Администраторам баз данных приходится следить за тем, чтобы для всех баз данных на каждом сервере выполнялось ежедневное плановое резервирование, и это занимает немало времени. Но как убедиться в том, что все необходимые задания резервирования действительно были выполнены в назначенный день? Что если кто-нибудь остановил или отменил настроенное вами задание, не поставив вас в известность (а такие ситуации, к сожалению, не редкость в компаниях, где работают несколько администраторов)? Вы хотите точно знать, что каждая база данных была зарезервирована, при этом не полагаясь на специальные методы резервирования, будь то встроенные средства SQL Server или продукты сторонних разработчиков. Задача усложняется, если поддерживается множество систем SQL Server с собственными планировщиками заданий, будь то агент SQL Server или сторонние планировщики, и вы используете комбинацию встроенных средств резервирования SQL Server и сторонних разработчиков.
В данной статье рассматривается способ мониторинга состояния резервирования нескольких серверов и создания отчетов с помощью одного центрального сервера. При этом не используются планировщики или альтернативные методы, предлагаемые сторонними разработчиками. Следует заметить, что полностью полагаться на этот метод для проверки резервирования все же не стоит. Отчет содержит только ту информацию, которая имеется на SQL Server. Никто не отменял необходимость физической проверки целостности резервных копий и выполнения тестовых процедур восстановления данных в соответствии с принятыми правилами.
Создание отчета о состоянии резервирования
Существует множество способов мониторинга и создания подробных отчетов о резервировании. Если не планируется тратить средства на приобретение инструментов сторонних разработчиков, можно воспользоваться предлагаемыми сценариями и создать собственные отчеты (ничем не хуже коммерчески доступных). Предлагаемые в статье сценарии могут работать с SQL Server версий 2008, 2005, 2000, а также с SQL Server 7.0. Обратите внимание, что в многосерверной среде следует назначить один из серверов SQL Server на роль центрального сервера (см. рисунок), на котором будет храниться информация о состоянии резервирования других серверов, связанных с центральным.
Таблица dbo.backupset в базе данных msdb содержит полную информацию о резервировании. На каждой отдельной системе SQL Server можно выполнить представленный в листинге 1 сценарий, чтобы найти все базы данных, для которых резервирование не выполнялось более семи дней. Назначив главный сервер, выполните перечисленные ниже шаги для создания хранимой процедуры, формирующей отчет о выполнении резервирования и задания для исполнения этой хранимой процедуры.
Шаг 1. Создание на центральном сервере соединений со связанными серверами. На центральном сервере необходимо установить соединения со всеми подчиненными серверами, информацию о резервировании которых планируется собирать. Детально процесс создания связей для SQL Server 2000 описан в статье «How to set up a linked server (Enterprise Manager)» в документации SQL Server Books Online (BOL). Связывание серверов для SQL Server 2005 рассматривается в статье «Linking Servers» в BOL. Представленные ниже сценарии будут обращаться к таблице sysservers, которая содержит все зарегистрированные связанные серверы в базе данных master. Прежде чем перейти к следующим шагам, убедитесь, что вы можете подключиться ко всем связанным серверам.
Шаг 2. Создание таблицы Backup_Status. На центральном сервере выполните сценарий create_table_backup_status.sql, представленный в листинге 2. Обратите внимание, что в этом и всех последующих листингах необходимо подставить имя вашей базы данных.
Шаг 3. Создание хранимой процедуры usp_mon_backup_status_of_all_servers. На центральном сервере выполните сценарий 02_ usp_mon_backup_status_of_all_servers.sql, чтобы создать хранимую процедуру usp_mon_backup_status_of_all_servers (листинг 3).
Шаг 4. Создание хранимой процедуры usp_help_backup_status. С помощью сценария, представленного в листинге 4, создайте на центральном сервере хранимую процедуру usp_help_backup_status.
Шаг 5. Создание задания для запуска хранимой процедуры usp_help_backup_status. Создайте задание для запуска на центральном сервере хранимой процедуры, сформированной на шаге 3. Вы можете также создать расписание для ежедневного запуска этого задания. Исчерпывающие сведения о создании заданий, шагах заданий и расписаниях запуска заданий можно найти в разделе Implementing Jobs в документации BOL.
Теперь, когда все подготовительные шаги выполнены, для получения ежедневного отчета о состоянии резервирования достаточно подключиться к центральному серверу с помощью анализатора запросов Query Analyzer или SQL Server Management Studio, открыть окно запроса и выполнить хранимую процедуру usp_help_backup_status, которая приведена в листинге 5. Результатом ее исполнения будет отчет, подобный представленному на экране.
Чтобы получить более детализированные отчеты, можно вызвать эту хранимую процедуру из Access или из SQL Server Reporting Services, чтобы отчет могли просматривать и другие пользователи, или даже опубликовать полученный из Reporting Services отчет на портале SharePoint. Созданный таким способом отчет может вполне заменить отчеты, сформированные с помощью продуктов сторонних разработчиков.
Проверка состояния резервирования
Администраторам баз данных необходимо иметь полную информацию о состоянии резервного копирования на всех системах SQL Server в своей зоне ответственности, а с использованием предложенного метода задача отслеживания создания резервных копий значительно упрощается. Предлагаемый метод обеспечивает мониторинг состояния резервного копирования без привлечения дополнительных средств, агента SQL Server, планировщиков и других продуктов от сторонних разработчиков.
Сивакумар Махалингам (sivim98@yahoo.com) — администратор баз данных в одной из крупных торговых компаний в США. Помимо баз данных SQL Server, он управляет базами Oracle, Teradata и DB2
Экран. Отчет о состоянии резервирования
Листинг 1. Сценарий для поиска баз данных, резервирование которых не выполнялось более 7 дней
Листинг 2. Сценарий создания таблицы Backup_Status
Листинг 3. Сценарий для создания хранимой процедуры usp_mon_backup_status_of_all_servers
Листинг 4. Сценарий для создания хранимой процедуры usp_help_backup_status