Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, AlexGin, Вы писали:
AG>>Есть сервер — контроллер домена (Windows Server 2012), но пока — экспериментируем на рабочем месте.
S>Вообще на контреллер домена SQL Server ставить не рекомендуется, и, как минимум 2005 и не ставился. Подозреваю более поздние тоже.
+100500
Да, уважаемый Somescout, именно так!
Я (под всеми правами админа) пытался установить различные версии MS SQL Server 2012 (на контроллер домена),
однако, данное действие всегда сопровождалось руганью
ALTER DATABASE [mydatabase] SET RECOVERY SIMPLE
DBCC SHRINKFILE(<log_file_name_Log>)
-- В данном случае, следующая строка не актуальна:
-- ALTER DATABASE [mydatabase] SET RECOVERY FULL
Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здравствуйте, capgreen, Вы писали:
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие. C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительностидля систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если ядро расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две или три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в таблицы БД не будет являться наиболее низкопроизводительным (узким) звеном
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.
Вообще, проблема в том что SQL Server пытается создать локальные группы (в SAM), которых полностью отключены на контроллере домена. Можно это обойти (если очень хочется приключений), если сначала поставить SQL Server, а затем контроллер домена. Но лучше разнести это по виртуалкам, благо начиная с Win2012 одну лицензию Standard можно использовать на двух виртуальных машинах (на одном сервере, при условии что если используется Hyper-V, то в на хосте стоит только его роль без дополнительного софта).
ARI ARI ARI... Arrivederci!
Re: MS SQL Server для моделирования и научных расчётов
Здравствуйте, bnk, Вы писали:
bnk>А зачем вам тогда вообще SQL SERVER? Почему не просто файл например?
Файлы — возможное, однако НЕ удобное решение для данного круга задач. Причины следующие:
1) Нам нужно хранить определённые структуры данных, где явно имеются определённые поля (столбцы). Выбирать набор таких структур
намного проще испльзуя привычные SQL запросы, нежели городить свои процедуры работы с файлами, тем более, что SQL имеет удобочитаемый вид.
Это особенно важно, когда в команде авторов есть как программисты, так и разработчики алгоритмов, для которых понять SQL скрипт —
намного проще, чем разобраться в кодах C/C++ (то есть в кодах самого приложения).
2) Объём хранимой информации — весьма большой, по мере проведения экспериментов, он быстро увеличивается. Таким образом, возникнет
дополнительная проблема архиварования при переносе, которая при использовании MS SQL Server решается элементарно: back-up/restore.
3) По мере исследований и доработок имитационной модели, происходит изменение структур (таблиц), изменение количества полей (столбцов).
В этом случае, подкорректировать SQL скрипт будет намного проще (и быстрее), нежели изменять в кодах проекта процедуры работы с файлом.
4) В составе MS SQL Server имеется удобная утилита — MS SQL Server Management Studio. Применяя данную утилиту, я имею возможность:
a) запрашивать — через SELECT... любые данные из любых структур, при этом сразу видеть результат выполнения данного запроса;
b) изменять — выполнив UPDATE любую запись (строку) в любой из таблиц (без сложных действий — программирования файловых процедур);
c) исследовать различные запросы, выполняемые от нашего приложения, на предмет как корректности, так и оптимизации по времени.
5) Используя MS SQL Server Management Studio, я могу оперативно создавать новые таблицы и корректировать старые, при этом в
кодах приложения может (на текущий момент) иметься только процедура выборки данных (через SELECT...), что позволяет оперативно
изменять данные для проводимых экспериментов, не производя действий, которые впоследствии могут оказаться вообще лишними.
P.S. Вся поддержка работы с БД в кодах приложения выполнена в виде программного интерфейса (aka абстрактный класс в C++).
Посему, если возникнет необходимость, изменить тип хранилища можно относительно безболезненно.
