глава 4. дизайн базы

Дизайн базы заключается в размещением файлов базы  (mdf, ldf ) по дискам
и заданию правильных размеров приращений.
Файлы уже размещены по дискам.
Начальные размеры если база влезла то все хорошо если нет то тут же начинают действовать приращения.

Осталось поговорить о приращениях.

Сначала о приращениях mdf
начиная с  ms sql 2005 появилась Быстрая инициализация файлов.

http://msdn.microsoft.com/ru-ru/library/ms175935%28v=sql.105%29.aspx
в ссылке описывается когда так делается и при каких условиях эта возможность отключается.

Т.е. эта возможность при выделении новых блоков и только для данных ( не для журналов транзакции )
позволяет делать мгновенное обнуление.
Поэтому вполне можно ставить приращение на данные побольше ( надо только учитывать
будут ли  или нет на этом диске еще файлы и также учитывать как  большие пустые куски будут влиять на Вашу стратегию резервного копирования).

Также ( ИХМО) никогда не ставьте значения приращений в процентах  потому что
это практически всегда пальцем в небо,
а во вторых серверу надо будет по процентам вычислить реальный размер приращения а это время и время очень
дорогое потому что на время выделения новых блоков файла база блокируется.


приращениях ldf
Совет ( ИХМО) тот же никогда не используйте приращение ldf в процентах.
В отличии от mdf, для ldf файлов  новые блоки всегда обнуляются.

Стратегия приращения зависит от модели восстановления.

1 случай модеь simple
В этой модели log файл закольцован сам на себя и в случае если голова догоняет хвост то выполняется приращение файла
В этом случае надо стремиться чтобы общий размер файла был минимальным
Можно вычислить Ваш размер методом деления пополам.
Берем приращение 100 Мб. смотрим как работает в течении дня т.е.
каким будет журнал транзакций в конце дня.
Обнуляем журнал транзакций и на следущий день все повторяем.
Если файл не изменился к концу дня то сокращаем размер вдвое
т.е. приращение 50 и смотрим как с этим приращением работает база.
Можно пойти и наоборот взять размер приращения 2 Мб и увеличивать его пока
у Вас задень не будет всего 3-4 приращения.
Естественно во время этих эксперементов не должно быть кардинальных событий
типа перестроения таблицы _1sjourn.


2 случай модель full.
В этой модели log  всегда только растет . При достижении конца файла всегда в конец файла добавляются новые блоки
и так  до тех пор пока не будет сделана резервная копия  и именно в этот момент усекается log файл.

Здесь все гораздо сложнее по выбору размера приращений.
С одной стороны надо чтобы число виртуальных журналов(активных ) было не очень большим
потому что при checkpoint надо просматривать все активные вирт журналы, т.е. это условие
требует чтобы приращение было большим а значит и сами вирт журналы большие,
а с другой стороны большое приращение влечет за собой большой размер виртуального журнала(активного )
и получается  обслуживание (checkpoint-а) одного большого вирт журнала обходиться
дороже чем двух в два раза меньше,
потому что когда два маленьких журнала то как только левый закроется ( но не усечеться)
то на обслуживание следующего журнала надо будет потратить меньше времени.
Ну а если самый левый журнал никогда не закроется (незакрыьая транзакция)то это в обоих случаях приведет к переполнению диска.

И Ваша задача найти оптимум между этими противоречивыми условиями.
Какой либо стратегии по поиску оптимального приращения для Вашей бд дать не могу.

к главе 4.
может быть тут для модели full имеет смысл упомянуть про стратегию бэкапов с возможностью восстановления БД на заданное время (постоянное резервное копирование transaction log в течении дня) - в этом случае приращений практически не будет (только в исключительных случаях).

глава 5    1с77 под ms sql2005


1.Переносим базу. Под sql2000 deattach под sql2005 attach
2.Ставим  для базы Уровень совместимости 80.
3.Настраиваем на новую базу 1с (из конфигуратора  Администрирование --> Параметры Базы 1с)
4. Запускаем 1с в монопольном и не в монопольном режиме.

На этот момент 1с работает ms sql2005.


на своей базе,Не сразу, но обнаружилось ( ограничение на память не было установлено )
следующее : что ms sql2005 брал под себя память. На существующих границах физич. памяти
не останавливался и через некоторое время происходило очень резкое падение производительности.
Так как памяти много это обнаружилось не сразу.
после выставления параметра ограничения памяти  30 Гб всего памяти 32
проблема полностью ушла.Здесь важно что значение надо задавать в мегабайтах.

max server memory (MB)  30720

Нижнюю границу не ограничивал потому что и bool написано что операц. система не обязана
сразу выделять память по нижней границе, и когда проводил эксперементы несмотря на
установленное значение нижней границе память выделялась по мере необходимости.
поэтому оставил ниж значение = 0 .
min server memory (MB)  0

Также был вместе с ограничением по памяти был выставлен приоретет sql (в значение=1 )
над другими задачами.
priority boost 1


Надо или нет ограничивать sql меньшим числом процессоров(ядер) чем есть на самом деле.
Я не ограничивал используются для ms sql все имеющиеся процессоры.
В книжках пишут если Вы хотите от операционной системы лучший отклик
то оставьте один процессор только под операционную систему.


Макс колво процессоров выделяемых под выполнение запроса.
Значение больше 1 означает сколько ms sql может выделить процессоров ( не  обязательно что будет выделять)
для выполнения запроса.
Значение 1 означает что над выполнением запроса
всегда выделяется ровно один процессор(ядро). Для задач OLTP ( в том числе и 1с77 )
надо выставлять 1.
Значение  0 означает что ms sql для каждого запроса сам решает сколько под выполнение
запроса надо выделить процессоров(ядер). Это значение идет по умолчанию.


max degree of parallelism 1

trad писал(а) 04. Декабря 2012 :: 06:16:

да точно, для выполнения запроса.

А зачем уровень совместимости понижать?

Всмысле ?
По -умолчанию,уровень совместимости 100.
откуда он меньше взялся ?

И зачем его делать 90 ?