Felsöka loggen skicka köer i en AlwaysOn-tillgänglighetsgrupp

Artikel
2024-12-14

Den här artikeln innehåller lösningar på problem som rör loggöverföringsköer.

Vad är log send-köning?

Ändringar som görs i en tillgänglighetsgruppdatabas på den primära repliken (till exempel INSERT, UPDATEoch DELETE) skrivs till transaktionsloggen och skickas till tillgänglighetsgruppens sekundära repliker. Log Send Queue definierar antalet loggposter i loggfilerna för den primära databasen som inte har skickats till de sekundära replikerna.

Symptom och effekt av loggöverföringsköer

Log send-kön lagrar alla sårbara data

Om den primära repliken går förlorad i ett plötsligt haveri och du redundansväxlar till den sekundära repliken där dessa ändringar ännu inte har kommit, visas inte dessa ändringar i den nya primära replikkopian av databasen. Detta utesluter alla ändringar som lagras när fullständiga databas- och loggsäkerhetskopior körs.

Växande loggöverföringskö gör att transaktionsloggfilen växer

För en databas som har definierats i en tillgänglighetsgrupp måste Microsoft SQL Server vid den primära repliken behålla alla transaktioner i transaktionsloggen som ännu inte har levererats till de sekundära replikerna. Loggens sändningskö representerar antalet loggade ändringar på den primära repliken som inte kan trunkeras under normala loggtrunkeringshändelser (till exempel under en säkerhetskopia av databasloggen). En stor och växande loggöverföringskö kan uttömma ledigt utrymme på den enhet som är värd för databasloggfilen eller överskrida den konfigurerade maximala transaktionsloggfilens storlek. Mer information finns i Fel 9002 när transaktionsloggen är stor.

Olika diagnostikfunktioner rapport tillgänglighet grupplogg skicka köer

Instrumentpanelen AlwaysOn i SQL Server Management Studio rapporterar i loggen skicka köer. Det kan rapportera att tillgänglighetsgruppen inte är felfri.

Så här söker du efter loggöverföringsköer

Loggöverföringskö är ett mått per databas. Du kan kontrollera det här värdet med instrumentpanelen AlwaysOn på den primära repliken eller med hjälp av sys.dm_hadr_database_replica_states Dynamic Management Views (DMV) på den primära eller sekundära repliken. Prestandaövervakarens räknare används för att söka efter loggöverföringsköer mot den sekundära repliken.

Nästa flera avsnitt innehåller metoder för att aktivt övervaka din tillgänglighetsgrupp databaslogg skicka kö.

Fråga sys.dm_hadr_database_replica_state

sys.dm_hadr_database_replica_states DMV rapporterar en rad för varje tillgänglighetsgruppdatabas. En kolumn i rapporten är log_send_queue_size. Det här värdet är loggens storlek för att skicka kö i kilobyte (KB). Du kan konfigurera en fråga, till exempel följande fråga, för att övervaka eventuella trender i loggens storlek för att skicka kö. Frågan körs på den primära repliken. Den använder predikatet is_local=0 för att rapportera data för den sekundära repliken, där log_send_queue_size och log_send_rate är relevanta.

SQL

WHILE 1=1
BEGIN
  SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
  FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
  JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
  WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
  waitfor delay '00:00:30'
END

Så här ser utdata ut.

Granska loggens skicka-kö på instrumentpanelen för AlwaysOn

Följ dessa steg för att granska loggens sändningskö:

Öppna instrumentpanelen AlwaysOn i SQL Server Management Studio (SSMS) genom att högerklicka på en tillgänglighetsgrupp i SSMS Object Explorer.
Välj Visa instrumentpanel.

Tillgänglighetsgruppens databaser visas sist och vissa data rapporteras om databaserna. Även om log Send Queue Size (KB) och Log Send Rate (KB/s) inte visas som standard, kan du lägga till dem i den här vyn, som du ser i skärmbilden i nästa steg.
Om du vill lägga till dessa kolumner högerklickar du på kolumnrubriken för tillgänglighetsgruppens databas och väljer i listan över tillgängliga kolumner.
Om du vill lägga till loggens storlek på skicka kö högerklickar du på rubriken som visas som markerad i rött på följande skärmbild.

