Мониторинг состояния и задержки доставки журналов (log shipping)

Команда

-- Summary (on the primary, secondary or monitor server):
EXEC master.sys.sp_help_log_shipping_monitor;

-- PRIMARY: when the last log backup was taken:
SELECT p.primary_server, p.primary_database,
       p.last_backup_date, p.last_backup_file,
       DATEDIFF(MINUTE, p.last_backup_date, GETDATE()) AS backup_age_min,
       p.backup_threshold                              AS threshold_min
FROM   msdb.dbo.log_shipping_monitor_primary p;

-- SECONDARY: copy and restore latency:
SELECT s.secondary_server, s.secondary_database, s.primary_server,
       s.last_copied_date, s.last_copied_file,
       s.last_restored_date, s.last_restored_file,
       s.last_restored_latency                           AS restore_latency_min,
       DATEDIFF(MINUTE, s.last_restored_date, GETDATE()) AS since_last_restore_min,
       s.restore_threshold                               AS threshold_min
FROM   msdb.dbo.log_shipping_monitor_secondary s;

-- Errors in the last 24 hours:
SELECT e.database_name, e.agent_type, e.log_time, e.message
FROM   msdb.dbo.log_shipping_monitor_error_detail e
WHERE  e.log_time >= DATEADD(HOUR, -24, GETDATE())
ORDER BY e.log_time DESC;

-- Secondary DB mode (RESTORING = NORECOVERY, is_in_standby = STANDBY):
SELECT name, state_desc, is_in_standby FROM sys.databases WHERE name = N'Musteri';

Что делает

Показывает возраст последней резервной копии журнала на первичном сервере, последний скопированный/восстановленный файл и задержку восстановления на вторичном вместе с их порогами, а также ошибки заданий backup/copy/restore за последние 24 часа.

Когда использовать

Когда срабатывает задание оповещения log shipping (ошибки 14420/14421), перед DR-тестом или для отчёта о том, насколько отстаёт вторичный сервер.

Внимание

Таблицы мониторинга содержат только ту сторону, которую видит сервер: таблица primary заполняется на первичном сервере/мониторе, таблица secondary — на вторичном/мониторе. Ручная (вне log shipping) резервная копия журнала разрывает цепочку, и задание restore продолжает падать; для разовых резервных копий журнала используйте COPY_ONLY. В режиме STANDBY пользовательские подключения разрываются перед каждым восстановлением. Запрос только на чтение; безопасно.