Résoudre les problèmes de basculement Always On groupes de disponibilité

Remarque

Pour automatiser l’analyse manuelle décrite dans cet article, consultez Utiliser AGDiag pour diagnostiquer les événements d’intégrité du groupe de disponibilité.

Cet article fournit des étapes de dépannage pour vous aider à déterminer la raison du basculement de votre groupe de disponibilité.

Symptômes et effets du problème d’intégrité Always On ou du basculement

Always On implémente une surveillance robuste de l’intégrité par le biais de différents mécanismes pour garantir l’intégrité du SQL Server instance Microsoft qui héberge le réplica principal, le cluster sous-jacent et l’intégrité du système. La charge de travail de production est momentanément interrompue lorsqu’un cluster Windows ou un problème d’intégrité Always On est identifié.

Lorsqu’une condition d’intégrité est détectée, la séquence d’événements suivante se produit généralement. Tout au long de cet utilitaire de résolution des problèmes, les événements d’intégrité sont mentionnés en référence aux événements suivants :

• Les réplicas de groupe de disponibilité et les bases de données passent du rôle principal au rôle de résolution.

• Les bases de données de groupe de disponibilité passent en mode hors connexion et ne sont plus accessibles.

• Le cluster Windows marque la ressource en cluster du groupe de disponibilité comme ayant échoué.

• Le cluster Windows tente de remettre en ligne le rôle de groupe de disponibilité (sur les réplica de partenaire de basculement automatique ou d’origine).

• Le rôle de groupe de disponibilité est correctement en ligne s’il est détecté comme sain par Always On et la surveillance de l’intégrité du cluster Windows.

En cas de réussite, les réplicas et les bases de données du groupe de disponibilité passent au rôle principal et les bases de données du groupe de disponibilité sont mises en ligne et sont accessibles par votre application.

Les applications ne peuvent pas accéder aux bases de données du groupe de disponibilité

Lorsqu’une condition d’intégrité est détectée, le groupe de disponibilité réplica et les bases de données passent au rôle Résolution, et les bases de données du groupe de disponibilité sont mises hors connexion. Une fois que le réplica est mis en ligne dans le rôle principal (sur le serveur réplica d’origine ou le serveur du partenaire de basculement réplica), le réplica et les bases de données passent à nouveau en ligne. Alors que les réplica et les bases de données sont en cours de résolution et sont hors connexion, toutes les applications qui tentent d’accéder à ces bases de données de groupe de disponibilité échouent et génèrent un message « Erreur 983 » : Unable to access availability database.... Cette erreur est également enregistrée dans le journal des erreurs microsoft SQL Server si SQL Server est configuré pour enregistrer les tentatives de connexion ayant échoué :

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

La période pendant laquelle le groupe de disponibilité est dans le rôle Résolution avant de revenir en ligne dans le rôle principal ne dure généralement que quelques secondes, voire moins d’une seconde.

Identifier et diagnostiquer les événements d’intégrité ou le basculement Always On groupe de disponibilité

1. Identifier les tendances Always On santé

Vous pouvez examiner un événement d’intégrité Always On unique, ou il peut y avoir une tendance récente ou continue de problèmes d’intégrité qui interrompent par intermittence la production. Les questions suivantes peuvent vous aider à affiner et à mettre en corrélation les modifications récentes dans votre environnement de production qui peuvent être liées à ces problèmes d’intégrité :

• Quand la tendance des événements Always On ou d’intégrité du cluster a-t-elle commencé ?
• Les événements d’intégrité se produisent-ils un jour donné ?
• Les événements d’intégrité se produisent-ils à une certaine heure de la journée ?
• Les événements d’intégrité se produisent-ils un certain jour ou une semaine du mois ?

Si vous détectez une tendance, case activée la maintenance planifiée sur le système (le système hôte dans un environnement virtuel), les lots ETL et d’autres travaux susceptibles d’être corrélés avec ces événements d’intégrité. Si le système est une machine virtuelle, recherchez dans le système hôte les modifications qui ont été éventuellement introduites au moment des pannes.

Envisagez des charges de travail de production ad hoc occupées qui peuvent être corrélées à l’heure des problèmes d’intégrité (par exemple, lorsque les utilisateurs se connectent pour la première fois au système ou après le retour des utilisateurs après le déjeuner).

