Envoi de journaux - RESTAURER AVEC STANDBY - sur SQL Server 2012 ne cesse de casser

10

Nous utilisons l'envoi de journaux et RESTORE WITH STANDBYsur SQL Server 2012 afin de restaurer la base de données en mode lecture seule à des fins de génération de rapports. Cependant, la configuration de l'envoi des journaux continue de se rompre après la restauration d'une ou deux sauvegardes de journaux. L'envoi de journaux ne se brise que lorsqu'il s'exécute en tant que RESTORE WITH STANDBY; RESTORE WITH NORECOVERYne pose aucun problème.

Ma seule intuition à ce sujet est que la base de données principale n'est pas aussi dynamique. Par conséquent, lorsqu'il n'y a pas de transactions, cela provoque des problèmes avec le RESTOREprocessus, peut-être?

Des idées, des correctifs connus?

Je l'ai fait fonctionner pendant quelques jours en exécutant un travail régulier qui effectue une mise à jour lourde sur deux tables. Lorsque le travail a cessé d'exécuter, la configuration de l'envoi des journaux a rapidement échoué, impossible de traiter le fichier .trn. J'ai réinitialisé l'envoi de journaux et j'ai essayé de voir s'il continuerait à fonctionner en faisant juste une petite mise à jour, en changeant la valeur d'une colonne d'un enregistrement dans une table, quelle que soit l'échec.

Merci pour toutes vos réponses.

PS: Un extrait de notre journal

25/02/2013 13: 00: 00, LSRestore_DBDB01-A_BulldogDB, En cours, 1, DBREPORTS, LSRestore_DBDB01-A_BulldogDB, Étape de travail du journal de restauration de l'envoi de journaux., 2013-02-25 13: 00: 12.31 *** Erreur: Impossible d'appliquer le fichier de sauvegarde du journal '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' à la base de données secondaire 'BulldogDB'. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.31 *** Erreur: Une erreur s'est produite lors du traitement du journal de la base de données 'BulldogDB'. Si possible, restaurez à partir de la sauvegarde. Si aucune sauvegarde n'est disponible, il peut être nécessaire de reconstruire le journal.
Une erreur s'est produite lors de la récupération, empêchant la base de données 'BulldogDB' (8: 0) de redémarrer. Diagnostiquez les erreurs de récupération et corrigez-les ou effectuez une restauration à partir d'une bonne sauvegarde connue. Si les erreurs ne sont pas corrigées ou attendues, contactez le support technique.
RESTORE LOG se termine anormalement.
0 pages traitées pour le fichier «BulldogDB» de la base de données «BulldogDB» dans le fichier 1.
1 page traitée pour le fichier «BulldogDB» de la base de données «BulldogDB_log» dans le fichier 1. (. Net SqlClient Data Provider) ***
25-02-2013 13: 00: 12.32 *** Erreur: impossible de consigner l'historique / message d'erreur. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.32 *** Erreur: ExecuteNonQuery nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
2013-02-25 13: 00: 12.32 Ignorer le fichier de sauvegarde du journal '\\ dbsan01 \ DBBackups \ LSBackup_BulldogDB \ BulldogDB_20130225180000.trn' pour la base de données secondaire 'BulldogDB' car le fichier n'a pas pu être vérifié.
25-02-2013 13: 00: 12.32 *** Erreur: impossible de consigner l'historique / message d'erreur. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.32 *** Erreur: ExecuteNonQuery nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
25/02/2013 13: 00: 12.33 *** Erreur: une erreur s'est produite lors de la restauration du mode d'accès à la base de données. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.33 *** Erreur: ExecuteScalar nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
25-02-2013 13: 00: 12.33 *** Erreur: impossible de consigner l'historique / message d'erreur. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.33 *** Erreur: ExecuteNonQuery nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
25/02/2013 13: 00: 12.33 *** Erreur: une erreur s'est produite lors de la restauration du mode d'accès à la base de données. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.33 *** Erreur: ExecuteScalar nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
25-02-2013 13: 00: 12.33 *** Erreur: impossible de consigner l'historique / message d'erreur. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.33 *** Erreur: ExecuteNonQuery nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***
2013-02-25 13: 00: 12.33 Suppression des anciens fichiers de sauvegarde du journal. Base de données primaire: 'BulldogDB'
25-02-2013 13: 00: 12.33 *** Erreur: impossible de consigner l'historique / message d'erreur. (Microsoft.SqlServer.Management.LogShipping) ***
25-02-2013 13: 00: 12.33 *** Erreur: ExecuteNonQuery nécessite une connexion ouverte et disponible. L'état actuel de la connexion est fermé. (System.Data) ***, 00: 00: 12,0,0 ,,,, 0
sql-server sql-server-2012 log-shipping Mendel
la source
Il se rompt en ce que le travail LS_Restore ne peut pas appliquer la sauvegarde du journal des transactions. Je viens de réinitialiser l'envoi de journaux afin que toutes les informations du journal des erreurs soient supprimées de la base de données. Je les ai enregistrés quelque part, je les posterai quand je les trouverai. Merci.
Mendel
Nous obtenons quelque chose comme "Fichier de sauvegarde du journal de saut ... .trn pour la base de données secondaire 'DB' parce que le fichier n'a pas pu être vérifié . Je ne sais pas comment vous pourriez spécifiquement vérifier la corruption.
Mendel
Lien mis à jour: feedback.azure.com/forums/908035-sql-server/suggestions/… .
Anthony Horne

Réponses:

4

Si les sauvegardes de journaux peuvent être restaurées alors que la base de données secondaire est en NORECOVERY et échoue uniquement lorsqu'elle est en LECTURE SEULE / STANDBY, je suppose que les sauvegardes de journaux elles-mêmes sont correctes et non corrompues.

Il se peut que votre composant de génération de rapports dispose d'une connexion ouverte à la base de données. Par conséquent, lors de la restauration du fichier journal, il est impossible d'obtenir une connexion exclusive à la base de données en raison des connexions ouvertes. Il y aurait une option lors de la configuration de l'envoi de journaux pour déconnecter toutes les connexions afin de lui permettre de restaurer la sauvegarde des journaux.

Ian Chamberland
la source
1
C'est correct. Pour contourner ce problème, ne laissez pas les travaux d'envoi de journaux restaurer en mode veille, mais ajoutez une deuxième étape au travail qui sera restauré en mode veille. RESTORE DATABASE [base de données] avec STANDBY = N'standbyfile '. Une autre option serait que la sauvegarde du journal des transactions ne soit pas terminée, essayez d'ajouter un délai de 20 minutes pour les restaurations
Spörri
1

En veille, la restauration secondaire ne déconnecte les utilisateurs qu'au démarrage du travail, après le démarrage, les utilisateurs peuvent se connecter ... et cela arrêtera le processus de restauration avec une erreur sur les "accès exclusifs". J'ai obtenu un service qui a essayé de se connecter à la base de données de secours pendant la restauration. Cela a rendu le processus de restauration interrompu après 1-10 / 100 fichiers restaurés.

Wiedzm
la source