Felsöka redundans för AlwaysOn-tillgänglighetsgrupper

Obs!

Information om hur du automatiserar den manuella analysen som beskrivs i den här artikeln finns i Använda AGDiag för att diagnostisera hälsohändelser för tillgänglighetsgrupper.

Den här artikeln innehåller felsökningssteg som hjälper dig att avgöra varför tillgänglighetsgruppen redväxade.

Symtom och effekter av Always On-hälsoproblem eller redundans

AlwaysOn implementerar robust hälsoövervakning via olika mekanismer för att säkerställa hälsotillståndet för den Microsoft SQL Server-instans som är värd för den primära repliken, det underliggande klustret och systemhälsan. Produktionsarbetsbelastningen avbryts tillfälligt när ett Windows-kluster eller AlwaysOn-hälsoproblem identifieras.

När ett hälsotillstånd identifieras inträffar vanligtvis följande händelsesekvens. I den här felsökaren nämns hälsohändelser i referensen till följande händelser:

• Tillgänglighetsgrupprepliker och databaser övergår från primär roll till att matcha roll.

• Tillgänglighetsgruppdatabaser övergår till offline och är inte längre tillgängliga.

• Windows-kluster markerar tillgänglighetsgruppens klustrade resurs som misslyckad.

• Windows-kluster försöker få tillgänglighetsgruppsrollen online igen (på den ursprungliga eller automatiska partnerrepliken för redundans).

• Tillgänglighetsgrupprollen är online om den har identifierats vara felfri av AlwaysOn och Windows-klusterhälsoövervakning.

Om det lyckas övergår tillgänglighetsgruppreplikerna och databaserna till den primära rollen och tillgänglighetsgruppdatabaserna är online och är tillgängliga för ditt program.

Program kan inte komma åt tillgänglighetsgruppdatabaserna

När ett hälsotillstånd identifieras övergår tillgänglighetsgrupprepliken och databaserna till rollen Matchning och tillgänglighetsgruppdatabaserna kopplas från. När repliken är online i den primära rollen (på den ursprungliga replikservern eller replikservern för redundanspartner) övergår repliken och databaserna igen till online. Medan repliken och databaserna löser och är offline misslyckas alla program som försöker komma åt dessa tillgänglighetsgruppdatabaser och genererar meddelandet "Fel 983": Unable to access availability database.... Det här felet registreras också i Felloggen för Microsoft SQL Server om SQL Server har konfigurerats för att registrera misslyckade inloggningsförsök:

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.

Den period under vilken tillgänglighetsgruppen är i rollen Matchning innan den är online igen i den primära rollen varar vanligtvis bara några sekunder eller till och med mindre än en sekund.

Identifiera och diagnostisera AlwaysOn-tillgänglighetsgruppens hälsohändelser eller redundans

1. Identifiera Always On-hälsotrender

Du kan undersöka en enskild AlwaysOn-hälsohändelse, eller så kan det finnas en aktuell eller pågående trend med hälsoproblem som tillfälligt avbryter produktionen. Följande frågor kan hjälpa dig att begränsa och korrelera de senaste ändringarna i produktionsmiljön som kan vara relaterade till dessa hälsoproblem:

• När började trenden för AlwaysOn- eller klusterhälsohändelser?
• Inträffar hälsohändelserna en viss dag?
• Inträffar hälsohändelserna vid en viss tidpunkt på dagen?
• Inträffar hälsohändelserna en viss dag eller vecka i månaden?

Om du upptäcker en trend kontrollerar du det schemalagda underhållet på systemet (värdsystemet i en virtuell miljö), ETL-batchar och andra jobb som kan korrelera med dessa hälsohändelser. Om systemet är en virtuell dator undersöker du värdsystemet för ändringar som eventuellt infördes vid tidpunkten för avbrotten.

Överväg upptagna ad hoc-produktionsarbetsbelastningar som kan korrelera med tidpunkten för hälsoproblemen (till exempel när användarna först loggar in på systemet eller efter att användarna har återvänt från lunch).

Obs!

