Obtenir une erreur lors de la restauration des journaux dans un environnement LOG SHIPPING

Question

Je travaille avec SQL Server 2005 SP2.

J'ai un environnement de travail et un environnement stable de LOG SHIPPING depuis un certain temps.

Hier, le travail de restauration de l'envoi de journaux dans le serveur DR a échoué avec l'erreur de verrouillage (le journal commence à partir de la dernière ligne et monte):

05:02:38.34 *** Error: The log backup file 'C:\database\LogShipping\20100927021501.trn' was verified but could not be applied to secondary database '' 
05:02:37.42 *** Error: Could not apply log backup file 'C:\database\LogShipping\20100927021501.trn' to secondary database ''. 
05:02:37.42 *** Error: Exclusive access could not be obtained because the database is in use. 
05:02:17.04 Restored log backup file. Secondary DB: ''<c/> File: 'C:\database\LogShipping\.trn' 
05:00:01.01 Disconnecting users. Secondary DB: '' 
05:00:00.64 Starting transaction log restore. Secondary ID: 'f89bba95-6fa8-4ee3-8883-3bb3b63f6127'<nl/> 
05:00:00.64 Retrieving restore settings. Secondary ID: 'f89bba95-6fa8-4ee3-8883-3bb3b63f6127'<nl/> 
05:00:00.65 Retrieved common restore settings. Primary Server: ''<c/> Primary Database: ''<c/> 
Backup Destination Directory: 'C:\database\LogShipping'<c/> File Retention Period: 4320 minute(s)<nl/> 
05:00:00.65 Retrieved database restore settings. Secondary Database: ''<c/> Restore Delay: 0<c/> Restore All: True<c/> Restore Mode: Standby<c/> 
Disconnect Users: True<c/> Last Restored File: C:\database\LogShipping\20100927014500.trn<c/> Block Size: Not Specified<c/> Buffer Count: Not Specified<c/> Max Transfer Size: Not Specified 
05:00:00.54 ----- START OF TRANSACTION LOG RESTORE ----- 

La prochaine tâche de restauration, réussi sans problèmes, et il restaurent tous les journaux, même les plus anciens.

Qu'ont-il arrivé?

J'ai la case « Déconnecter les utilisateurs dans la base de données lors de la restauration des sauvegardes » cochée dans la configuration SHIPPING LOG.

Vous pouvez voir dans le journal ci-dessus qu'il existe un stade DISCONNECTING USERS.

Lors de mes recherches sur Google, je ne trouve que des liens qui me demandent de cocher la case ci-dessus, ou de créer une procédure qui tue les sessions et les exécute avant le travail de restauration.

Mais - il y avait une déconnexion des utilisateurs avant le travail de restauration. peut-être un utilisateur applicatif a-t-il essayé de connecter le DB en une fraction de seconde entre la fin de la première restauration du journal et la seconde restauration du journal?

Si oui, comment puis-je empêcher que cela se produise?

Merci, Roni.

Answer 1

Pour y remédier, définissez la propriété Retry Job pour le LS travail de restauration Agent SQL. Ce ne serait pas entièrement infaillible. Cependant, vous pouvez réduire la probabilité qu'un utilisateur se connecte dans cette fraction de seconde. Trois tentatives devraient suffire.

Answer 2

J'ai couru dans cela aussi. Les problèmes sont, lorsque l'api d'expédition de journal tue les connexions ouvertes à la base de données, il exécute ALTER DATABASE SET SINGLE_USER WITH ROLLBACK IMMEDIATE. Techniquement, s'il y a une tentative de connexion de la part de l'application immédiatement après cela, elle obtiendra la session utilisateur unique avant l'envoi du journal.

Answer 3

Ue Déclencheur de connexion Activez et désactivez avant et après l'exécution du travail de restauration pour un utilisateur ou un hôte particulier afin d'empêcher l'établissement de connexions au DB pour une période de temps donnée.