Муки сисадмина 1С. Настройка планов обслуживания MS SQL сервера. DBCC CheckDB.

Многие не понимают важности и значимости планов обслуживания. Однако, если их вообще не настраивать или настроить неверно, то ваши базы данных очень скоро начнут доставлять вам немало хлопот, от сильного замедления в работе до полного отказа.

Ниже мы приведём один из испытанных временем планов обслуживания баз MS SQL Server, обеспечивающий функционирование программ С:Предприятие в ежедневном режиме, когда выделяется 20 часов на работу и 4 часа на обслуживание.

Для начала поясним, что при установке SQL Server Management Studio версии 20 и старше для того, чтобы этот мощный и удобный инструмент поддерживал работу с планами обслуживания, нужно на предварительном этапе не забыть установить компоненту Microsoft Visual Studio под названием Бизнес-аналитика:

Если этого не сделать, то мы не увидим при нажатии правой кнопкой мыши по Меню “Maintenance Plans (Планы обслуживания)” следующего контекстного всплывающего подменю:

Кроме того, важно отметить, что даже если вы сможете создать планы обслуживания, вы не сможете их запустить на выполнение, если при установке самого MS SQL Server не устанавливали SSIS (SQL Server Integration Services), ибо все планы обслуживания работают через этот компонент:

Прежде чем создавать планы обслуживания дадим некоторые определения. План обслуживания – это цепочка некоторых действий, осуществляемых при помощи скриптов на языке Transact-SQL (T-SQL), которые нужно выполнять регулярно в строго определённой последовательности. Вообще говоря, все необходимые действия можно определить в рамках одного общего плана обслуживания, так как SSMS (SQl Server Management Studio) это позволяет сделать, но в этом случае он будет представлять из себя довольно сложную конструкцию, фактически некоторую большую программу с набором условных операторов. В этой ситуации, если по какой-то причине не отработала какая-то часть плана, то выполнить быстро только эту часть будет сложно. Посему один план с логическими ветвлениями  – худшая практика. Не мудрствуя лукаво, приведём ниже сравнительную таблицу подходов к созданию планов обслуживания, исходя из которой примем решение создавать несколько отдельных планов:

Итак, выбираем из нашего меню пункт “Maintenance Plan Wizard (Мастер Планов обслуживания)”. Появляется окно приветствия мастера создания планов обслуживания SSMS. Изучаем, что там написано. Оно нам в будущем не понадобится, поэтому ставим птичку и нажимаем на кнопку Next (Далее):

В следующем окне нам нужно будет дать имя нашему плану, например “MaintenancePlan-1”, которое будет отражать тот факт, что этот план должен будет выполняться первым в нашей цепочке. Далее крайне желательно ввести описание (Description) плана, например DBCC CheckDB.  Оно будет отражать суть действия плана, ибо первое, что нам нужно будет непременно делать регулярно, так это проверять целостность баз данных (команда “DBCC CheckDB” T-SQL). Точку оставляем на радиокнопке “Single Schedule for entire plan or no schedule (Единое расписание выполнения на весь план или без расписания)”:

Если нужно задать расписание, то нажимаем на кнопку Change (изменить):

Здесь в нашем случае в поле Recurs every выбираем Daily (ежедневно), ставим в поле Occurs once at ровно в 2:00, при условии, что обслуживание выполняем в период с 2 ночи до 6 утра, и нажимаем на кнопку “ОК”, более никаких полей не исправляя. Система возвратится к предыдущему окну, где нужно просто нажать на кнопку Next (далее), что приступить к выбору действий:

Тут нам нужно выбрать только первое действие “Check Database Integrity (Проверить целостность базы данных)”, однако если для каких-то планов обслуживания нужно будет выбрать несколько действий, то данный интерфейс это позволяет, ибо здесь представлен список с множественным выбором.

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

После того, как вы проставите птички напротив нужных баз данных, у вас загорится кнопка “ОК”, которую нужно будет нажать. Отметим, что обычной и лучшей практикой является выбор всех баз данных (All databases), имея ввиду то, что системные базы данных тоже нужно регулярно проверять! При этом, как правило, имеет смысл пометить и пункт “Ignore databases whose state is not online (Игнорировать базы данных, находящиеся в автономном режиме)” Далее происходит как бы возврат к предыдущему окну, где стоит обратить внимание на возможность выбора пунктов Tablock (Блокировка Таблицы) и Max Degree of Parallelism. Если ваш сервер не испытывает недостатка в ресурсах, то просто опять нажимаем на кнопку Next (Далее), что приводит нас к предпоследнему окну выбора места, куда будет писаться отчёт о работе данного плана обслуживания:

Здесь можно оставить всё по умолчанию, либо выбрать другой каталог в файловой системе. Можно также воспользоваться возможностью отправки отчёта на e-mail. Нажатие на кнопку Next (Далее) приведёт к появлению завершающего процесс создания плана обслуживания окна, в котором остаётся просто нажать кнопку Finish (Завершить), либо Cancel (Отмена):

В результате в списке планов обслуживания появится новая строка с заданным нами названием “MaintenancePlan-1”. Если дважды щёлкнуть мышью по ней, то можно увидеть следующее окно:

В нём видно расписание запуска, название, описание плана, а также выбранное нами действие. Если нажать правой кнопкой мыши по нижней части, где приведено действие, то в ниспадающем контекстном меню можно выбрать пункт Edit (Редактировать), открывающий окно, дающее возможность изменить перечень баз, к которым нужно применить данное действие. Кроме того, в новом окне есть кнопка “T_SQL”, благодаря которой можно увидеть скрипт tranact-sql, который создала  система для осуществления выбранного действия:

Важно заметить, что регулярная проверка целостности базы данных, которая планируется к осуществлению в созданном выше плане обслуживания, является едва ли самым важным делом любого администратора баз данных. Она может помочь предотвратить катастрофу, ибо база данных обычно рушится не сразу, могут происходить так называемые “Тихие повреждения (Silent Corruption”, происходящие когда диски, RAID-контроллеры или оперативная память сбоят и искажают данные при записи или чтении. DBCC CheckDB – чисто информационная процедура, подразумевающая три исхода:

• всё хорошо, можно не беспокоиться;
• базе данных не хватает дискового пространиства для расширения (alloc error);
• ошибки согласованности данных (consistency error)

Обычно, конечно же, всё бывает хорошо, о чём свидетельствует соответствующий зелёный значок в окне, которое открывается с помощью следующего контекстного меню:

Однако, если это не так, то нужно срочно принимать меры в следующем приоритетном порядке:

На этом мы заканчиваем повествование по созданию плана обслуживания, предназначенного для регулярной проверки целостности базы данных и приступаем к описанию процесса создания плана обслуживания, который тоже должен выполняться регулярно и называется “Обновление статистики (Update Statistics)”.