Remarque

Il s’agit d’un bon moment pour envisager un plan de collecte de données de performances tout au long de la semaine et du mois. Pour mieux comprendre quand le système est le plus occupé, vous pouvez mesurer les compteurs de l’analyseur de performances Windows, tels que Processor Information::% Processor Time, Memory::Available MByteset MSSQLServer:SQL Statistics::Batch Requests/sec.

2. Passer en revue le journal du cluster

Le journal de cluster Windows est le journal le plus complet à utiliser pour identifier le type de Always On ou d’événement d’intégrité du cluster, ainsi que la condition d’intégrité détectée à l’origine de l’événement. Pour générer et ouvrir le journal du cluster, procédez comme suit :

Utilisez Windows PowerShell pour générer le journal de cluster Windows sur le nœud de cluster qui héberge le réplica principal au moment de l’événement d’intégrité. Par exemple, exécutez l’applet de commande suivante dans une fenêtre PowerShell avec élévation de privilèges en utilisant « sql19agn1 » comme nom de serveur basé sur SQL Server :

get-clusterlog -Node sql19agn1 -UseLocalTime     

Remarque

Par défaut, le fichier journal est créé dans %WINDIR%\cluster\reports.

3. Rechercher l’événement d’intégrité dans le journal du cluster

Always On utilise plusieurs mécanismes de surveillance de l’intégrité pour surveiller l’intégrité du groupe de disponibilité. En plus d’un événement d’intégrité de cluster Windows (dans lequel le cluster Windows détecte un problème d’intégrité parmi les nœuds du cluster), Always On a quatre types différents de vérifications d’intégrité :

• Le service SQL Server n’est pas en cours d’exécution
• Délai d’expiration d’un bail SQL Server
• Un délai d’attente case activée d’intégrité SQL Server
• Problème d’intégrité interne SQL Server

Vous pouvez localiser l’un de ces événements Always On d’intégrité spécifiques en recherchant la chaîne dans le journal du cluster, [hadrag] Resource Alive result 0. Cette chaîne est enregistrée dans le journal du cluster quand l’un de ces événements est détecté. Par exemple :

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

Vous pouvez utiliser un outil pour rechercher tous les événements d’intégrité dans le journal du cluster afin de générer un rapport récapitulatif des problèmes d’intégrité Always On. Cela peut être utile pour identifier les tendances chronologiques et déterminer si un type particulier de Always On état de santé est récurrent. La capture d’écran suivante montre comment utiliser un éditeur de texte (NotePad++, dans ce cas) pour rechercher toutes les lignes du journal du cluster qui contiennent la [hadrag] Resource Alive result 0 chaîne :

Déterminer le type de problème d’intégrité qui a déclenché le basculement

Pour déterminer le type de problèmes d’intégrité que vous trouvez dans le journal de cluster du réplica principal, comparez-les aux problèmes décrits dans les sections suivantes.

Événement d’intégrité du cluster

Le cluster Microsoft Windows surveille l’intégrité des serveurs membres du cluster. Si un problème d’intégrité est détecté, un serveur membre du cluster peut être supprimé du cluster. En outre, les ressources de cluster (y compris le rôle de groupe de disponibilité hébergé sur le serveur membre du cluster supprimé) sont déplacées vers le partenaire de basculement du groupe de disponibilité réplica s’il est configuré pour le basculement automatique.

Symptômes des événements d’intégrité du cluster

Voici un exemple d’événement d’intégrité de cluster dans le journal du cluster. Pour le trouver, vous pouvez rechercher Lost quorum ou Cluster service has terminated parce que l’un des deux peut être présent pendant le changement de rôle ou le basculement du groupe de disponibilité.

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

Une autre façon d’identifier cet événement consiste à effectuer une recherche dans le journal des événements système Windows :

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Diagnostiquer un événement d’intégrité de cluster

Les erreurs dans le journal des événements Windows (événements 1135 et 1177) suggèrent que la connectivité réseau est une cause de l’événement. Il s’agit de la raison la plus courante pour laquelle un problème d’intégrité de cluster est détecté. L’exemple suivant montre que les autres serveurs membres du cluster n’ont pas pu communiquer avec ce serveur qui héberge le réplica principal du groupe de disponibilité, et que ce problème a déclenché la suppression du nœud de cluster du cluster :

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

