Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Sammanfattning
Den här artikeln hjälper dig att felsöka återställningsköer (kallas även redo queuing) på en sekundär replik i en SQL Server AlwaysOn-tillgänglighetsgrupp. Den förklarar vad återställningskön är, hur du kontrollerar storleken på redokön och redohastigheten, hur du tolkar värdena och hur du diagnostiserar och åtgärdar vanliga orsaker till redofördröjning, inklusive blockerade redo-trådar och enkeltrådad redo.
Vad återställningsköer är
Ändringar som görs i den primära repliken i en tillgänglighetsgruppdatabas skickas till varje sekundär replik i samma tillgänglighetsgrupp. När ändringarna har hämtats till en sekundär replik skrivs de först (härdade) till transaktionsloggfilen för tillgänglighetsgruppdatabasen. Microsoft SQL Server använder sedan åtgärden recovery eller redo för att tillämpa loggposterna på databasfilerna.
Om ändringarna anländer och permanentas i transaktionsloggen snabbare än de kan återskapas, bildas en återställningskö. Denna kö består av de loggposter som har skrivits till stabil lagring men ännu inte har tillämpats på databasen.
Symtom och effekter av återställningsköer
Inaktuella data på sekundära repliker
Skrivskyddade arbetslaster som kör frågor mot sekundära repliker kan returnera inaktuella data. Om återställningsköer inträffar visas inte de senaste ändringarna i den primära replikdatabasen ännu på den sekundära när du kör frågor mot samma data.
Ändringarna kommer till den sekundära databasen och skrivs till databasens loggfil, men de kan inte läsas förrän redo tillämpar dem på datafilerna.
Mer information finns i avsnittet Datasvarstid på sekundär replik i "Skillnader mellan tillgänglighetslägen för en AlwaysOn-tillgänglighetsgrupp".
Längre tid för växling vid fel eller överskriden RTO
Mål för återställningstid (RTO) är den maximala databasavbrott som en organisation kan tolerera och hur snabbt organisationen kan återfå användningen av databasen efter ett avbrott. Om det finns en stor återställningskö på en sekundär replika när en redundansväxling inträffar, kan redo på den nya primära replikan ta längre tid än RTO. När återställningen har slutförts går databasen över till den primära rollen och återspeglar det tillstånd som fanns före redundansväxlingen. En längre omgörningstid fördröjer hur snabbt produktionen återupptas.
Diagnostikverktyg rapporterar en tillgänglighetsgrupp med feltillstånd
När kön för att göra om är stor kan Always On-dashboarden i SQL Server Management Studio (SSMS) visa att tillgänglighetsgruppen inte är felfri.
Sök efter återställningsköer
Återställningskön är ett mått per databas. Du kan kontrollera detta i Always On-instrumentpanelen på den primära repliken eller genom att köra en fråga mot den dynamiska hanteringsvyn (DMV) sys.dm_hadr_database_replica_states på den primära eller sekundära repliken. Räknarna i Performance Monitor rapporterar även storleken på återställningskön och redohastigheten. Kontrollera dessa räknare på den sekundära repliken.
I de följande avsnitten beskrivs metoder för att aktivt övervaka återställningskön för databasen i tillgänglighetsgruppen.
Fråga sys.dm_hadr_database_replica_states
sys.dm_hadr_database_replica_states DMV rapporterar en rad för varje tillgänglighetsgruppdatabas. Kolumnen redo_queue_size visar återställningsköstorleken i kilobyte. Om du vill övervaka trenden i återställningsköstorlek var 30:e sekund ställer du in en fråga som liknar följande. Kör den 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 redo_queue_size och redo_rate är relevanta.
WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_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 återställningskön i instrumentpanelen Always On
Följ dessa steg för att granska återställningskön:
I SSMS Object Explorer väljer du och håller (eller högerklickar) en tillgänglighetsgrupp för att öppna snabbmenyn.
Välj Visa instrumentpanel.
Tillgänglighetsgruppens databaser visas sist, med vissa data rapporterade för varje databas. Redo Queue Size (KB) och Redo Rate (KB/sek) visas inte som standard, men du kan lägga till dem i vyn, som du ser i nästa steg.
Om du vill lägga till dessa räknare trycker du och håller ned (eller högerklickar på) rubriken ovanför databasrapporterna och väljer sedan vilka kolumner som ska visas.
Om du vill lägga till Redo Queue Size (KB) och Redo Rate (KB/sek) trycker du och håller ned (eller högerklickar på) rubriken som är markerad i rött i följande skärmbild.
Som standard uppdaterar AlwaysOn-instrumentpanelen automatiskt Redo Queue Size (KB) och Redo Rate (KB/sek) var 60:e sekund.
Granska återställningskön i Prestandaövervakaren
Varje sekundär replik och databas har en egen återställningsköstorlek. Följ dessa steg för att granska återställningskön 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 SQLServer:Database Replica och väljer sedan räknarna Återställningskö och Omgjorda byte/s.
I listrutan Instans väljer du den tillgänglighetsgruppdatabas som du vill övervaka för återställningsköer.
Välj Lägg till>OK.
Så här kan ökad återställningskö se ut.
Tolka värden för återställningsköer
I det här avsnittet beskrivs hur du tolkar de återställningskövärden som du samlade in i föregående avsnitt.
När återställningsköer är ett problem
Ett återställningskövärde på 0 innebär att inga kvarvarande uppgifter görs om vid tidpunkten för rapporten. I en hårt belastad produktionsmiljö visar återställningskön ofta ett värde som inte är noll även när tillgänglighetsgruppen är felfri. Under typisk produktion förväntar du dig att värdet varierar mellan 0 och ett icke-nollvärde.
Om återställningskön växer över tid, undersök saken närmare. Tillväxt indikerar att något har ändrats. När du ser plötslig tillväxt är följande mått användbara för felsökning:
- Loggomföringshastighet (KB/sec) (Always On-instrumentpanel)
-
redo_rateisys.dm_hadr_database_replica_states
Upprätta baslinjeåterställningshastigheter
Vid normal Always On-prestanda bör du övervaka omgörningshastigheten för de hårt belastade databaserna i tillgänglighetsgruppen. Avbildningshastigheter under typiska kontorstider och under underhållsperioder när stora transaktioner (till exempel ombyggnad av index eller ETL-processer) ger högre dataflöde. Jämför dessa baslinjer när du ser tillväxt i återställningsköer för att identifiera vad som har ändrats. Arbetsbelastningen kan vara större än vanligt, eller så kan omgörningsfrekvensen vara lägre än förväntat, vilket kräver ytterligare undersökning.
Ta hänsyn till arbetsbelastningens omfattning
Stora arbetsbelastningar (till exempel en UPDATE-sats mot en miljon rader, en omindexering av en tabell på 1 TB eller en ETL-batch som infogar miljontals rader) orsakar vanligtvis viss ökning av återställningskön, antingen omedelbart eller över tid. Den här tillväxten förväntas när många ändringar plötsligt görs i tillgänglighetsgruppdatabasen.
Diagnostisera återställningsköer
När du har identifierat återställningsköer för en specifik sekundär repliktillgänglighetsgruppdatabas ansluter du till den sekundära repliken och frågar sys.dm_exec_requests sedan för att kontrollera wait_type och wait_time för återställningstrådar. Du letar efter en hög frekvens av en eller flera väntetyper och stora väntetider för dessa väntetyper. Följande exempelfråga körs var femte sekund och rapporterar väntetyper och väntetider för tillgänglighetsgruppens databas agdb:
WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END
Viktigt!
För meningsfulla utdata av väntetyp bör återställningskön växa när du samlar in dessa data med någon av de metoder som beskrevs tidigare.
I följande exempel rapporteras vissa I/O-relaterade väntetyper (PAGEIOLATCH_UP, PAGEIOLATCH_EX). Övervaka om dessa väntetyper fortsätter att visa de största wait_time värdena, enligt rapporten i nästa kolumn.
Identifiera väntetyper för återställning
När du har identifierat en väntetyp använder du Availability group secondary replica redo model and performance som referens för vanliga väntetyper som orsakar köbildning vid återställning och för vägledning om hur problemet kan åtgärdas.
Blockerade återställningstrådar på skrivskyddade sekundära repliker
Om din lösning dirigerar rapportering (fråga) mot tillgänglighetsgruppdatabaser på en sekundär replik, låser sig dessa skrivskyddade frågor schemastabilitet (Sch-S). Sch-S-lås kan blockera redo-trådar från att erhålla schemaändringslås (Sch-M) (även kallade schema modify-lås, eller LCK_M_SCH_M) som krävs för att tillämpa DDL-ändringar som ALTER TABLE eller ALTER INDEX. En blockerad omdaningstråd kan inte tillämpa loggposter förrän den har avblockerats, vilket orsakar återställningsköer.
Om du vill kontrollera om det finns historik över blockerad redo öppnar du spårningsfilerna för Extended Events för AlwaysOn_health på den sekundära repliken med hjälp av SSMS. Leta efter lock_redo_blocked händelser.
Använd Performance Monitor för att aktivt övervaka effekten av blockerad redo på återställningskön. Lägg till SQL Server:Database Replica\Redo blocked/sec och SQL Server:Database Replica\Recovery Queue räknarna. Följande skärmbild visar hur ett ALTER TABLE ALTER COLUMN-kommando körs på den primära repliken samtidigt som en långvarig fråga körs mot samma tabell på den sekundära repliken.
Räknaren Gör om blockerad/sek toppar när ALTER TABLE ALTER COLUMN kommandot körs. Medan den långvariga frågan är aktiv i samma tabell på den sekundära repliken ökar eventuella efterföljande ändringar i den primära återställningskön.
Övervaka väntetypen för schemaändringslås som återställningstråden försöker erhålla. Använd den tidigare frågan för att kontrollera de väntetyper som rapporteras för redo-åtgärder i sys.dm_exec_requests. Du kan se väntetiden för LCK_M_SCH_M öka medan gör om blockeras.
Återställning med en tråd
SQL Server 2016 infördes parallell återställning för sekundära replikdatabaser. Om du kör en tidigare version, till exempel SQL Server 2014 eller SQL Server 2012, uppgradera till en version som stöds för att få parallell redo och förbättrad redoprestanda.
Entrådad omdaning kan fortfarande ske i SQL Server 2016 till och med SQL Server 2019, som använder den parallella återställningsarkitekturen. I de versionerna kan en SQL Server-instans använda upp till 100 trådar för parallell redo. Systemet allokerar parallella ombearbetningstrådar mellan tillgänglighetsgruppdatabaser baserat på antalet processorer och databaser, upp till den summan på 100 trådar. När gränsen på 100 trådar har nåtts tilldelar systemet vissa databaser i tillgänglighetsgruppen en enda omtrådningstråd.
Om du vill kontrollera om tillgänglighetsgruppdatabasen använder parallell återställning ansluter du till den sekundära repliken och kör följande fråga för att räkna de rader (trådar) som tillämpar återställning för databasen. I följande exempel kan återställningsarbetsbelastningen agdb dra nytta av parallell återställning om databasen har en enda rad och dess kommando är DB STARTUP.
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
Om databasen använder enkeltrådad återställning ska du granska den tidigare algoritmen för att kontrollera om SQL Server överskrider de 100 arbetstrådar som är avsedda för parallell återställning. Att nå den gränsen kan vara anledningen till att agdb bara använder en enda redo-tråd.
SQL Server 2022 och senare använder en parallell återställningsalgoritm som tilldelar arbetstrådar baserat på arbetsbelastningen, vilket eliminerar risken för att en hårt belastad databas fortsätter att använda enkeltrådad redo. Mer information finns i avsnittet Trådanvändning efter tillgänglighetsgrupper i avsnittet "Krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper".