При доставке журнала транзакций SQL не удается восстановить базу данных в режим ожидания

Question

Я установил доставку журналов транзакций между двумя серверами SQL 2014, кажется, что все настроено правильно, но когда восстановление происходит, оно кажется неудачным, если.trn действительно маленький, например, 7k.

Не уверен, имеет ли это какое-либо отношение к этому, но это единственное, что отличается.

Вот журналы от задания восстановления.

Дата 25/04/2016 22:59:24 Журнал заданий (LSRestore_IRIS_WebStock)

ID шага 1 Имя задания сервера HERA LSRestore_IRIS_WebStock Имя шага Записать шаг задания журнала восстановления доставки. Продолжительность 00:00:04 Sql Серьезность 0 Sql ID сообщения 0 Оператор отправил письмо Оператору Сеть отправлено
Попытки постраничных попыток оператора 0

Сообщение 2016-04-25 22:59:28.71 Ошибка: не удалось применить файл резервной копии журнала "E:\ShippingLogs\WebStock\WebStock_20160425033000.trn" к вторичной базе данных "WebStock".(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.71 Ошибка: при обработке журнала для базы данных "WebStock" произошла ошибка. Если возможно, восстановите из резервной копии. Если резервная копия недоступна, может потребоваться перестроить журнал. Во время восстановления произошла ошибка, препятствующая перезапуску базы данных WebStock (12:0). Диагностируйте ошибки восстановления и исправляйте их или восстанавливайте из заведомо исправной резервной копии. Если ошибки не исправлены или не ожидаются, обратитесь в службу технической поддержки.

RESTORE LOG завершается ненормально. Обработано 0 страниц для базы данных 'WebStock', файл 'WebStock' в файле 1. Обработано 1 страниц для базы данных 'WebStock', файл 'WebStock_log' в файле 1.(Поставщик данных Net SqlClient) 2016-04-25 22:59: 28.71 Ошибка: не удалось записать историю / сообщение об ошибке.(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Пропуск файла резервной копии журнала 'E:\ShippingLogs\WebStock\WebStock_20160425033000.trn' для вторичной базы данных 'WebStock', так как файл не может быть проверено. 2016-04-25 22:59:28.73 Ошибка: не удалось записать историю / сообщение об ошибке.(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: Произошла ошибка при восстановлении режима доступа к базе данных. (Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59: 28.73 Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59: 28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: не удалось применить файл резервной копии журнала 'E:\ShippingLogs\WebStock\WebStock_20160425034500.trn' к вторичной базе данных 'WebStock'.(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59: 28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Пропуск файла резервной копии журнала 'E:\ShippingLogs\WebStock\WebStock_20160425034500.trn' для вторичной базы данных 'WebStock', так как файл не может быть проверено. 2016-04-25 22:59:28.73 Ошибка: не удалось записать историю / сообщение об ошибке.(Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59:28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: Произошла ошибка при восстановлении режима доступа к базе данных. (Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59: 28.73 Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) 2016-04-25 22:59: 28.73 Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто.(System.Data) 2016-04-25 22:59:28.73 Ошибка: не удалось применить файл резервной копии журнала 'E:\ShippingLogs\WebStock\WebStock_20160425040000.trn' к вторичной базе данных 'WebStock'. (Microsoft.SqlServer.Management.LogShipp

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

Произойдет ли восстановление, если журнал будет пуст?

Answer 1

Из данных,

Журнал в этом наборе резервных копий начинается с номера LSN <#>, который является слишком новым для применения к базе данных.

Это ошибка, которая наблюдается в различных сценариях доставки журналов.

2016-07-25 07: 37: 12.34 * Ошибка: файл 'C:\LS_Secondary\LogShippingDB_20160725020411.trn' является слишком новым для применения к вторичной базе данных 'LogShippingDB'. (Microsoft.SqlServer.Management.LogShipping) *

2016-07-25 07: 37: 12.34 * Ошибка: журнал в этом наборе резервных копий начинается с номера LSN 79000000014400001, который слишком поздний для применения к базе данных. Более раннюю резервную копию журнала, включающую LSN 79000000011200001, можно восстановить. RESTORE LOG завершается ненормально (поставщик данных Net. SqlClient) *

Доставка журналов основана на том, что каждый журнал резервных копий транзакций образует цепочку с предыдущей резервной копией журнала транзакций. Если мы попытаемся пропустить любую из резервных копий журнала, то возникнет ошибка выше. Чтобы найти недостающую резервную копию, мы можем использовать таблицы истории резервного копирования MSDB или файл ERRORLOG. Оба они содержат информацию о типе резервной копии, месте и т. Д.

2016-07-25 07: 32: 11.95 Резервное копирование журнала. База данных: LogShippingDB, дата создания (время): 2016/07/24(21:53:30), первый LSN: 79:48:1, последний LSN: 79:80:1, количество устройств дампа: 1, информация об устройстве: (ФАЙЛ =1, ТИП = ДИСК: {'C: \ LS \ LogShippingDB_20160725020211.trn'}). Это только информационное сообщение. От пользователя не потребуется никаких действий.

2016-07-25 07: 33: 11.83 Резервное копирование журнала. База данных: LogShippingDB, дата создания (время): 2016/07/24(21:53:30), первый LSN: 79:80:1, последний LSN: 79: 112: 1, количество устройств дампа: 1, информация об устройстве: (ФАЙЛ =1, ТИП = ДИСК: {'C: \ LS \ LogShippingDB_20160725020311.trn'}). Это только информационное сообщение. От пользователя не потребуется никаких действий.

2016-07-25 07: 33: 32.22 Резервное копирование журнала. База данных: LogShippingDB, дата создания (время): 2016/07/24(21:53:30), первый LSN: 79: 112: 1, последний LSN: 79:144:1, количество устройств дампа: 1, информация об устройстве: (FILE=1, TYPE=DISK: {'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\Extra.trn'}). Это только информационное сообщение. От пользователя не потребуется никаких действий.

2016-07-25 07: 34: 11.69 Резервное копирование журнала резервного копирования. База данных: LogShippingDB, дата создания (время): 2016/07/24(21:53:30), первый LSN: 79:144:1, последний LSN: 79:176:1, количество устройств дампа: 1, информация об устройстве: (ФАЙЛ =1, ТИП = ДИСК: {'C:\LS\LogShippingDB_20160725020411.trn'}). Это только информационное сообщение. От пользователя не потребуется никаких действий.

Мы выделили резервную копию журнала, которая не работает. Теперь нам нужно вернуться в прошлое и выяснить, почему предыдущий журнал не был восстановлен на вторичном сервере.

Решение:

Найдите недостающую резервную копию журнала и восстановите ее вручную во вторичной базе данных. После восстановления следующие резервные копии будут загружены автоматически.

Answer 2

http://sqlmag.com/database-high-availability/how-restart-failed-log-shipping-quickly

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

Это все о ЛСН

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