10.2.3. Мониторинг доставки журналов

Получение информации о доставке журналов

Для получения информации о доставке журналов можно воспользоваться встроенным отчетом Management Studio. Чтобы получить отчет о доставке журналов необходимо:

1. Открыть Management Studio и в дереве Object Explorer выделить строку с именем сервера. Это может быть основной сервер, вторичный сервер или сервер мониторинга: в отчете будет показана только информация о той части доставки журналов, которая выполняется на этом сервере;

2. В окне Summary раскрыть список рядом с окном Report и выбрать тип отчета, который называется Transaction Log Shipping Status, рис. 10.2.

Рис. 10.2. Отчет о доставке журналов

Просмотр истории выполнения заданий

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

1. В окне Object Explorer выбрать контейнер SQL Server Agent для нужного сервера SQL Server Agent и раскрыть в нем контейнер Jobs (Задания). При настройке доставки журналов автоматически создаются четыре задания:

• LSBackup... — задание для резервного копирования журналов транзакций. Оно создается на основном сервере;

• LSCopy... — задание для сетевого копирования созданных файлов резервных копий. Оно создается на вторичном сервере;

• LSRestore... — задание для восстановления созданных резервных копий. Оно также создается на вторичном сервере;

• LSAlert... — задание для опроса основного и резервного сервера. Оно создается на сервере мониторинга.

2. Открыть контекстное меню для нужного задания и выбрать команду View History. Откроется окно просмотра истории выполнения заданий, аналогичное представленному на рис. 10.3.

Рис. 10.3. История выполнения задания

Создание отчетов о доставке журналов в своем собственном формате

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

1. Таблицы мониторинга:

log_shipping_monitor_alert, log_shipping_monitor_error_detail, log_shipping_monitor_history_detail, log_shipping_monitor_primary, log_shipping_monitor_secondary;

2. Хранимые процедуры для доступа к информации этих таблиц:

sp_help_log_shipping_monitor_primary, sp_help_log_shipping_monitor_secondary, sp_help_log_shipping_alert_job, sp_help_log_shipping_primary_database, sp_help_log_shipping_primary_secondary, sp_help_log_shipping_secondary_database.

10.2.4. Действия в случае сбоя основного сервера

План действий в случае сбоя основного сервера следующий:

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

• Либо отключить само задание - из контекстного меню для объекта задания в Object Explorer (контейнер SQL Server Agent Jobs) выбрать команду Disable.

• Либо отключить расписание для задания - открыть свойства задания, перейти на вкладку Schedules, выделить нужное расписание и нажать на кнопку Edit. Затем в свойствах расписания нужно снять флажок Enabled.

2. Вручную скопировать и восстановить те резервные копии журналов транзакций, которые были созданы на основном сервере, но еще не были восстановлены на вторичном сервере. Для этого можно вручную запустить на выполнение задания LSCopy... и LSRestore.... при помощи команды Start job из контекстного меню в Object Explorer.

3. Если нужно запретить работу с основным сервером, то можно произвести резервное копирование остатка журнала с параметром NORECOVERY. В этом случае будет не только создана резервная копия журнала транзакций, но и закрыт доступ к базе данных для пользователей.

4. Перевести базу данных на вторичном сервере в рабочее состояние из режима NORECOVERY или STANDBY (в зависимости от параметров доставки журналов). Для этого достаточно выполнить команду RESTORE DATABASE с параметром WITH RECOVERY, например: RESTORE DATABASE db1copy WITH RECOVERY

5. Переключить клиентские приложения на работу со вторичным сервером. В вашем распоряжении — следующие варианты:

1. переименовать вторичный сервер (а, возможно, и вторичной базы данных). После выполнения этой операции клиентские компьютеры начнут обращаться к новому серверу автоматически;

2. изменить записи на сервере DNS, если клиентские приложения для подключения используют полное доменное имя сервера;

3. изменить IP-адрес вторичного сервера, если клиенты подключаются по IP-адресу;

4. внести изменения в клиентские приложения:

• изменить имя сервера в клиентском приложении;

• применить псевдоним для SQL Server (псевдонимы придется создавать на каждом клиентском компьютере);

• изменить свойства источника данных ODBC (тоже на каждом клиенте).

В случае возврата в строй основного сервера:

1. Произвести резервное копирование вторичной базы данных (которая в настоящее время выполняет функцию рабочей).

2. Восстанавить эту резервную копию на основном сервере;

3. Перенацелить клиентские приложения вновь на основной сервер;

4. Удалить старые задания для резервного копирования, сетевого копирования, восстановления и мониторинга;

5. Настроить доставку журналов заново.