Доставка журналів - ВІДНОВЛЕННЯ З 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. (. Чистий постачальник даних SqlClient) ***
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 відновлених файлів.