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

После очередной просьбы рассказать как составить план обслуживания 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

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

По пунктам плана обслуживания:

Перестроение индекса. 

Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
В качестве параметров:

Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).

Объект, в котором мы выбираем «Таблицы и представления».

Параметры свободного места – при малом объеме жесткого диска можно выбирать пункт «по умолчанию», однако я рекомендую использовать «Изменить долю свободного места на странице», рекомендуемое значение 20%. Это позволит оставить запас свободных страниц, и позволит дольше держать индексы в актуальном состоянии. ВНИМАНИЕ: Увеличивает размер базы данных.

Отсортировать результаты в tempdb. Думаю пояснять не требуется, однако предупредить хочу, в это время tempdb, будет очень сильно разрастаться, хоть и сортировка в ней и призвана ускорить процесс, будьте осторожны, имейте запас пространства.

Сохранять индекс в режиме «в сети» — фишка доступная для enterprise версии SQL. Позволяет делать переиндексацию без отключения клиентов.!!! ВНИМАНИЕ!!! В Standard версии при переиндексации происходит отключение клиентов от базы данных на время работы данного шага.

Пример настроек

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

Обновление статистики. 

Задача сбора информации о состоянии индексов в базе. (В общем-то мало актуальная после переиндексации, но все же я делаю).
Параметры:

  • Объект. Все те же таблицы и представления, что и для перестроения индекса.
  • Обновить. Тут обновляем всю статистику.
  • Тип просмотра – Полный просмотр.

Таким образом, мы обновляем статистику по всей базе данных.

Пример настроек:

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

Выполнение инструкции T-SQL

Это выполнение произвольной команды на языке SQL, в частности нас интересует

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

Проверка целостности базы данных

Тут кажется излишни пояснения – убеждаемся, что ничего не сломалось. В параметрах «включаем индексы» в проверку, не зря же перестраивали.

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

Резервное копирование базы данных.

Тут поговорить надо побольше, ввиду многих особенностей. Лучше изучить данный пункт отдельно самостоятельно в других руководствах, формат данной статьи не предусматривает углубленного изучения резервного копирования.
Но о паре нюансов хочу предупредить:

  • SQL не умеет чистить контейнер свой, потому если добавлять резервные копии в файл (оно же обзывается «Устройство резервного копирования»), в итоге забьете все свободное место.
  • SQL помнит о своих резервных копиях, потому сделав ручками бэкап, единоразовый (например, отнести базу в другое место, или чтоб развернуть для теста в еще одну базу из бэкапа), следующий «разностный» будет отсчитываться от него. Дабы предотвратить это, требуется ставить галочку «Только резервное копирование». В задаче резервного копирования такого пункта нет. Вообще в недельном плане рекомендую все же использовать полный тип резервной копии.
  • И хорошо бы проверять копию, пусть спиться спокойнее.
  • Сжатие, в общем-то, использовать можно, но будьте аккуратны, разностные тогда надо тоже сжимать.
Составление планов обслуживания SQL для нужд 1С: Предприятия 8.х

Очистка журнала

  • Журнал резервного копирования и восстановления.
  • Журнал заданий агента SQL Server.
  • Журнал плана обслуживания.

Я чищу все. Как следует из названия, чистит события в журнале SQL. Я считаю, что события старше 4 недель вряд ли меня заинтересуют, ибо если проблема есть, то о ней сообщать в течение месяца.

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

Уведомление оператора

Пунктик опять-таки для самостоятельного изучения. Но как понятно из названия, для сообщения о проблемах в ходе выполнения плана.

Daily

Общий вид

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

Говорить отдельно не имеет смысла. Почти все аналогично Weekly.
Различие в первой задаче – «Реорганизации индексов». Задачи отличаются тем, что реорганизация пытается выправить имеющиеся индексы, а не делает все с чистого листа. Чем больше фрагментация – тем чаще стоить запускать. Но в нормальных условиях раз в день достаточно, чтобы поддерживать индекс в актуальном состоянии до следующего перестроения.

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

Так же можно использовать разностное резервное копирование.

На этом все. Повторяюсь, догматов в этом моменте я не видел, этот вариант был разработан и протестирован мной. Актуально для баз размером от 6 до 100 ГБ.

Оцените статью
( 1 оценка, среднее 5 из 5 )