Задание резервного копирования журнала транзакций доставки выполняется непрерывно

Question

В рамках нашего решения DR мы попытались включить доставку журналов для базы данных с высокой нагрузкой транзакций. Пока конфигурация завершается успешно, первое задание резервного копирования журнала транзакций, которое запускается после завершения конфигурации доставки журналов, выполняется непрерывно и имеет экспоненциальный размер. В одном случае это первое задание резервного копирования журнала транзакций выполнялось в течение 12 часов с размером файла, в 3 раза превышающим размер файла полной резервной копии 27 ГБ для базы данных. Мы убили этот процесс. Недавно мы попытались изменить подход, используя дифференциал, как описано ниже, но задание резервного копирования журнала транзакций все еще выполнялось с постоянно растущим размером файла.

Этот процесс был запущен в выходные дни с низким уровнем использования

• 7:46 утра - начинается конфигурация доставки журналов

• 9:32 утра - файл резервной копии хранится в общей сетевой папке. Размер файла составляет 26,1 ГБ

• 21:30 - Конфигурация доставки журналов завершена. - Я отключаю задания резервного копирования, копирования и восстановления журналов

• 9:31 вечера - я ввел команду для резервного копирования базы данных с дифференциалом

• 9:33 вечера - Дифференциал завершается с размером файла 768 МБ. - Я снова включаю задания резервного копирования и копирования, чтобы продвинуть этот процесс после дифференциала - Я копирую файл дифференциала во вторичное местоположение

• 9:45 вечера - запускается первое задание резервного копирования журнала транзакций

• 9:59 вечера - После того, как дифференциальный файл скопирован, я восстанавливаю базу данных на Вторичном, используя дифференциальный

• 23:02 - Восстановление дифференциала все еще выполняется. Задание резервного копирования журнала транзакций, созданное в 9:45, все еще выполняется с размером файла 28 ГБ и продолжает расти.

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

Кто-нибудь испытывал этот сценарий раньше? Можно ли что-то изменить, чтобы сократить время выполнения задания резервного копирования журнала транзакций? Учитывая большую нагрузку на транзакции, я хотел бы знать, будет ли лучше реализовать альтернативное решение DR для этой конкретной базы данных.

Answer 1

Я знаю, что это может быть старым, но добавив несколько указателей, которые помогут вам.

1. Когда для базы данных задана модель восстановления Bulklogged,Tlog также будет содержать копии файлов данных, поэтому ваш размер Tlogs будет большим

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

dbcc traceon (3004, 3605, -1)

3. Флаг восстановления трассировки можно использовать для восстановления.

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

http://www.sqlskills.com/blogs/paul/why-could-restoring-a-log-shipping-log-backup-be-slow/

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

Вы также можете проверить наличие задержки в сети с помощью счетчиков perfmon.