Det här är ett bra tillfälle att överväga en plan för att samla in prestandadata under veckan och månaden. För att bättre förstå när systemet är som mest upptaget kan du mäta räknare för Windows-prestandaövervakare, till exempel Processor Information::% Processor Time, Memory::Available MBytesoch MSSQLServer:SQL Statistics::Batch Requests/sec.

2. Granska klusterloggen

Windows-klusterloggen är den mest omfattande logg som används för att identifiera typen av AlwaysOn- eller klusterhälsohändelse och även det identifierade hälsotillståndet som orsakade händelsen. Följ dessa steg för att generera och öppna klusterloggen:

Använd Windows PowerShell för att generera Windows-klusterloggen på klusternoden som är värd för den primära repliken vid tidpunkten för hälsohändelsen. Kör till exempel följande cmdlet i ett upphöjt PowerShell-fönster med hjälp av "sql19agn1" som SQL Server-baserat servernamn:

get-clusterlog -Node sql19agn1 -UseLocalTime     

Obs!

Som standard skapas loggfilen i %WINDIR%\cluster\reports.

3. Hitta hälsohändelsen i klusterloggen

AlwaysOn använder flera hälsoövervakningsmekanismer för att övervaka tillgänglighetsgruppens hälsa. Förutom en windowsklusterhälsohändelse (där Windows-klustret identifierar ett hälsoproblem bland klusternoderna) har AlwaysOn fyra olika typer av hälsokontroller:

• Tjänsten SQL Server körs inte
• Tidsgräns för SQL Server lån
• Tidsgräns för SQL Server hälsokontroll
• Ett SQL Server internt hälsoproblem

Du kan hitta någon av dessa AlwaysOn-specifika hälsohändelser genom att söka i klusterloggen efter strängen, [hadrag] Resource Alive result 0. Den här strängen sparas i klusterloggen när någon av dessa händelser identifieras. Till exempel:

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

Du kan använda ett verktyg för att hitta alla hälsohändelser i klusterloggen så att du kan generera en sammanfattningsrapport över AlwaysOn-hälsoproblem. Detta kan vara användbart för att identifiera kronologiska trender och avgöra om en viss typ av AlwaysOn-hälsotillstånd är återkommande. Följande skärmbild visar hur du använder en textredigerare (NotePad++, i det här fallet) för att hitta alla rader i klusterloggen som innehåller strängen [hadrag] Resource Alive result 0 :

Fastställa vilken typ av hälsoproblem som utlöste redundansväxlingen

Om du vill ta reda på vilken typ av hälsoproblem som du hittar i klusterloggen för den primära repliken jämför du dem med de problem som beskrivs i de kommande avsnitten.

Händelse för klusterhälsa

Microsoft Windows-kluster övervakar hälsotillståndet för medlemsservrarna i klustret. Om ett hälsoproblem identifieras kan en klustermedlemsserver tas bort från klustret. Dessutom flyttas klusterresurserna (inklusive tillgänglighetsgrupprollen som finns på den borttagna klustermedlemsservern) till repliken för redundansväxling av tillgänglighetsgruppspartner om den är konfigurerad för automatisk redundans.

Symptom på klusterhälsohändelser

Här är ett exempel på en klusterhälsohändelse i klusterloggen. Om du vill hitta den kan du söka Lost quorum efter eller Cluster service has terminated eftersom den kan finnas under rolländringen eller redundansväxlingen i tillgänglighetsgruppen.

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.

Ett annat sätt att identifiera den här händelsen är att söka i windows-systemhändelseloggen:

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.

Diagnostisera en klusterhälsohändelse

Felen i Windows-händelseloggen (händelser 1135 och 1177) tyder på att nätverksanslutningen är en orsak till händelsen. Det här är den vanligaste orsaken till att ett klusterhälsoproblem identifieras. I följande exempel visas att andra klustermedlemsservrar inte kunde kommunicera med den här servern som är värd för tillgänglighetsgruppens primära replik och att det här problemet utlöste borttagningen av klusternoden från klustret:

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'

