Necro_KOT
После очередной просьбы рассказать как составить план обслуживания sql-баз используемый1С: Предприятием, решил поделиться опытом со всеми сразу.
Зачем это надо - если в sql не обслуживать базы данных, то его смысл теряется вовсе. Основной инструмент - индексы и их надо держать в актуальном состоянии. Каких-то догматов я не встретил не в практике, не в нете, не на курсах в самой 1С, а потому делюсь своим опытом.
Зачастую база работает в "нормальных" условиях. Что под этим подразумевается:
- Сервер SQL хорошо "питается", т.е. объем ОЗУ предоставляемой для работы SQL сервера выбирать из расчёта 70% от размера всех mdf файлов баз данных.
- Процессор не загружен более чем на 50% в течении 90% времени.
- Имеется достаточное место на дисках (в частности для сортировки используется база temp.db, 1С ее использует вообще для всей своей жизнедеятельности, потому стоит заранее озаботиться местом на диске с этой базой).
- Режим восстановления базы данных - "Простой". (Эмпирически выяснено, что большой ldf файл тормозит 1с-ку, а возможность восстановления по лог-файлу весьма сомнительна).
Так же стоит учитывать несколько нюансов:
- При использовании Standard редакции SQL, при полном перестроении индекса, все пользователи будут отключены от базы, потому стоит это учитывать при решении проведения Weekly плана обслуживания (план будет описан ниже).
- Стоит учитывать, что сервер 1С тоже потребляет память, особенно если используются тонкие клиенты или веб-службы.
- Самому SQL лучше ограничить в параметрах сервера максимальный объем ОЗУ, дабы по достижению критической массы, он заранее начинал очищать ненужные данные из ОЗУ. Да и чтоб разрастаясь не вгонять весь сервер в ступор.
Рационально при нормальных условиях использовать 2 плана обслуживания Weekly (раз в неделю) и Daily(в остальные 6 дней недели).
Weekly
Общий вид
По пунктам плана обслуживания:
- Перестроение индекса. Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
В качестве параметров:
- Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).
- Объект, в котором мы выбираем "Таблицы и представления".
- Параметры свободного места - при малом объеме жесткого диска можно выбирать пункт "по умолчанию", однако я рекомендую использовать "Изменить долю свободного места на странице", рекомендуемое значение 20%. Это позволит оставить запас свободных страниц, и позволит дольше держать индексы в актуальном состоянии. ВНИМАНИЕ: Увеличивает размер базы данных.
- Отсортировать результаты в tempdb. Думаю пояснять не требуется, однако предупредить хочу, в это время tempdb, будет очень сильно разрастаться, хоть и сортировка в ней и призвана ускорить процесс, будьте осторожны, имейте запас пространства.
- Сохранять индекс в режиме "в сети" - фишка доступная для enterprise версии SQL. Позволяет делать переиндексацию без отключения клиентов.
!!! ВНИМАНИЕ!!! В Standard версии при переиндексации происходит отключение клиентов от базы данных на время работы данного шага.
- Обновление статистики. Задача сбора информации о состоянии индексов в базе. (В общем-то мало актуальная после переиндексации, но все же я делаю).
Параметры:
- Объект. Все те же таблицы и представления, что и для перестроения индекса.
- Обновить. Тут обновляем всю статистику.
- Тип просмотра - Полный просмотр.
Таким образом, мы обновляем статистику по всей базе данных.
- Выполнение инструкции T-SQL. Это выполнение произвольной команды на языке SQL, в частности нас интересует
dbcc proccache
Как следует из название - чистка кэша.
- Проверка целостности базы данных. Тут кажется излишни пояснения - убеждаемся, что ничего не сломалось. В параметрах "включаем индексы" в проверку, не зря же перестраивали.
- Резервное копирование базы данных. Тут поговорить надо побольше, ввиду многих особенностей. Лучше изучить данный пункт отдельно самостоятельно в других руководствах, формат данной статьи не предусматривает углубленного изучения резервного копирования.
Но о паре нюансов хочу предупредить:
- SQL не умеет чистить контейнер свой, потому если добавлять резервные копии в файл (оно же обзывается "Устройство резервного копирования"), в итоге забьете все свободное место.
- SQL помнит о своих резервных копиях, потому сделав ручками бэкап, единоразовый (например, отнести базу в другое место, или чтоб развернуть для теста в еще одну базу из бэкапа), следующий "разностный" будет отсчитываться от него. Дабы предотвратить это, требуется ставить галочку "Только резервное копирование". В задаче резервного копирования такого пункта нет. Вообще в недельном плане рекомендую все же использовать полный тип резервной копии.
- И хорошо бы проверять копию, пусть спиться спокойнее.
- Сжатие, в общем-то, использовать можно, но будьте аккуратны, разностные тогда надо тоже сжимать.
- Очистка журнала.
- Журнал резервного копирования и восстановления.
- Журнал заданий агента SQL Server.
- Журнал плана обслуживания.
Я чищу все. Как следует из названия, чистит события в журнале SQL. Я считаю, что события старше 4 недель вряд ли меня заинтересуют, ибо если проблема есть, то о ней сообщать в течение месяца.
- Уведомление оператора. Пунктик опять-таки для самостоятельного изучения. Но как понятно из названия, для сообщения о проблемах в ходе выполнения плана.
Daily
Говорить отдельно не имеет смысла. Почти все аналогично Weekly.
Различие в первой задаче - "Реорганизации индексов". Задачи отличаются тем, что реорганизация пытается выправить имеющиеся индексы, а не делает все с чистого листа. Чем больше фрагментация - тем чаще стоить запускать. Но в нормальных условиях раз в день достаточно, чтобы поддерживать индекс в актуальном состоянии до следующего перестроения.
Так же можно использовать разностное резервное копирование.
На этом все. Повторяюсь, догматов в этом моменте я не видел, этот вариант был разработан и протестирован мной. Актуально для баз размером от 6 до 100 ГБ.
Желаю Вам быстрой и надежной работы.
Ссылки по теме
