Автоматизация задач поддержки баз данных MS SQL Server

У нас в DB-Service принят ряд практик по автоматизации баз данных MS SQL Server, благодаря которым БД наших клиентов работают бесперебойно и эффективно. В этой речь мы расскажем о них — процедурах обслуживания индексов и статистики SQL Server, резервного копирования, и проверки целостности баз данных.

Из-за фрагментации индексов без их регулярного обслуживания, работа с таблицами замедляется, что может снижать эффективность бизнеса и приводить к финансовым потерям. Поэтому в DB-Service мы советуем использовать IndexOptimize — это процедуру ребилда и реорганизации индексов, а также обновления статистики.

Процедура кастомизированная и имеет множество параметров. Её можно настроить на выполнение как для всех баз данных, так и для БД определенного типа (например, системных или пользовательских баз), а также для конкретной БД.

Для работы доступны разные режимы ребилда индекса:

Пример условия может звучать так: «Реорганизовать индекс. Сделать ребилд индекса онлайн, если реорганизация не поддерживается. Сделать ребилд в автономном режиме, если иное невозможно».

Для любого уровня фрагментации индекса есть подходящие параметры обслуживания, так как процедура проверяет это значение в системном динамическом представлении sys.dm_db_index_physical_stats.

В процедуре можно также настроить фильтр на количество страниц в таблице. Например, если страниц меньше 50, то процедуру проводить не эффективно, а значит эти таблицы не будут обслуживаться заданием.

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

Обновление статистики является частью обслуживания и обеспечивает оптимизатору запросов наиболее эффективные планы их выполнения. Это позволяет ускорить обмен данными. Мы настраиваем сбалансирование расписание обновления — слишком частое использование процесса также вредно, как и слишком редкое. Возможно обновление статистических данных по всем индексам и столбцам или выборочное.

Использование политик бэкапов для баз данных MS SQL является важной практикой по обеспечению безопасности и защите данных. Базы данных подвержены различным рискам, таким как сбои жесткого диска, ошибки операционной системы, вирусные атаки или человеческий фактор. Регулярные резервные копии обеспечивают возможность восстановления данных в случае их потери.

В DB-Service мы используем гибкий подход для каждого клиента и предлагаем различные стратегии резервного копирования. В зависимости от отрасли, в которой работает ваша компания, вам будут предложены конкретные правила, нормативы и требования к хранению данных.

Нашим главным решением является гибкая и эффективная процедура Database Backup. Она позволяет настраивать политики резервного копирования для всех баз данных, либо для подгруппы — системных или пользовательских баз. Специальные флаги дают возможность исключать произвольные базы из обслуживания вплоть до настройки политики исключительно для одной базы. Возможен выбор места хранения копий — локальный каталог или сетевой ресурс.

Database Backup создает структуру каталогов с именем сервера, именем экземпляра, именем базы данных и типом бэкапа в корневом каталоге резервной копии. Если база данных является частью группы доступности, то вместо имени сервера и имени экземпляра используются имя кластера и имя группы доступности.

Существует три типа резервного копирования:

В зависимости от важности базы и настроек можно применять разные конфигурации. Как правило мы настраиваем все три типа бэкапов для продовых баз, что даёт возможность восстановить их к любому моменту времени.

Для хранения копий предусмотрены параметры cleanup mode и cleanuptime mode. С помощью них мы настраиваем автоматическое удаление ненужных копий с целью сохранения дискового пространства для свежих бэкапов.

Например, режим BEFORE_BACKUP удалит старую копию прежде чем сделать новую, а AFTER_BACKUP удаляет старые файлы резервных копий после выполнения бэкапа. В последнем случае, если резервное копирование завершилось неудачно, файлы резервных копий не удаляются. Для дополнительной экономии места можно использовать сжатие копии.

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

Для такой проверки мы используем эффективный инструмент — хранимую процедуру проверки целостности БД DatabaseIntegrityCheck. Задание можно использовать для любой подгруппы баз данных, в том числе сконфигурированных с помощью AAG. Целостность можно проверять как на уровне базы данных, так и на уровне отдельной файловой группы.

Главная цель нашего сервиса — обеспечить быструю, отказоустойчивую и надёжную работу системы. Перечисленные выше практики — лишь часть нашей работы по управлению и автоматизации баз данных. Мы щепетильно относимся к настройке необходимых параметров операционной системы и СУБД и следуем следующему алгоритму, который позволяет обеспечить высокую эффективность и надежность MS SQL Server.