Du kan söka i klusterloggen efter bevis på ett anslutningsfel till noden. Från platsen i klusterloggen där du hittade Lost quorumsöker du bakåt efter strängar som Failed to connect to remote endpoint, unreachableoch is broken.

Lösa en klusterhälsohändelse

Kontrollera att övervakning av klusterhälsa är lämplig för värdmiljön. Mer information om SQL Server AlwaysOn-tillgänglighetsgrupper som finns i Microsoft Azure finns i Översikt över Windows Server-redundanskluster – SQL Server på virtuella Azure-datorer.

Om det behövs kan du kontakta Support för hög tillgänglighet i Microsoft Windows för att öppna en supportincident.

SQL Server tjänsten är nere: En AlwaysOn-hälsohändelse

AlwaysOn-hälsoövervakning kan identifiera om den SQL Server tjänst som är värd för tillgänglighetsgruppens primära replik inte längre körs.

Symptom på SQL Server tjänstavstängning

Här är ett exempel på klusterloggrapporten för tillgänglighetsgruppsrollen ag som anger ett fel eftersom QueryServiceStatusEx ett process-ID 0returnerades:

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.

Diagnostisera och lösa avstängningshändelser för SQL-tjänsten

Kontrollera händelseloggen för Windows-systemet och SQL Server felloggen för en oväntad SQL Server avstängning.

Om SQL Server stängdes av av en systemavstängning eller en administrativ avstängning skulle följande post visas i felloggen för SQL Server:

2023-03-10 09:38:46.73 spid9s SQL Server avslutas som svar på en "stopp"-begäran från Service Control Manager. Det här är bara ett informationsmeddelande. Ingen användaråtgärd krävs.

Händelseloggen för Windows-systemet visar följande felpost:

Information 2023-03-10 09:41:06 Service Control Manager 7036 None Tjänsten SQL Server (MSSQLSERVER) övergick i stoppat tillstånd.

Händelseloggen för Windows-systemet visar följande felpost om SQL Server oväntat stängs av:

Fel 2023-03-10 08:37:46 Service Control Manager 7034 Ingen Tjänsten SQL Server (MSSQLSERVER) avslutades oväntat. Det har gjort detta 1 gång(ar).

Leta efter ledtrådar i slutet av SQL Server-felloggen. Om felloggen slutar plötsligt innebär det att den stängdes av med våld. Om SQL Server till exempel avslutades med hjälp av Aktivitetshanteraren skulle SQL Server felrapport inte avslöja någon information om interna problem som kan ha orsakat att processen stängdes av.

Om ett SQL Server internt hälsotillstånd orsakade SQL Server avslutas oväntat kan det finnas ledtrådar om ett eventuellt allvarligt undantag (inklusive en dumpfildiagnostik som genereras) i slutet av SQL-felloggen. Granska ledtrådarna och vidta nödvändiga åtgärder. Om du hittar en dumpfil kan du öppna kontakta Microsoft SQL Server support och ange SQL Server fellogg och dumpfilinnehåll för vidare undersökning.

Tidsgräns för lån: En AlwaysOn-hälsohändelse

AlwaysOn använder en "lease"-mekanism för att övervaka hälsotillståndet för den dator där SQL Server är installerad. Standardtidsgränsen för lån är 20 sekunder.

Symptom på timeout-händelser för AlwaysOn-lån

Här är ett exempel på utdata från tidsgränsen för AlwaysOn-lån från klusterloggen. Du kan söka i dessa strängar för att hitta en tidsgräns för lån i klusterloggen.

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

Mer information om tidsgränser för lån finns i avsnittet Lånemekanism i Mekanik och riktlinjer för tidsgränser för lån, kluster och hälsokontroll för AlwaysOn-tillgänglighetsgrupper.

Diagnostisera och lösa timeout-händelser för AlwaysOn-lån

Det finns två huvudsakliga problem som kan utlösa en tidsgräns för lån:

• SQL Server dumpfildiagnostik: När SQL Server identifierar vissa interna hälsohändelser, till exempel en åtkomstöverträdelse, en kontroll eller ett dödläge för schemaläggaren, genererar den en diagnostikdumpfil (.mdmp) i mappen SQL Server \LOG.