Som standard uppdaterar AlwaysOn-instrumentpanelen automatiskt dessa data var 60:e sekund.

Granska loggen Skicka kö i Prestandaövervakaren

Loggens sändningskö är specifik för varje sekundär replikdatabas. Följ därför dessa steg för att granska loggens skicka-kö för en tillgänglighetsgruppdatabas:

Öppna Prestandaövervakaren på den sekundära repliken.
Välj knappen Lägg till (räknare).
Under Tillgängliga räknare väljer du räknarna SQLServer:Database Replica och Log Send Queue .
I listrutan Instans väljer du den tillgänglighetsgruppdatabas som du vill söka efter i kö för loggöverföring.
Välj Lägg till och OK.

Så här kan det se ut att öka loggens sändningskö.

Tolka loggen skicka kövärden

I det här avsnittet beskrivs hur du tolkar värdena för loggens storlek för att skicka kö.

När är loggen skicka köer dåligt? Hur mycket loggöverföringsköer bör tolereras?

Du kan anta att om loggen skicka kön rapporterar ett värde på 0, innebär det att ingen logg skicka köer inträffar vid tidpunkten för rapporten. Men när produktionsmiljön är upptagen bör du förvänta dig att observera att loggens sändningskö ofta rapporterar ett annat värde än noll även i en felfri AlwaysOn-miljö. Under typisk produktion bör du förvänta dig att observera att det här värdet varierar mellan 0 och ett värde som inte är noll.

Om du ser ökad loggöverföringskö över tid är ytterligare undersökning berättigad. Den här extra aktiviteten anger att något har ändrats. Om du ser en plötslig ökning i loggens sändningskö är följande mått användbara för felsökning:

Loggöverföringshastighet (KB/s) (AlwaysOn-instrumentpanel)
sys.dm_hadr_database_replica_states (DMV)
Databasreplik::Speglade transaktioner per sekund (prestandaövervakare)

Hämta baslinjepriser för loggöverföringshastighet och speglade transaktioner per sekund

Under felfria AlwaysOn-prestanda övervakar du loggens sändningshastighet och speglade transaktioner/sek-värden för dina upptagna tillgänglighetsgruppdatabaser. Hur ser de ut under vanligtvis upptagna kontorstider? Hur ser de ut under underhållsperioder när stora transaktioner ger högre transaktionsdataflöde i systemet? Du kan jämföra dessa värden när du ser loggen skicka kötillväxt för att avgöra vad som har ändrats. Arbetsbelastningen kan vara större än vanligt. Om loggöverföringsfrekvensen är lägre än vanligt kan ytterligare undersökning krävas för att avgöra varför.

Arbetsbelastningsvolymer spelar roll

När du har stora arbetsbelastningar (till exempel en UPDATE instruktion mot 1 miljon rader, ett index som återskapas i en tabell på 1 terabyte eller till och med en ETL-batch som infogar miljontals rader), bör du förvänta dig att vissa loggar skickar kötillväxt, antingen omedelbart eller över tid. Detta förväntas när ett stort antal ändringar plötsligt görs i tillgänglighetsgruppdatabasen.

Så här diagnostiserar du loggöverföringsköer

När du har identifierat loggöverföringsköer för en specifik tillgänglighetsgruppdatabas bör du söka efter flera olika möjliga rotorsaker till problemet, enligt beskrivningen i följande avsnitt.

Viktigt

För meningsfulla utdata av väntetyp kontrollerar du om loggens sändningskö ökar med någon av de metoder som beskrivs i föregående avsnitt när du övervakar för följande villkor.

Systemet är för upptaget

Kontrollera om arbetsbelastningen på den primära repliken överbelastar systemets processorer. Om du ser en ökning i loggens sändningskö frågar du DMV:en sys.dm_os_schedulers och övervakaren efter high runnable_tasks_count. Det här antalet anger utestående aktiviteter som kördes vid den tidpunkten.

SQL

SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers

Följande tabell är ett exempel på resultat. En ökning av värdet runnable_tasks_count anger att ett stort antal uppgifter väntar på CPU-tid.

scheduler_address	scheduler_id	cpu_id	status	current_tasks_count	runnable_tasks_count	current_workers_count	active_workers_count
0x000002778D 200040	0	0	SYNLIG OFFLINE	1	0	2	1
0x000002778D 220040	1	1	SYNLIG ONLINE	108	12	115	107
0x000002778D 240040	2	2	SYNLIG ONLINE	113	2	123	113
0x000002778D 260040	3	3	SYNLIG ONLINE	105	11	116	105
0x000002778D 480040	4	4	SYNLIG ONLINE	108	15	117	108
0x000002778D 4A0040	5	5	SYNLIG ONLINE	100	25	110	99
0x000002778D 4C0040	6	6	SYNLIG ONLINE	105	23	113	105
0x000002778D 4E0040	7	7	SYNLIG	109	25	116	109
0x000002778D 700040	8	8	SYNLIG ONLINE	98	10	112	98
0x000002778D 720040	9	9	SYNLIG ONLINE	114	1	130	114
0x000002778D 740040	10	10	SYNLIG ONLINE	110	25	120	110
0x000002778D 760040	11	11	SYNLIG ONLINE	83	8	93	83
0x000002778D A00040	12	12	SYNLIG ONLINE	104	4	117	104
0x000002778D A20040	13	13	SYNLIG ONLINE	108	32	118	108
0x000002778D A40040	14	14	SYNLIG ONLINE	102	12	113	102
0x000002778D A60040	15	15	SYNLIG ONLINE	104	16	116	103

Lösning: Om du upptäcker hög runnable_task_countminskar du arbetsbelastningen i systemet eller ökar antalet processorer som är tillgängliga för systemet.

Svarstid för nätverk

Det här villkoret är särskilt vanligt om den sekundära repliken är fysiskt fjärransluten från den primära repliken. Med tillgänglighetsgrupper för flera platser kan kunder distribuera kopior av affärsdata på flera platser för haveriberedskap och rapportering. Detta gör nästan realtidsändringar tillgängliga för kopior av produktionsdata på fjärranslutna platser.

Om en sekundär replik finns långt från den primära repliken kan loggöverföringsköer orsakas av nätverksfördröjning och en oförmåga att skicka ändringar till den sekundära fjärrservern så snabbt som de skapas i den primära replikdatabasen.

Viktigt

SQL Server använder en enda anslutning för att synkronisera ändringar från den primära till de sekundära replikerna. Om en sekundär replik är fjärransluten påverkar därför inte rörbredden hur mycket data SQL Server kan skicka. I stället är den här mängden mer beroende av nätverksfördröjningen i röret (anslutningshastighet).

Testa för nätverksfördröjning

Kontrollera om inställningarna för flödeskontroll bidrar till nätverksfördröjning

Microsoft SQL Server-tillgänglighetsgrupper använder flödeskontrollgrindar för att undvika överdriven förbrukning av nätverksresurser, minne och andra resurser på alla tillgänglighetsrepliker. Dessa flödeskontrollgrindar påverkar inte hälsotillståndet för synkronisering av tillgänglighetsreplikerna. De kan dock påverka den övergripande prestandan för dina tillgänglighetsdatabaser, inklusive RPO.

Senare versioner av SQL Server ändrar tröskelvärdena vid vilka flödeskontroll anges. Detta kan hjälpa dig att lindra den effekt som flödeskontroll har på symtom som loggöverföringsköer. Mer information om flödeskontroll och historiken för ändringar av tröskelvärden för flödeskontroll finns i Flödeskontrollgrindar.

Du kan övervaka flödeskontroll med hjälp av Prestandaövervakaren för att samla in data på den primära repliken. Om du vill övervaka databasflödeskontrollen lägger du till SQLServer:Database Replica-räknare och väljer räknarna Fördröjning av databasflödeskontroll och databasflödeskontroller per sekund . I dialogrutan Instans väljer du den tillgänglighetsgruppdatabas som du vill söka efter databasflödeskontroll. Om du vill identifiera och övervaka flödeskontrollen för tillgänglighetsreplik lägger du till räknare för SQLServer:Tillgänglighetsreplik och väljer räknare för flödeskontroll (ms/sek) och flödeskontroll/sek .
Kontrollera om windows-omstart av överbelastning bidrar till nätverksfördröjning

Problem med nätverksprestanda som orsakar loggöverföringsköer kan utlösas genom att inställningen För överbelastning för Windows Starta om TCP är inställd på Sant. Det här var standardinställningen i Windows Server 2016. Kontrollera att Omstart av överbelastningsfönster är inställt på Falskt på Windows-servrar som är värdar för tillgänglighetsgrupprepliker där loggöverföringsköer observeras.

PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart

Mer information om hur du ställer in egenskapen TCP Congestion Windows Restart till False finns i Set-NetTCPSetting (NetTCPIP).

Mer information om synkroniseringsprocessen finns i Övervaka prestanda för AlwaysOn-tillgänglighetsgrupper. Den här artikeln visar också hur du beräknar några av de viktigaste måtten och innehåller länkar till några av de vanliga scenarierna för prestandafelsökning.

Använd ping för att hämta ett svarstidsexempel

På en kommandorad på node1 (primär replik), ping node2 (sekundär replik):

Output

C:\Users\customer>ping node2
Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data:
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms
Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms

Ping statistics for 2<ip address>:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 94ms, Maximum = 119ms, Average = 101ms

Testa nätverkets dataflöde från primärt till sekundärt med oberoende verktyg

Använd ett verktyg som NTttcp för att oberoende identifiera nätverkets dataflöde mellan de primära och sekundära replikerna med hjälp av en enda anslutning. Nätverksfördröjning är en vanlig orsak till loggöverföringsköer. Följande steg visar hur du använder ett oberoende verktyg, till exempel NTttcp, för att mäta nätverkets dataflöde.

Viktigt

SQL Server skickar ändringar från den primära repliken till den sekundära repliken med hjälp av en enda anslutning. I följande avsnitt konfigurerar och kör vi NTttcp för att använda en enda anslutning (på samma sätt som SQL Server) för att jämföra dataflödet korrekt.

Du kan ladda ned NTttcp från Github – microsoft/ntttcp.

Följ dessa steg för att köra NTttcp:
1. Ladda ned och kopiera verktyget till de primära och sekundära SQL Server-baserade servrarna.
2. Öppna en upphöjd kommandotolk på den sekundära replikservern, ändra katalogen till mappen NTttcp-verktyg och kör sedan följande kommando:
  
  ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  Anteckning
  
  I det här kommandot <secondaryipaddress> är en platshållare för den faktiska IP-adressen för den sekundära replikservern.
3. Öppna en upphöjd kommandotolk på den primära replikservern, ändra katalogen till mappen NTttcp-verktyg och kör sedan följande kommando genom att ange den faktiska IP-adressen för den sekundära replikservern igen:
  
  ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60
  
  Följande skärmbilder visar NTttcp som körs på de sekundära och primära replikerna. På grund av nätverksfördröjning kan verktyget bara skicka 739 KB/s data. Det är vad du kan förvänta dig att SQL Server ska kunna skicka.
  
  NTttcp på sekundär replik
  
  NTttcp på primär replik

Granska prestandaövervakarräknare

Kontrollera vilka NTttcp-rapporter. En stor transaktion körs i SQL Server på den primära repliken. När du har startat Prestandaövervakaren på den primära repliken lägger du till räknaren Network Interface::Bytes Sent/sec . Den här räknaren bekräftar att den primära repliken kan skicka cirka 777 kB/s data. Detta liknar värdet på 739 KB/s som rapporteras av NTttcp-testet.

Det är också användbart att jämföra värdet SQL Server::D atabases::Log Bytes Flushed/sec på den primära repliken med SQL Server::D atabase Replica::Log Bytes Received/sec för samma databas på den sekundära repliken. I genomsnitt observerar vi ~20 MB/s ändringar som skapas i agdb-databasen. Den sekundära repliken får dock i genomsnitt endast 5,4 MB ändringar. Detta gör att loggen skickar köer på den primära repliken av utestående ändringar i databastransaktionsloggen som ännu inte har skickats till den sekundära repliken.

Primära replikloggbyte tömda per sekund för agdb-databasen

Mottagna byte för sekundär repliklogg/s för databasen agdb

Dela via