Vous pouvez rechercher dans le journal du cluster la preuve d’un échec de connexion au nœud. À partir de l’emplacement dans le journal du cluster où vous avez trouvé Lost quorum, recherchez des chaînes telles que Failed to connect to remote endpoint, unreachableet is broken.

Résoudre un événement d’intégrité de cluster

Assurez-vous que la surveillance de l’intégrité du cluster est appropriée pour l’environnement hôte. Pour plus d’informations sur les groupes de disponibilité SQL Server Always On hébergés dans Microsoft Azure, consultez Vue d’ensemble du cluster de basculement Windows Server - SQL Server sur les machines virtuelles Azure.

Si nécessaire, envisagez de contacter le support microsoft Windows Haute disponibilité pour ouvrir un incident de support.

SQL Server service est arrêté : événement d’intégrité Always On

Always On analyse de l’intégrité peut détecter si le service SQL Server qui héberge le réplica principal du groupe de disponibilité n’est plus en cours d’exécution.

Symptômes de l’arrêt du service SQL Server

Voici un exemple de rapport de journal de cluster pour le rôle de groupe de disponibilité « ag » qui indique un échec car QueryServiceStatusEx a retourné un ID de 0processus :

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

Diagnostiquer et résoudre les événements d’arrêt du service SQL

Vérifiez le journal des événements système Windows et SQL Server journal des erreurs pour rechercher un arrêt SQL Server inattendu.

Si SQL Server a été arrêté par un arrêt du système ou un arrêt administratif, l’entrée suivante s’affiche dans le journal des erreurs SQL Server :

2023-03-10 09 :38 :46.73 spid9s SQL Server se termine en réponse à une demande d’arrêt de Service Control Manager. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise.

Le journal des événements du système Windows affiche l’entrée d’erreur suivante :

Informations 10/03/2023 9 :41 :06 AM Service Control Manager 7036 None Le service SQL Server (MSSQLSERVER) est entré dans l’état arrêté.

Le journal des événements système Windows affiche l’entrée d’erreur suivante si SQL Server s’arrête de manière inattendue :

Erreur 10/03/2023 8 :37 :46 AM Service Control Manager 7034 None Le service SQL Server (MSSQLSERVER) s’est arrêté de manière inattendue. Il a fait cette ou ces 1 fois.

Vérifiez la fin du journal des erreurs SQL Server pour obtenir des indices. Si le journal des erreurs se termine brusquement, cela signifie qu’il a été arrêté par la force. Par instance, si SQL Server a été arrêté à l’aide du Gestionnaire des tâches, le rapport d’erreurs SQL Server ne révélerait aucune information sur les problèmes internes susceptibles d’avoir provoqué l’arrêt du processus.

Si un problème d’intégrité interne SQL Server a provoqué l’arrêt inattendu de SQL Server, il peut y avoir des indices d’une exception irrécupérable possible (y compris un diagnostic de fichier de vidage généré) à la fin du journal des erreurs SQL. Passez en revue les indices et prenez les mesures nécessaires. Si vous trouvez un fichier de vidage, envisagez de contacter le support microsoft SQL Server et fournissez le SQL Server contenu du journal des erreurs et du fichier de vidage pour une investigation plus approfondie.

Délai d’expiration du bail : événement d’intégrité Always On

Always On utilise un mécanisme de « bail » pour surveiller l’intégrité de l’ordinateur sur lequel SQL Server est installé. Le délai d’expiration du bail par défaut est de 20 secondes.

Symptômes des événements de délai d’expiration de bail Always On

Voici un exemple de sortie d’un délai d’expiration de bail Always On à partir du journal du cluster. Vous pouvez effectuer une recherche dans ces chaînes pour rechercher un délai d’expiration de bail dans le journal du cluster.

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

Pour plus d’informations sur le délai d’expiration du bail, consultez la section Mécanisme de bail dans Mécanismes et instructions relatives aux délais d’expiration des case activée de bail, de cluster et d’intégrité pour les groupes de disponibilité Always On.

Diagnostiquer et résoudre Always On événements de délai d’expiration de bail

Il existe deux problèmes main qui peuvent déclencher un délai d’expiration de bail :