• Ett systemomfattande prestandaproblem: En tidsgräns för lån indikerar inte nödvändigtvis ett SQL Server hälsoproblem. I stället kan det tyda på ett systemomfattande hälsoproblem som också påverkar hälsotillståndet för den SQL Server-baserade servern. Mer detaljerade felsökningssteg finns i MSSQLSERVER_19407.

1. SQL Server dumpfildiagnostik

SQL Server kan identifiera ett internt hälsoproblem, till exempel en åtkomstöverträdelse, försäkran eller låsta schemaläggare. I det här fallet genererar programmet en minidumpfil (.mdmp) i mappen SQL Server \LOG i den SQL Server processen för diagnos. Den SQL Server processen är låst i flera sekunder medan minidumpfilen skrivs till disk. Under den här tiden är alla trådar i SQL Server processen i låst tillstånd. Detta inkluderar lånetråden som övervakas av AlwaysOn-hälsoövervakning. Därför kan AlwaysOn identifiera en tidsgräns för lån.

**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.

För att lösa det här problemet måste diagnostiken för dumpfilen undersökas för rotorsaken. Överväg att kontakta Microsoft SQL Server support för att tillhandahålla SQL Server fellogg och dumpa filinnehåll för ytterligare undersökning.

2. Problem med hög CPU-användning eller andra systemprestanda

En tidsgräns för lån anger ett prestandaproblem som påverkar hela systemet, inklusive SQL Server. För att diagnostisera systemproblemet rapporterar AlwaysOn-hälsodiagnostik prestandaövervakardata i klusterloggen och inkluderar timeout-händelsen för lån. Prestandadata sträcker sig över cirka 50 sekunder fram till timeout-händelsen för lån, rapportering om CPU-användning, ledigt minne och diskfördröjning.

Här är ett exempel på rapporterade prestandadata som visar en tidsgräns för lån i klusterloggen. I det här exemplet utdata, hög övergripande CPU-användning som kan vara relaterad till lånet timeout.

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

Om prestandadata visar hög CPU-användning, låg minnesanvändning eller hög diskfördröjning vid tidpunkten för en tidsgräns för lån börjar du samla in prestandaövervakardata för hela dagen på den primära repliken för att undersöka dessa symptom. Genom att samla in prestandaövervakningsdata under en längre period kan du bättre identifiera baslinje- och toppvärden för dessa resurser och övervaka ändringar i dessa resurser när ett lån överskrider tidsgränsen. När du samlar in dessa data bör du överväga om det finns vissa schemalagda eller ad hoc-arbetsbelastningar i SQL Server som korrelerar med tidpunkten för dessa resursproblem och hälsohändelser.

Du bör också samla in räknare som rapporterar samma systemresursanvändning, inklusive följande:

• 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

Tidsgräns för hälsokontroll: En AlwaysOn-hälsohändelse

När en tillgänglighetsgruppreplik övergår till den primära rollen upprättar AlwaysOn-hälsoövervakning en lokal ODBC-anslutning till den SQL Server instansen. Även om AlwaysOn är ansluten och övervakar, om SQL Server inte svarar över ODBC-anslutningen inom den period som har angetts för tillgänglighetsgruppens tidsgräns för hälsokontroll (standardvärdet är 30 sekunder), utlöses en timeout-händelse för hälsokontroll. I det här fallet övergår tillgänglighetsgruppen från den primära rollen till matchningsrollen och initierar redundans, om den är konfigurerad för att göra detta.

Mer information om tidsgränser för hälsokontroll finns i avsnittet "Timeout-åtgärd för hälsokontroll" i Mekanik och riktlinjer för tidsgränser för lån, kluster och hälsokontroll för AlwaysOn-tillgänglighetsgrupper.

Här är tidsgränsen för AlwaysOn-hälsokontroll enligt rapporten i klusterloggen:

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.

Diagnostisera och lösa timeout-händelsen för AlwaysOn-hälsokontroll

