В данной статье рассматривается создание нового (ежедневного) субплана плана обслуживания базы данных на СУБД MS SQL Server, а также настройка выполнения задания реорганизации/дефрагментации индекса. Статья является продолжением статьи «Перечень необходимых задач регламентного обслуживания MS SQL Server».
Предисловие
Индексы таблиц базы данных являются важной составляющей для производительной работы системы. Во время работы с базой данных, при добавлении/изменении/удалении информации из таблиц базы данных, происходит автоматическое обновление индексов, что, в свою очередь, приводит к постепенной фрагментации последних. Фрагментированные индексы могут значительно снизить производительность системы, для их дефрагментации необходимо выполнять соответствующие регламентные операции. Настройку одного из таких мы сейчас и рассмотрим на примере создания ежедневного субплана плана обслуживания.
Настройка задания
В ранее созданный нами план обслуживания (статья «Резервное копирование транзакционного лога») добавим еще один субплан «EveryDayActivity» и назначим расписание его выполнения. Поскольку данный план обслуживания должен выполняться ежедневно (а точнее 6 раз в неделю, т.к. в один из дней недели мы будем выполнять другой, «Еженедельный» план), установим выполнение, например, с понедельника по субботу, в период времени когда пользовательская активность минимальна или ее нет (в моем случае 5:00 утра).
Далее, из панели инструментов Планов обслуживания перенесем задание «Реорганизация индекса» (Reorganize Index Task) в рабочую область субплана (т.е. добавим задание в наш субплан).
И, сразу после этого, двойным щелчком по заданию, откроем его свойства.
Данная задача имеет лишь небольшое количество настроек, тем не менее, рассмотрим их:
- «Базы данных» (Databases): в данном свойстве можно выбрать одну/несколько/все базы данных. Здесь выбор зависит от вашего желания, если план обслуживания создается общий для нескольких баз, можно выбрать все необходимые.
- «Объект» (Object): ограничивает набор данных в поле «Выбор» для отображения таблиц, представлений или обоих элементов. Для наших целей подходит значение «Таблица» (Table)
- «Выбор» (Selection): в данном поле можно выбрать конкретные таблицы, индексы которых, необходимо реорганизовать. Такая возможность может быть полезной, например, если есть таблицы с редко изменяемыми данными, а значит и индексы у них фрагментируются медленно, тогда в целях экономии времени на выполнение задания, можно исключить такие таблицы из ежедневного задания, но включить в еженедельное, например.
- «Сжатие больших объектов» (Compact large objects): сжимает большие объекты (LOB), по умолчанию установлено. Смысла отключать не имеет, разве что для сокращения времени выполнения задания.
Таким образом, сейчас у нас должно быть одно задание в новом субплане:
В следующих статьях будет рассмотрено добавление оставшихся заданий в ежедневный субплан плана обслуживания.
А были ли попытки оценить эффект от этой постоянной дефрагментации? И оправдывает ли он дополнительную нагрузку на систему? И второй вопрос. Не пробовали ли решить проблему настройкой индексов, чтобы уменьшить фрагментацию?
Нет, оценка мной не производилась. Сам кейс интересный, но сильно зависит от входящих данных и, соответственно, не понятно как его обобщить (для разных систем). Думаю, как-нибудь проведу такой эксперимент.
Говоря о дополнительной нагрузке (в данном случае) стоит разделять системы работающие 24/7 и системы с наличием окон для выполнения регламентных операций (административно установленными или ввиду рабочего режима сотрудников-пользователей системы). В первом случае, действительно, следует сопоставлять доп.нагрузку и выигрыш от регламентного задания. Для сокращения показателя «доп.нагрузка/выигрыш» можно произвести комплексный анализ системы и вместо обычного задания написать скрипт с учетом характера использования таблиц (количества операций чтения, количества операций записи), частоты использования индекса, степени фрагментации. Тут вопрос до какого уровня необходимо сократить показатель «доп.нагрузка/выигрыш». Во втором не вижу в этом смысла, если удается вписаться в это окно.
Я не совсем понял вопрос, как мне кажется, здесь перепутана причинно-следственная связь. Фрагментация является следствием выполнения операций вставки, обновления или удаления. Индекс же создается с целью повышения производительности поиска данных. Таким образом, если индекс является необходимым и производительным, о какой его настройке идет речь?
Если под настройкой индекса понимается изменение состава индекса (удаление лишних полей), а так же удаление неиспользуемых индексов, конечно, это повлияет на степень фрагментации/совокупность фрагментированных индексов, но здесь первоочередно должен стоять вопрос не об «уменьшении фрагментации», а об увеличении производительности системы. Так, при наличии неиспользуемых индексов или неиспользуемых полей индекса, это вносит дополнительные затраты при записи данных в БД и их следует оптимизировать.
Помимо этого, стоит упомянуть что платформа 1С:Предприятие сама строит индексы в соответствие со структурой метаданных, соответственно, настройка индексов происходит за счет правильной настройки метаданных в конфигурации.
Изменение же индексов непосредственно в СУБД является нарушением лицензионного соглашения. При этом, если при обновлении информационной базы 1С:Предприятие будет затронут объект метаданных, для которого индекс был изменен непосредственно в СУБД, изменения в СУБД могут быть потеряны (возвращены в состояние, определяемой платформой).