• diagnostic de fichier de vidage SQL Server : quand SQL Server détecte certains événements d’intégrité internes, tels qu’une violation d’accès, une assertion ou un blocage du planificateur, il génère un fichier de vidage de diagnostic (.mdmp) dans le dossier SQL Server \LOG.

• Problème de performances à l’échelle du système : un délai d’expiration du bail n’indique pas nécessairement un problème d’intégrité SQL Server. Au lieu de cela, cela peut indiquer un problème d’intégrité à l’échelle du système qui affecte également l’intégrité du serveur SQL Server. Pour plus d’informations sur les étapes de résolution des problèmes, consultez MSSQLSERVER_19407.

1. Diagnostic du fichier de vidage SQL Server

SQL Server peut détecter un problème d’intégrité interne tel qu’une violation d’accès, une assertion ou des planificateurs bloqués. Dans ce cas, le programme génère un mini fichier de vidage (.mdmp) dans le dossier SQL Server \LOG du processus de SQL Server pour le diagnostic. Le processus SQL Server est figé pendant plusieurs secondes pendant que le fichier de vidage est écrit sur le disque. Pendant ce temps, tous les threads du processus SQL Server sont figés. Cela inclut le thread de bail surveillé par Always On surveillance de l’intégrité. Par conséquent, Always On peut détecter un délai d’expiration du bail.

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

Pour résoudre ce problème, le diagnostic du fichier de vidage doit être examiné pour la cause racine. Envisagez de contacter le support microsoft SQL Server pour fournir le SQL Server contenu du journal des erreurs et du fichier de vidage pour une investigation plus approfondie.

2. Utilisation élevée du processeur ou autre problème de performances système

Un délai d’expiration du bail indique un problème de performances qui affecte l’ensemble du système, y compris SQL Server. Pour diagnostiquer le problème système, Always On diagnostics d’intégrité signale les données de l’analyse des performances dans le journal du cluster et inclut l’événement de délai d’expiration du bail. Les données de performances s’étendent sur environ 50 secondes jusqu’à l’événement de délai d’expiration du bail, rapportant l’utilisation du processeur, la mémoire libre et la latence du disque.

Voici un exemple des données de performances signalées qui indiquent un délai d’expiration de bail dans le journal du cluster. Dans cet exemple de sortie, l’utilisation globale élevée du processeur peut être liée au délai d’expiration du bail.

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

Si les données de performances montrent une utilisation élevée du processeur, une mémoire insuffisante ou une latence de disque élevée au moment d’un délai d’expiration du bail, commencez à collecter des données Analyseur de performances pendant toute la journée sur le réplica principal pour examiner ces symptômes. En capturant les données de l’analyseur de performances sur une période plus longue, vous pouvez mieux identifier les valeurs de référence et de pointe pour ces ressources et surveiller les modifications apportées à ces ressources lorsqu’un délai d’expiration de bail se produit. Lorsque vous collectez ces données, déterminez s’il existe certaines charges de travail planifiées ou ad hoc dans SQL Server qui sont corrélées à l’heure de ces problèmes de ressources et événements d’intégrité.

Vous devez également capturer les compteurs qui signalent la même utilisation des ressources système, notamment les éléments suivants :

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

Délai d’expiration du case activée d’intégrité : événement d’intégrité Always On

Lorsqu’un groupe de disponibilité réplica passe au rôle principal, Always On surveillance de l’intégrité établit une connexion ODBC locale au SQL Server instance. Alors que Always On est connecté et qu’il effectue la surveillance, si SQL Server ne répond pas sur la connexion ODBC dans la période définie pour le délai d’attente de case activée d’intégrité du groupe de disponibilité (30 secondes par défaut), un événement de délai d’case activée d’intégrité est déclenché. Dans ce cas, le groupe de disponibilité passe du rôle principal au rôle Résolution et lance le basculement, s’il est configuré pour le faire.

Pour plus d’informations sur les délais d’case activée d’intégrité, consultez la section « Opération de délai d’expiration case activée d’intégrité » dans Mécanismes et instructions relatives aux délais d’case activée expiration de bail, de cluster et d’intégrité pour Always On groupes de disponibilité.

Voici un délai d’Always On d’intégrité case activée comme indiqué dans le journal du cluster :

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

Diagnostiquer et résoudre Always On événement de délai d’attente case activée d’intégrité