Följande avsnitt hjälper dig att granska SQL Server loggarna för "brödsmulor" händelser som du kan hitta och som korrelerar med AlwaysOn-hälsokontrolls timeouter som identifieras och rapporteras. Loggarna som granskas här inkluderar klusterloggen (där tidsgränsen för hälsokontrollen bekräftas), de system_health utökade händelseloggarna och SQL Server felloggarna (båda finns i mappen SQL Server \LOG) och händelseloggen för Windows-systemet. Använd dessa och andra loggar för att leta efter korrelerande händelser som kan hjälpa dig att begränsa orsaken till tidsgränsen för hälsokontrollen.

1. Sök efter icke-givande scheduler-händelser

Tidsgränsen för AlwaysOn-hälsokontrollen orsakas ofta av "icke-givande" händelser i SQL Server. När SQL Server upptäcker att en tråd inte har gett resultat för en schemaläggare, rapporterar den att en icke-givande scheduler-händelse har inträffat. Om du ser andra uppgifter i samma schemaläggare som inte får CPU-tid är detta det primära tecknet på en icke-givande schemaläggare. Det här beteendet kan orsaka en fördröjd körning av dessa uppgifter och "svälta" arbetsbelastningar som har tilldelats till en viss schemaläggare av CPU-tid.

Följ dessa steg om du vill söka efter icke-givande scheduler-händelser:

1. Kontrollera SQL Server system_health utökade händelseloggarna för att avgöra om en icke-givande scheduler-händelse av något slag rapporterades vid tidpunkten för alwayson-hälsokontrollens timeout-händelse. Icke-givande händelser som du kan hitta inkluderar följande:

   • 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. Öppna SQL Server utökade händelseloggar för systemhälsa på den primära repliken till tidpunkten för tidsgränsen för misstänkt hälsokontroll.

3. I SQL Server Management Studio (SSMS) går du till Öppna fil >och väljer Sammanfoga utökade händelsefiler.

4. Välj knappen Lägg till .

5. I dialogrutan Öppna fil navigerar du till filerna i katalogen SQL Server \LOG.

6. Tryck på och håll kontroll och välj sedan de filer vars namn börjar med system_health_xxx.xel.

7. Välj Öppna>OK.

8. Filtrera resultatet. Högerklicka på en händelse under namnkolumnen och välj Filtrera efter det här värdet.

   

9. Definiera ett filter för att sortera rader där värdena i namnkolumnen innehåller yield, enligt följande skärmbild. Detta returnerar alla typer av icke-givande händelser som kan ha registrerats i loggarna system_health .

   

10. Jämför tidsstämplarna för att se om det fanns icke-givande händelser vid tidpunkten för tidsgränsen för hälsokontrollen. Här är tidsgränsen för hälsokontrollen enligt rapporten i klusterloggen:

    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.
    

    Du kan se att det fanns icke-givande händelser som inträffade vid tidpunkten för tidsgränsen för hälsokontrollen.

    

Om icke-givande händelser identifieras kontrollerar du orsaken till den icke-givande händelsen. Överväg att kontakta SQL Server supportteamet för att undersöka de icke-givande händelserna.

2. Kontrollera SQL Server felloggen

Kontrollera SQL Server felloggen för korrelering av händelser vid tidpunkten för hälsokontrollens timeout. Dessa händelser kan ge "brödsmulor" som föreslår ytterligare steg för att begränsa rotorsaken till tidsgränserna för hälsokontroll.

Följande loggpost visar till exempel att tidsgränsen för en hälsokontroll inträffade i klusterloggen:

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.

I SQL Server felloggen, inom några sekunder efter tidsgränsen för hälsokontrollen, rapporterar SQL Server att den har identifierat allvarlig I/O-svarstid:

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.

Granska systemhändelseloggen för att hitta möjliga systeminsikter som kan vara relaterade till timeout-händelsen för hälsokontrollen. När du granskar händelseloggen för Windows-systemet kan du hitta ett I/O-problem som rapporteras samtidigt för samma timeout för hälsokontroll:

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."

SQL Server hälsa: En AlwaysOn-hälsohändelse

