Использование клиент-серверного варианта работы системы 1С:Предприятие накладывает дополнительные обязательства по обслуживанию информационной системы. То, какие задачи и как часто должны выполняться для поддержания высокой производительности системы, мы рассмотрим в данной статье на примере СУБД MS SQL Server.
Будем считать что на данный момент у нас инсталлирован экземпляр MS SQL Server и развернута база данных (с полной моделью восстановления). Думаю, многие предполагают или даже знают, что нельзя просто установить СУБД, развернуть на ней базу данных и «отправить в свободное плавание». Дело в том, что происходит фрагментация индексов, устаревает статистика, и это приводит к замедлению системы. Помимо этого нельзя забывать о резервном копировании базы данных, а для базы с полной моделью восстановления еще необходимо периодически делать резервное копирование транзакционного лога. Таким образом, мы приходим к пониманию что нам необходимо организовать и автоматизировать выполнение регламентных задач обслуживания нашей базы данных. О том какие процедуры обслуживания и с какой частой следует производить, мы и разберем в этой статье.
Процедуры обслуживания
Попробуем разобраться какие процедуры обслуживания нам необходимо выполнять и как часто. Для удобства объединим процедуры в связанные группы, впоследствии они станут субпланами обслуживания. О том как создать план обслуживания можно прочесть в статье «Механизм «Планы обслуживания» MS SQL Server».
Субплан «В течение дня»
- Резервное копирование транзакционного лога. Когда для базы данных выбрана полная модель восстановления, необходимо регулярно делать резервное копирование транзакционного лога, иначе будет происходить его чрезмерное разрастание, пока тот не займет все пространство на диске, а SQL Server начнет сообщать об этой ошибке. Для простой модели восстановления данная задача не требуется. Частота бэкапа журнала транзакций напрямую зависит от выделенного для него размера на диске, а так же от интенсивности работы с базой. Зависимость эта заключается в рекомендации что транзакционной лог не должен расти (должен сохранять выделенное ему место на диске) в течение работы пользователей с базой данных. Для себя я выбрал частоту резервного копирования лога транзакций равной 1 часу. Более подробно о настройке задания резервного копирования журнала транзакций написано в статье «Резервное копирование транзакционного лога».
Субплан «Ежедневный» (6 из 7 дней в неделе)
Для поддержания базы данных в эффективном для работы состоянии, необходимо ежедневно (в нерабочее время) выполнять следующие задачи:
- Реорганизация/Дефрагментация индекса (Reorganize Index). Database Engine автоматически обновляет индекс при операциях INSERT, DELETE, UPDATE. Со временем эти операции могут привести к фрагментации индекса. Значительно фрагментированные индексы могут серьезно снижать производительность запросов и служить причиной замедления. Таким образом, необходимо в план обслуживания включить задание по устранению фрагментации индексов. Альтернативой дефрагментации индексов является реиндексация/перестроение индекса (rebuild index), но она имеет такие недостатки как: значительно большее время выполнения; сброс статистики использования индексов, которая требуется для целей описанных в статье «Поиск отсутствующих индексов таблиц в базе на MS SQL Server». Также в качестве альтернативы возможно использование хранимой процедуры условного (от степени фрагментации) выбора способа устранения фрагментации (реорганизация/перестроение) индекса. Более подробно можно прочитать в «Реорганизация/дефрагментация индекса СУБД MS SQL Server»
- Обновление статистики (Update Statistics). Скорость выполнения запроса зависит от построенного для него плана запроса, который, в свою очередь, опирается на информацию о существующих индексах, а также на статистику. Если статистика устарела, существует вероятность выбора не оптимального плана запроса, что приведет к снижению производительности. Таким образом, необходимо включить задание обновления статистики.
- Разностное резервное копирование (Differential backup). Надеюсь, нет необходимости рассказывать почему надо делать периодическое резервное копирование базы данных, альтернативой разностному бэкапу является полное резервное копирование. Разностное резервное копирование включает в себя только изменения между текущим состоянием базы данных и состоянием базы данных на момент последнего полного резервного копирования, таким образом, задача разностного бэкапа выполняется быстрее, а сам файл занимает меньше места. В то же время есть и недостаток разностного бэкапа — без полного бэкапа он бесполезен.
- Очистка процедурного кэша. Для очистки кэшированных планов запросов необходимо выполнить очистку процедурного кэша. Обновление статистики вызывает рекомпеляцию запросов, но, для надежности, рекомендуется включить данную задачу после выполнения задачи обновления статистики.
Субплан «Еженедельный» (7-ой день недели)
В целом, данный субплан похож на «Ежедневный», но в нем присутствует задача «Проверка целостности базы данных», дефрагментация заменена на более требовательную процедуру «Перестроение индекса», а также разностный бэкап заменен на полный. Если достаточно ресурсов (как системных, так и времени в которое не происходит работы пользователей), тогда при желании можно еженедельный план сделать ежедневным, отказавшись от ранее описанного ежедневного.
- Проверка целостности базы данных (Check Database Integrity). Используется для проверки размещения и структурной целостности пользовательских и системных таблиц, а также индексов в базе данных.
- Реиндексация/Перестроение индекса (Rebuild Index). Достаточно долгая и требовательная операция. Она удаляет и заново строит индексы. В результате данной операции удаляется статистика использования индексов.
- Обновление статистики (Update Statistics)
- Full backup (Полное резервное копирование)
- Очистка процедурного кэша
Субплан «Экстренное резервное копирование и сжатие транзакционного лога»
В простейшем случае субплан состоит из 2 последовательных выполнений резервного копирования и усечения транзакционного лога. Почему именно 2 — мне не совсем ясно, но на практике первое усечение не дает необходимого результата. Если кому-то известно такое поведение, напишите в комментариях, пожалуйста. Данный субплан не должен иметь расписания. Данный план нам потребуется для двух целей: во-первых, как задача других субпланов (например, при перестроении или дефрагментации индексов происходит сильное разрастание журнала транзакций, чтобы вернуть ему исходный размер, будет выполнен этот субплан). Во-вторых, в случае необходимости экстренного «ручного» выполнения усечения транзакционного лога.
Создание плана обслуживания по данному перечню будет приведено в будущих статьях…