La section suivante vous aide à passer en revue les journaux d’SQL Server des événements de « miette de navigation » que vous pouvez trouver et qui sont corrélés à Always On intégrité case activée des délais d’attente détectés et signalés. Les journaux d’activité qui sont examinés ici incluent le journal du cluster (où le délai d’case activée d’intégrité est confirmé), les system_health journaux des événements étendus et SQL Server journaux des erreurs (tous deux trouvés dans le dossier SQL Server \LOG) et le journal des événements système Windows. Utilisez ces journaux et d’autres pour rechercher les événements de corrélation qui peuvent vous aider à définir la cause du délai d’case activée d’intégrité.

1. Rechercher les événements du planificateur ne produisant pas de rendement

Le délai d’case activée d’intégrité Always On est souvent dû à des événements « non rentables » dans SQL Server. Quand SQL Server détecte qu’un thread n’a pas été généré sur un planificateur, il signale qu’un événement de planificateur sans rendement s’est produit. Si vous voyez d’autres tâches sur le même planificateur qui ne reçoivent pas de temps processeur, il s’agit du signe principal d’un planificateur sans rendement. Ce comportement peut retarder l’exécution de ces tâches et « affamer » les charges de travail affectées à un certain planificateur de temps processeur.

Pour case activée pour les événements de planificateur ne produisant pas de rendement, procédez comme suit :

1. Vérifiez les journaux d’événements étendus SQL Server system_health pour déterminer si un événement de planificateur non générateur de rendement a été signalé au moment de l’Always On’case activée’événement de délai d’attente. Les événements qui ne produisent pas de rendement sont les suivants :

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. Ouvrez les journaux des événements étendus d’intégrité du système SQL Server sur le réplica principal jusqu’à l’heure de l’expiration de l’case activée d’intégrité suspecte.

3. Dans SQL Server Management Studio (SSMS), accédez à Ouvrir un fichier>, puis sélectionnez Fusionner les fichiers d’événements étendus.

4. Cliquez sur le bouton Ajouter.

5. Dans la boîte de dialogue Ouvrir le fichier, accédez aux fichiers dans le répertoire SQL Server \LOG.

6. Appuyez longuement sur Ctrl, puis sélectionnez les fichiers dont les noms commencent par system_health_xxx.xel.

7. Sélectionnez Ouvrir>OK.

8. Filtrez les résultats. Cliquez avec le bouton droit sur un événement sous la colonne de nom , puis sélectionnez Filtrer par cette valeur.

   

9. Définissez un filtre pour trier les lignes dans lesquelles les valeurs de la colonne name contiennent yield, comme illustré dans la capture d’écran suivante. Cette opération retourne toutes sortes d’événements qui peuvent avoir été enregistrés dans les journaux d’activité system_health .

   

10. Comparez les horodatages pour voir s’il y avait des événements sans rendement au moment de l’intégrité case activée délai d’expiration. Voici le délai d’case activée d’intégrité indiqué dans le journal du cluster :

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    Vous pouvez voir qu’il y avait des événements sans rendement qui se sont produits au moment de l’case activée d’expiration de l’intégrité.

    

Si des événements sans rendement sont détectés, case activée la cause de l’événement sans rendement. Envisagez de contacter l’équipe de support SQL Server pour examiner les événements qui ne produisent pas de rendement.

2. Vérifier le journal des erreurs SQL Server

Vérifiez dans le journal des erreurs SQL Server la corrélation des événements au moment de l’expiration de l’case activée d’intégrité. Ces événements peuvent fournir des « miettes de pain » qui suggèrent d’autres étapes pour définir la cause racine de l’intégrité case activée des délais d’expiration.

Par exemple, l’entrée de journal suivante indique qu’un délai d’case activée d’intégrité s’est produit dans le journal du cluster :

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

Dans le journal des erreurs SQL Server, dans les secondes qui suivent le délai d’case activée d’intégrité, SQL Server signale qu’il a détecté une latence d’E/S grave :

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

Passez en revue le journal des événements système pour connaître les indices système possibles qui pourraient être liés à l’événement de délai d’case activée d’intégrité. Lorsque vous examinez le journal des événements du système Windows, vous pouvez trouver un problème d’E/S signalé en même temps pour le même délai d’intégrité case activée d’expiration :

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

intégrité SQL Server : événement d’intégrité Always On