AlwaysOn övervakar olika typer av SQL Server hälsohändelser. Även om den är värd för en primär replik för tillgänglighetsgruppen körs sp_server_diagnostics SQL Server kontinuerligt som rapporterar om SQL Server hälsa med hjälp av olika komponenter. När eventuella hälsoproblem identifieras sp_server_diagnostics rapporterar ett fel för den specifika komponenten och skickar sedan resultaten tillbaka till alwayson-hälsoidentifieringsprocessen. När ett fel rapporteras visar tillgänglighetsgruppsrollen feltillstånd och eventuell redundans om tillgänglighetsgruppen har konfigurerats för att göra detta.

Symtom på AlwaysOn-SQL Server hälsohändelser

Här är ett exempel på ett SQL Server hälsoproblem som rapporteras av sp_server_diagnostics i klusterloggen. SQL Server rapporterar ett feltillstånd i systemkomponenten till AlwaysOn-hälsoövervakning, och tillgänglighetsgruppen "contoso-ag" övergår till ett feltillstånd.

Obs!

Ett SQL Server hälsoproblem genererar en liknande rapport som för tidsgränsen för hälsokontroll. Båda hälsohändelserna rapporterar Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel. Skillnaden för en SQL Server hälsohändelse är att den rapporterar att SQL Server komponenten har ändrats från "varning" till "fel".

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.

Diagnostisera och lösa SQL Server hälsohändelser

Den typ av hälsoproblem som rapporteras av SQL Server hälsa bör diktera riktningen för rotorsaksanalysen.

När du distribuerar en tillgänglighetsgrupp FAILURE_CONDITION_LEVEL anges som standard som tre. Detta aktiverar övervakning av vissa, men inte alla SQL Server hälsoprofiler. På standardnivå utlöser AlwaysOn en hälsohändelse när SQL Server skapar för många dumpfiler, en överträdelse av skrivåtkomst eller en överbliven spinlock. Om du ställer in tillgänglighetsgruppen på nivå fyra eller fem utökas de typer av SQL Server hälsoproblem som övervakas. Mer information om SQL Server alwayson-övervakare för hälsotillstånd finns i Konfigurera en flexibel automatisk redundansprincip för en tillgänglighetsgrupp – SQL Server Alltid på.

Följ dessa steg för att identifiera problemet med AlwaysOn-specifika hälsotillstånd:

1. Öppna SQL Server utökade händelseloggar för klusterdiagnostik på den primära repliken till tidpunkten för den misstänkta SQL Server hälsohändelsen inträffade.

2. I SSMS går du till Öppna fil> och väljer sedan Sammanfoga utökade händelsefiler.

3. Välj Lägg till.

4. I dialogrutan Öppna fil navigerar du till filerna i katalogen SQL Server \LOG.

5. Tryck på Kontroll, välj de filer vars namn matchar <servername>_<instance>_SQLDIAG_xxx.xeloch välj sedan Öppna>OK.

   

   Du ser ett nytt fönster med flikar i SSMS som innehåller de utökade händelserna, enligt följande skärmbild.

6. Om du vill undersöka ett SQL Server hälsoproblem letar du reda på component_health_result vars state_desc värde är error. Här är ett exempel på en systemkomponenthändelse som rapporterade ett fel tillbaka till AlwaysOn-hälsoövervakning:

   

7. Dubbelklicka på datakolumnen i det nedre fönstret. Då öppnas detaljerade komponentdata i ett nytt fönsterfönster för SSMS för granskning. Så här ser systemkomponentdata ut:

   

   Observera att "totalDumprequests=186"-data indikerar att det har genererats för många diagnostikhändelser för dumpfiler på den här SQL Server. Det här är orsaken till att systemkomponenten rapporterade ett feltillstånd. När AlwaysOn-hälsoövervakning tar emot det här feltillståndet utlöser den en hälsohändelse för tillgänglighetsgruppen. Du kan också kontrollera att inga överträdelser av skrivåtkomst eller överblivna spinlocks har identifierats från de data som anges i systemkomponentdata.

   Om det behövs kontaktar du SQL Server support för att öppna en supportincident för ytterligare hjälp med att hitta rotorsaken till dessa interna SQL Server hälsoproblem.