Log shipping - RIPRISTINA CON STANDBY - su SQL Server 2012 continua a rompersi

Stiamo utilizzando la distribuzione dei log e RESTORE WITH STANDBYsu SQL Server 2012 per ripristinare il database in modalità di sola lettura a scopo di report. Tuttavia, l'installazione del log shipping continua a rompersi dopo aver completato il ripristino di uno o due backup del log. Il log shipping si interrompe solo quando è in esecuzione come RESTORE WITH STANDBY; RESTORE WITH NORECOVERYnon causa alcun problema.

La mia unica intuizione al riguardo è che il database primario non è così dinamico. Pertanto, quando non ci sono transazioni, ciò causa problemi con il RESTOREprocesso, forse?

Qualche idea, correzioni conosciute?

L'ho fatto funzionare per alcuni giorni eseguendo un lavoro regolare che esegue un pesante aggiornamento su due tabelle. Quando il lavoro ha smesso di eseguire l'installazione del log shipping non è riuscito rapidamente, impossibile elaborare il file .trn. Ho ripristinato il log shipping e ho provato a vedere se avrebbe continuato a funzionare semplicemente facendo un piccolo aggiornamento, modificando il valore di una colonna di un record in una tabella, chiunque non riuscisse ancora.

Grazie per tutte le tue risposte.

PS: un estratto dal nostro registro

25/02/2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, In Progress, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, Step del processo di log del ripristino della spedizione del log., 25-02-2013 13: 00: 12.31 *** Errore: Impossibile applicare il file di backup del registro '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' al database secondario 'BulldogDB'. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.31 *** Errore: si è verificato un errore durante l'elaborazione del registro per il database 'BulldogDB'. Se possibile ripristinare dal backup. Se un backup non è disponibile, potrebbe essere necessario ricostruire il registro.
Si è verificato un errore durante il ripristino che impedisce il riavvio del database "BulldogDB" (8: 0). Diagnosticare gli errori di ripristino e correggerli o ripristinarli da un backup valido noto. Se gli errori non vengono corretti o previsti, contattare l'assistenza tecnica.
RESTORE LOG si sta chiudendo in modo anomalo.
0 pagine elaborate per il file 'BulldogDB' del database 'BulldogDB' sul file 1.
Elaborate 1 pagine per il file 'BulldogDB' del database 'BulldogDB_log' sul file 1. (. Net SqlClient Data Provider) ***
25-02-2013 13: 00: 12.32 *** Errore: impossibile registrare la cronologia / messaggio di errore. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.32 *** Errore: ExecuteNonQuery richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25/02/2013 13: 00: 12.32 Salto del file di backup del registro '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' per il database secondario 'BulldogDB' perché non è stato possibile verificare il file.
25-02-2013 13: 00: 12.32 *** Errore: impossibile registrare la cronologia / messaggio di errore. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.32 *** Errore: ExecuteNonQuery richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25/02/2013 13: 00: 12.33 *** Errore: si è verificato un errore durante il ripristino della modalità di accesso al database. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.33 *** Errore: ExecuteScalar richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25-02-2013 13: 00: 12.33 *** Errore: impossibile registrare la cronologia / messaggio di errore. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.33 *** Errore: ExecuteNonQuery richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25/02/2013 13: 00: 12.33 *** Errore: si è verificato un errore durante il ripristino della modalità di accesso al database. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.33 *** Errore: ExecuteScalar richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25-02-2013 13: 00: 12.33 *** Errore: impossibile registrare la cronologia / messaggio di errore. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.33 *** Errore: ExecuteNonQuery richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***
25-02-2013 13: 00: 12.33 Eliminazione di vecchi file di backup del registro. Database primario: 'BulldogDB'
25-02-2013 13: 00: 12.33 *** Errore: impossibile registrare la cronologia / messaggio di errore. (Microsoft.SqlServer.Management.LogShipping) ***
25/02/2013 13: 00: 12.33 *** Errore: ExecuteNonQuery richiede una connessione aperta e disponibile. Lo stato corrente della connessione è chiuso. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0

Se i backup del log sono in grado di essere ripristinati mentre il database secondario è in NORECOVERY e fallisce solo quando è in READ-ONLY / STANDBY, suppongo che i backup dei log stessi siano ok e non danneggiati.

È possibile che il componente di report disponga di una connessione aperta al database, pertanto durante il ripristino del file di registro non è possibile ottenere una connessione esclusiva al database a causa delle connessioni aperte. Ci sarebbe un'opzione quando si imposta il log shipping per disconnettere tutte le connessioni per consentirgli di ripristinare il backup del log.

In standby Il ripristino secondario disconnette gli utenti solo all'avvio del lavoro, dopo l'avvio gli utenti possono connettersi ... e questo interromperà il processo di ripristino con errore "accesso esclusivo". Ho ricevuto un servizio che ha tentato di connettersi al database di standby durante il ripristino. Ciò ha comportato l'interruzione del processo di ripristino dopo 1-10 / 100 file ripristinati.