Symptômes
Supposez que vous utilisez Microsoft SQL Server 2016 ou 2017. Lorsqu’un groupe de disponibilité joint un groupe de disponibilité distribuée (DAG) existant immédiatement après la perte et la recréation du DAG, il est possible qu’il n'y ait pas accès au DAG et que vous receviez les messages d’erreur similaires à ce qui suit :
Toujours activé : notification de modification de la configuration AG du processus pour AG « AGName » dans l’État « avance » (7). Erreur : 41162, gravité : 16, État : 0. échec de la validation du numéro de séquence de la configuration du groupe de disponibilité «AGName». Le numéro de séquence en mémoire ne correspond pas au numéro de séquence persistante. Le groupe disponibilité et/ou le réplica de disponibilité locale seront redémarrés automatiquement. Aucune action de l’utilisateur n’est requise pour le moment. Toujours activé : AR'AGName'est en train de traiter la notification (type 64). Toujours activé : notification de modification de la configuration AG du processus pour AG «AGName» dans l’État « avance » (7). Toujours activé : AR'AGName'valide désormais l’intégrité AG dans WSFC. Toujours activé :AGNamede rôles de la fonction de migration de rôles [redirecteur]--> [redirecteur], déclencheur [VALIDATE_AG_CONFIG], État (WSFC = 1 ; métadonnées = 1). Toujours activé : AR'AGName'est en train de traiter la notification (type-2).
Par ailleurs, l’erreur 41162 peut mettre en place l’état de résolution AG et peut entraîner deux autres problèmes : erreur 19407 et échec d’assertion.
Error 19407 :
Les transactions non qualifiées sont restaurées dans la base de données dbname pour un changement d’état des groupes toujours à disponibilité. Fin de restauration estimée : 100%. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise. [HaDrDbMgr::SetPrimaryAR] Définir Primary comme AGID : AGNumber, ReplicaId : ReplicaNumber, AGDBID : AGDBNumbererreur : 19407, gravité : 16, État : 2. le bail entre le groupe de disponibilité « nom_groupe » et le cluster de basculement Windows Server a expiré. Un problème de connectivité s’est produit entre l’instance de SQL Server et le cluster de basculement du serveur Windows. Pour déterminer si le groupe de disponibilité ne fonctionne pas correctement, consultez la ressource de groupe disponibilité correspondante dans le cluster de basculement du serveur Windows.
Allégation
Toujours activé : notification de modification de la configuration AG du processus pour AG «DatabaseName» dans l’état « RESOLVING_NORMAL » (0).
Toujours activé : AR'DatabaseName'valide désormais l’intégrité AG dans WSFC.
Always On : GetTransportWithRef () est rejeté, car local AR n’est pas en ligne.
Informations sur l’état de la base de données «DatabaseName» : LSN renforcée : ' (34:304752:1) 'Commit LSN : ' (0:0:0) 'Time commit : 'Jan 1 1900 12:00AM'
Restauration (DatabaseName; 6) : début de l’arrêt des travailleurs de restauration en parallèle
* * Vider le thread-SPID = 0, EC = 0x000001F280CC7250
Vidage de la pile envoyé à FileLocation
* COMMENCER LE VIDAGE DE PILE :
* Emplacement : «FileLocation» : 1774
* Expression : GetContext ()->GetController ()->GetHadrArRoleExternal () = = HADR_ROLE_FORWARDING_SECONDARY
* SPID : SPID
* ID de processus : ProcessID
Erreur : 17066, gravité : 16, État : 1.
SQL Server assertion : file : < «FileLocation» >, line = 1774 Fail assertion = 'GetContext ()->GetController ()->GetHadrArRoleExternal () = = HADR_ROLE_FORWARDING_SECONDARY'. Cette erreur est éventuellement liée au minutage. Si l’erreur persiste après avoir reexécuté l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de données, ou redémarrez le serveur pour vérifier que les structures de données en mémoire ne sont pas endommagées.
Erreur : 3624, gravité : 20, État : 1.
La vérification de l’assertion du système a échoué. Pour plus d’informations, consultez le journal des erreurs SQL Server. En règle générale, un échec d’assertion est lié à un bogue logiciel ou à des données endommagées. Pour vérifier la corruption de la base de données, envisagez d’exécuter DBCC CHECKDB. Si vous avez accepté d’envoyer des vidages à Microsoft lors de l’installation, un mini-vidage sera envoyé à Microsoft. Il est possible qu’une mise à jour soit disponible à partir de Microsoft dans le Service Pack le plus récent ou dans un correctif du support technique.
Statut
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Résolution
Ce problème a été résolu dans la mise à jour cumulative suivante pour SQL Serveurs
À propos des mises à jour cumulatives pour SQL Server :
Chaque nouvelle mise à jour cumulative de SQL Server contient toutes les HotFix et tous les correctifs de sécurité inclus dans le précédent mise à jour cumulative. Consultez les dernières mises à jour cumulatives pour SQL Server :
Informations sur le correctif à la demande :
Ce problème a été résolu dans le correctif à la demande de SQL Server suivant :
Références
En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.
