Symptômes
Prenons l’exemple du scénario suivant :
-
Vous exécutez Microsoft SQL Server 2014 ou Microsoft SQL Server 2012 Service Pack 2 (SP2) sur un serveur qui héberge le réplica secondaire d’un groupe de disponibilité dans le cadre d’une mise à niveau propagée.
-
Vous avez appliqué une des mises à jour de l’installation de SQL Server suivantes :
-
Mise à jour cumulative 5 SQL Server 2014
-
Mise à jour cumulative 4 SQL Server 2012 Service Pack 2
-
Mise à jour cumulative 3 SQL Server 2012 Service Pack 2
Important Le correctif mentionné dans cet article remplace ces mises à jour cumulatives. N’installez pas ces mises à jour si vous ne l’avez pas déjà fait.
-
-
Pour terminer l’installation de la mise à jour cumulative, vous devez redémarrer ce réplica secondaire.
-
Vous basculez le groupe de disponibilité qui bascule le réplica secondaire mis à jour vers le rôle principal.
Dans ce scénario, vous risquez de voir un ou plusieurs des problèmes suivants sur le serveur exécutant SQL Server et qui héberge désormais le réplica principal de votre groupe de disponibilités :
-
Les réplicas secondaires sont signalés comme ne se SYNCHRONISEnt pas.
-
Lorsque vous interrogez sys.dm_exec_requests, vous remarquez que le blocage du verrouillage intermittent entre les sessions utilisateur et une session dont la commande est signalée est « DB_STARTUP ». Vous pouvez également remarquer le blocage entre les commandes Checkpoint et DB_STARTUP .
-
Le blocage de la session qui récupérait l’une de vos bases de données de disponibilité est signalé dans le journal des erreurs SQL Server. Ces journaux sont similaires à ce qui suit : <date/time> spid<xx> Recovery is writing a checkpoint in database <dbname/dbid>. This isan informational message only. No user action is required.<date/time> spid<xx> Recovery completed for database <dbname/dbid> in <x> second(s) (analysis<x> ms, redo <x> ms, undo <x> ms.) This is an informational message only. No user action is required.…<date/time> spid<xx> Error: 1205, Severity: 13, State: 28.<date/time> spid<xx> Transaction (Process ID <xx>) was deadlocked on lock resources with anotherprocess and has been chosen as the deadlock victim. Rerun the transaction.
-
Si votre base de données de disponibilité est activée pour Microsoft SQL Server Service Broker, il est possible que les messages de votre base de données de disponibilité ne soient pas traités correctement. Si vous démarrez l’outil de suivi du générateur de profils, puis que vous capturez l’événement « Broker : message de classification », l’événement suivant est capturé :
9791, le Broker est désactivé dans la base de données de l’expéditeur.
Remarque Ce n’est pas un problème systématique. Vous pourrez peut-être appliquer ces mises à jour cumulatives sur une configuration AlwaysOn sans rencontrer ce problème. Si vous avez déjà appliqué ces mises à jour cumulatives et que vous n’avez pas remarqué ce problème, votre système n’est pas affecté et ces informations ne s’appliquent pas.
Cause
Ce problème survient en raison d’une situation de race entre les threads système et les connexions utilisateur. Cela empêche la logique de correction de la mise à jour cumulative d’obtenir les verrous requis pour achever le processus de mise à jour.
Résolution
Pour résoudre ce problème, appliquez le correctif critique à la demande (COD) suivant :
3034679 CORRECTIF : les groupes de disponibilité AlwaysOn pourront être signalés comme ne se SYNCHRONISEnt pasImportant Vous devez appliquer ce correctif COD au lieu des mises à jour cumulatives suivantes :
-
Mise à jour cumulative 5 SQL Server 2014
-
Mise à jour cumulative 4 SQL Server 2012 Service Pack 2
-
Mise à jour cumulative 3 SQL Server 2012 Service Pack 2
Remarque Si vous avez déjà appliqué ces mises à jour cumulatives, vous devez utiliser la solution de contournement suivante pour résoudre ce problème.
Solution de contournement
Étant donné que ce problème est lié à la contention entre la session utilisateur et la session de mise à niveau des bases de données de disponibilité alors que les bases de données sont transférées vers le rôle principal, vous devez supprimer cette contention pour permettre aux bases de données de se retrouver dans cet État. Pour contourner ce problème, procédez comme suit :
-
Essayez les méthodes suivantes dans l’ordre indiqué.
Méthode 1 : suppression de l’accès aux bases de donnéesSi les bases de données rencontrent les symptômes mentionnés dans la section « symptômes », utilisez l’une des procédures suivantes, ou les deux, si nécessaire pour éliminer la condition de blocage du verrouillage :
-
Les sys.dm_exec_requests de requête permettent de localiser les sessions dans lesquelles un blocage de verrouillage se produit dans les bases de données de disponibilité. Utilisez l’instruction Kill pour terminer ces sessions.
-
Désactivez ou arrêtez l’application qui accède aux bases de données de disponibilité.
Si la méthode 1 ne résout pas le problème, passez à la méthode 2.
Méthode 2 : redémarrer le serveur hôte SQL ServerLorsque l’accès des applications et l’accès utilisateur sont toujours désactivés, redémarrez l’instance de SQL Server qui héberge les bases de données de disponibilité affectées. Pour cela, procédez comme suit :
-
Désactiver le basculement automatique du groupe de disponibilité.
-
Redémarrez l’instance affectée de SQL Server qui héberge le réplica principal.
-
Activez le basculement automatique du groupe de disponibilité.
-
-
Après le rétablissement complet des bases de données affectées, rétablissez la connectivité des applications et des utilisateurs.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.
Références
Pour plus d’informations sur les mises à jour cumulatives affectées par ce problème, voir les articles suivants de la base de connaissances Microsoft :
