Составление планов обслуживания SQL для нужд 1С: Предприятия 8.х

Источник: habrahabr

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 ГБ.

Желаю Вам быстрой и надежной работы.