Symptômes
Lorsque vous utilisez la mise en miroir de base de données dans Microsoft SQL Server 2012 ou Microsoft SQL Server 2014, vous pouvez appuyer sur une condition d’assertion et la mise en miroir de la base de données passe à l’état suspendu.
Cause
Le problème se produit car, lors de l’attribution d’une nouvelle page, SQL Server obtient un verrou X sur la nouvelle page. SQL Server placera le hobt_id (segment de mémoire ou ID d’arborescence B) auquel appartient la nouvelle page dans la demande de verrouillage. Toutefois, SQL Server ne peut pas placer l’hobt_id dans le journal de mise en miroir et génère un autre comportement de verrouillage entre le volume principal et le miroir. Cela peut être expliqué en détail comme suit :
-
T1 Placez un verrou IX sur la page P1.
-
T2 effectue un fractionnement de page sur P1 et alloue une nouvelle page P2, une transaction système TX est utilisée ici, elle contient un verrou X sur P2. Ici, SQL Server n’a pas placé la hobt_id dans le journal en miroir.
-
TX effectue une migration de verrou pour T1 pour déplacer le verrou IX de P1 vers P2.
-
TX validée, désormais T2 peut utiliser la page P2 et T2 obtenir un autre verrou IX sur la page P2.
-
T1 validée, il s’agit de la seule personne qui détient un verrou IX sur P2.
-
Après avoir inséré un grand nombre d’insertions, une escalade de verrou se produit, sur le principal, T2 libère le IX sur P2, mais sur le miroir, lors de l’augmentation du verrou, T2 n’a pas libéré le verrou IX.
-
Après la suppression de ce nombre, la page P2 devient vide et est désallouée.
-
T3 a besoin d’une nouvelle page, ce qui a pour effet d’attribuer le mode P2, cela nécessite un verrou X, mais sur le miroir, cette étape a échoué en raison de l’étape 6.
Sur le miroir, l’étape 6 ne libère pas le verrou IX, car le hobt_id dans le bloc de verrouillage est incorrect. Ce hobt_id incorrecte est fourni lors de l’étape 2, car SQL Server ne place pas le hobt_id dans le journal de mise en miroir. en règle générale, vous ne voyez pas de problème, car la fonction TX de l’étape 2 est très courte, et le bloc de verrouillage avec une hobt_id incorrecte sera disponible lors de la validation. Toutefois, en raison de la migration de verrou dans step3 et des étapes suivantes (4 et 5), ce bloc de verrouillage avec un hobt_id incorrect est conservé et est finalement à l’origine du problème. Ce problème ne se pose pas pour la première fois, car elle utilise un hobt_id correct à l’étape 2. Toutefois, l’enregistrement du journal n’a pas de hobt_id correcte.
Résolution
Le problème a été résolu dans la mise à jour cumulative suivante de SQL Server.
Mise à jour cumulative 1 pour SQL Server 2014 /en-us/help/2931693
Mise à jour cumulative 9 pour SQL Server 2012 SP1 /en-us/help/2931078
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Solution de contournement
Pour contourner ce problème, réinitialisez le miroir pour mettre fin à l’état suspendu.
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.
