Échec d’assertion sur un serveur miroir lors de l’utilisation de SQL Server architecture de mise en miroir

  • Article

Cet article décrit un échec d’assertion microsoft SQL Server qui peut se produire sur un serveur partenaire lors de l’utilisation de SQL Server architecture de mise en miroir.

Version du produit d’origine : SQL Server 2014, SQL Server 2012, SQL Server 2008 R2, SQL Server 2008
Numéro de la base de connaissances d’origine : 2729953

Symptômes

Dans SQL Server architecture de mise en miroir, vous pouvez rencontrer une assertion SQL Server case activée échec sur le serveur partenaire (miroir). Dans ce cas, case activée le journal des erreurs SQL Server pour plus d’informations. Dans le journal, vous trouverez un message d’erreur qui ressemble au message suivant. Cette erreur signifie généralement que vous devez reconstruire la paire miroir.

assertion SQL Server : Fichier : loglock.cpp, line=834 Failed Assertion = 'result == LCK_OK' . Cette erreur peut être liée au minutage. Si l’erreur persiste après la réexécution de l’instruction, utilisez DBCC CHECKDB pour case activée la base de données à des fins d’intégrité structurelle, ou redémarrez le serveur pour vous assurer que les structures de données en mémoire ne sont pas endommagées.

Erreur : 3624, Gravité : 20, État : 1.

En règle générale, un échec d’assertion est dû à un bogue logiciel ou à une altération des données. Pour case activée d’altération de la base de données, envisagez d’exécuter DBCC CHECKDB. Si vous acceptez d’envoyer des vidages à Microsoft pendant l’installation, un minidump est envoyé à Microsoft. Une mise à jour peut être disponible auprès de Microsoft dans le dernier Service Pack ou dans un QFE auprès du support technique.

Remarque

Lorsque ce problème se produit, un fichier minidump est généré dans le dossier SQL Server du journal des erreurs. Ce fichier a un nom qui ressemble au nom de fichier SQLDumpnnnn.mdmp .

Cause

Ce problème peut se produire dans différents scénarios. Chaque scénario a une cause et une résolution différentes, et chaque scénario peut provoquer le même message d’erreur et l’échec d’assertion.

Remarque

  • Bien que la signature d’erreur semble être très spécifique, l’erreur réelle est due à une assertion qui a échoué. Par exemple, l’erreur peut être due à une assertion qui effectue une case activée proactive dans le code SQL Server qui valide l’échec des conditions saines aussi proprement que possible au lieu de provoquer un plantage à l’échelle du processus.
  • Vous ne pouvez pas facilement déterminer la cause réelle. Les services de support technique Microsoft déterminent généralement la cause. Elle est généralement effectuée en collectant le fichier de sauvegarde complète de la base de données principale et les sauvegardes du journal des transactions qui couvrent l’heure du problème. En outre, un fichier de vidage complet du miroir peut être nécessaire pour reproduire le problème dans des paramètres spécifiques.

Résolution

Pour résoudre ce problème, obtenez le dernier correctif pour votre version de SQL Server. Pour plus d’informations, reportez-vous au tableau suivant.

Cause Article de la Base de connaissances Première correction dans
Comportement de verrouillage différent entre le principal et le miroir 2938828 CORRECTIF : la mise en miroir de bases de données atteint l’assertion et la session de mise en miroir affiche l’état suspendu dans SQL Server 2012 ou SQL Server 2014 2931693 Mise à jour cumulative 1 pour SQL Server 2014, 2931078 Mise à jour cumulative 9 pour SQL Server 2012 SP1
Insertion en bloc/BCP avec Check_Constraints OFF SQL Server 2012
Modification des clés de chiffrement : clé de master de base de données, clé de instance master serveur SQL Server 2012

Remarque

  • Dans le tableau précédent, la dernière colonne répertorie uniquement la première build qui contient le correctif. Étant donné que les builds SQL Server sont cumulatives, les builds ultérieures, telles que SQL Server 2014 SP1, contiennent ces correctifs. Toutefois, ces builds ne sont pas répertoriées dans le tableau.
  • Pour plus d’informations sur l’obtention du dernier Service Pack pour votre version de SQL Server, consultez Déterminer la version, l’édition et le niveau de mise à jour. Le scénario BCP/Insertion en bloc est un scénario courant qui reste non corrigé pour SQL Server 2008 et SQL Server 2008 R2, et il s’agit de la cause connue la plus probable des assertions lck_ok sur ces versions. Le problème a été résolu pour la première fois dans SQL Server 2012. La raison de ne pas résoudre ce problème dans les versions antérieures est qu’il nécessite une nouvelle architecture de SQL Server internes du journal des transactions. Une telle modification ne peut être incluse qu’avec une version majeure de SQL Server.

Voir aussi

Assertion lorsque vous exécutez l’insertion en bloc ou BCP