Доставка журналов - RESTORE WITH STANDBY - на SQL Server 2012 постоянно ломается

Мы используем доставку журналов и RESTORE WITH STANDBYна SQL Server 2012, чтобы восстановить базу данных в режиме только для чтения для целей отчетности. Однако настройка доставки журналов не работает после восстановления одной или двух резервных копий журналов. Доставка журналов прерывается только тогда, когда она работает как RESTORE WITH STANDBY; RESTORE WITH NORECOVERYне вызывает никаких проблем.

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

Есть идеи, известные исправления?

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

Спасибо за все ваши ответы.

PS: выдержка из нашего журнала

25.02.2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, Выполняется, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, шаг задания журнала восстановления доставки журналов. ,, 2013-02-25 13: 00: 12.31 *** Ошибка: Не удалось применить файл резервной копии журнала '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' к вторичной базе данных "BulldogDB". (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.31 *** Ошибка: произошла ошибка при обработке журнала для базы данных «BulldogDB». Если возможно восстановить из резервной копии. Если резервная копия недоступна, может потребоваться перестроить журнал.
Во время восстановления произошла ошибка, препятствующая перезапуску базы данных BulldogDB (8: 0). Диагностируйте ошибки восстановления и исправляйте их или восстанавливайте из заведомо исправной резервной копии. Если ошибки не исправлены или ожидаются, обратитесь в службу технической поддержки.
RESTORE LOG завершается ненормально.
Обработано 0 страниц для базы данных «BulldogDB», файла «BulldogDB» для файла 1.
Обработано 1 страниц для базы данных «BulldogDB», файла «BulldogDB_log» в файле 1. (. Net SqlClient Data Provider) ***
2013-02-25 13: 00: 12.32 *** Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.32 Пропуск файла резервной копии журнала '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' для вторичной базы данных BulldogDB, так как файл не может быть проверен.
2013-02-25 13: 00: 12.32 *** Ошибка: не удалось записать историю / сообщение об ошибке. (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.32 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: при восстановлении режима доступа к базе данных произошла ошибка (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: при восстановлении режима доступа к базе данных произошла ошибка (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteScalar требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***
2013-02-25 13: 00: 12.33 Удаление старых файлов резервных копий журнала. Основная база данных: 'BulldogDB'
2013-02-25 13: 00: 12.33 *** Ошибка: не удалось записать историю / сообщение об ошибке (Microsoft.SqlServer.Management.LogShipping) ***
2013-02-25 13: 00: 12.33 *** Ошибка: ExecuteNonQuery требует открытого и доступного соединения. Текущее состояние соединения закрыто. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0

Если резервная копия журнала может быть восстановлена, когда вторичная база данных находится в NORECOVERY, и происходит сбой только тогда, когда она находится в режиме READ-ONLY / STANDBY, тогда я бы предположил, что сами резервные копии журнала исправны и не повреждены.

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

В режиме ожидания Вторичное восстановление отключает пользователей только при запуске задания, после запуска пользователи могут подключиться ... и это остановит процесс восстановления с ошибкой об "исключительных доступах". Я получил службу, которая пыталась подключиться к резервной базе данных во время восстановления. Это сделало процесс восстановления прерываться после 1-10 / 100 восстановленных файлов.