Always On surveille différents types d’événements d’intégrité SQL Server. Bien qu’il héberge un réplica principal de groupe de disponibilité, SQL Server exécute sp_server_diagnostics en continu des rapports sur SQL Server’intégrité à l’aide de différents composants. Quand des problèmes d’intégrité sont détectés, sp_server_diagnostics signale une erreur pour ce composant particulier, puis renvoie les résultats au processus de détection d’intégrité Always On. Lorsqu’une erreur est signalée, le rôle Groupe de disponibilité affiche l’état d’échec et le basculement possible si le groupe de disponibilité est configuré pour ce faire.

Symptômes des événements de santé Always On SQL Server

Voici un exemple de problème d’intégrité SQL Server signalé par sp_server_diagnostics dans le journal du cluster. SQL Server signale un état « erreur » dans le composant système pour Always On surveillance de l’intégrité, et le groupe de disponibilité « contoso-ag » est passé à un état d’échec.

Remarque

Un problème d’intégrité SQL Server génère un rapport similaire à celui du délai d’case activée d’intégrité. Les deux événements d’intégrité rapportent Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel. La distinction pour un événement d’intégrité SQL Server est qu’il signale que le composant SQL Server est passé de « avertissement » à « erreur ».

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

Diagnostiquer et résoudre les événements d’intégrité SQL Server

Le type de problème d’intégrité signalé par SQL Server intégrité doit dicter la direction de l’analyse de la cause racine.

Par défaut, lorsque vous déployez un groupe de disponibilité, est FAILURE_CONDITION_LEVEL défini sur trois. Cela active la surveillance de certains profils d’intégrité SQL Server, mais pas tous. Au niveau par défaut, Always On déclenche un événement d’intégrité quand SQL Server produit trop de fichiers de vidage, une violation d’accès en écriture ou un verrouillage tournant orphelin. La définition du groupe de disponibilité jusqu’au niveau quatre ou cinq étend les types de problèmes d’intégrité SQL Server qui sont surveillés. Pour plus d’informations sur les moniteurs d’intégrité SQL Server Always On, consultez Configurer une stratégie de basculement automatique flexible pour un groupe de disponibilité - SQL Server Always On.

Pour identifier le Always On problème d’intégrité spécifique, procédez comme suit :

1. Ouvrez les journaux des événements étendus de diagnostic de cluster SQL Server sur le réplica principal jusqu’au moment où l’événement d’intégrité SQL Server suspect s’est produit.

2. Dans SSMS, accédez à Ouvrir un fichier>, puis sélectionnez Fusionner les fichiers d’événements étendus.

3. Sélectionnez Ajouter.

4. Dans la boîte de dialogue Ouvrir le fichier, accédez aux fichiers dans le répertoire SQL Server \LOG.

5. Appuyez sur Ctrl, sélectionnez les fichiers dont le nom correspond <servername>_<instance>_SQLDIAG_xxx.xelà , puis sélectionnez Ouvrir>OK.

   

   Une nouvelle fenêtre à onglets s’affiche dans SSMS qui inclut les événements étendus, comme illustré dans la capture d’écran suivante.

6. Pour examiner un problème d’intégrité SQL Server, recherchez le dont state_desc la component_health_result valeur est error. Voici un exemple d’événement de composant système qui a signalé une erreur à Always On surveillance de l’intégrité :

   

7. Double-cliquez sur la colonne de données dans le volet inférieur. Cela ouvre les données détaillées du composant dans un nouveau volet de fenêtre SSMS pour révision. Voici à quoi ressemblent les données du composant système :

   

   Notez que les données « totalDumprequests=186 » indiquent qu’un trop grand nombre d’événements de diagnostic de fichier de vidage ont été générés sur cette SQL Server. C’est la raison pour laquelle le composant système a signalé un état d’erreur. Lorsque Always On analyse de l’intégrité reçoit cet état d’erreur, elle déclenche un événement d’intégrité de groupe de disponibilité. Vous pouvez également vérifier qu’aucune violation d’accès en écriture ou verrouillage tournant orphelin n’a été détectée à partir des données fournies dans les données du composant système.

   Si nécessaire, contactez SQL Server support technique pour ouvrir un incident de support afin d’obtenir de l’aide supplémentaire pour trouver la cause racine de ces problèmes de santé internes SQL Server.