Problemen met de wachtrij voor herstel (redo) in een Always On-beschikbaarheidsgroep oplossen

Overzicht

Dit artikel helpt u bij het oplossen van problemen met het in de wachtrij plaatsen van herstel (ook wel redo queuing genoemd) op een secundaire replica in een SQL Server AlwaysOn-beschikbaarheidsgroep. Hierin wordt uitgelegd wat de herstelwachtrij is, hoe u de grootte van de redo queue en de redo rate controleert, hoe u de waarden interpreteert en hoe u veelvoorkomende oorzaken van redovertraging kunt diagnosticeren en verhelpen, waaronder geblokkeerde redo-threads en single-threaded redo.

Wat wachtrijen voor herstel zijn

Wijzigingen in de primaire replica in een beschikbaarheidsgroepdatabase worden verzonden naar elke secundaire replica in dezelfde beschikbaarheidsgroep. Nadat de wijzigingen op een secundaire replica zijn aangekomen, worden ze eerst geschreven (beperkt) naar het transactielogboekbestand van de database van de beschikbaarheidsgroep. Microsoft SQL Server gebruikt vervolgens de herstel- of herbewerking om deze logboekrecords toe te passen op de databasebestanden.

Als wijzigingen sneller binnenkomen en in het transactielogboek worden vastgelegd dan ze opnieuw kunnen worden toegepast, ontstaat er een herstelwachtrij. Deze wachtrij is de verzameling beveiligde logrecords die nog niet op de database zijn toegepast.

Symptomen en effecten van het in wachtrij plaatsen van herstel

Verouderde gegevens op secundaire replica's

Leesbewerkingen die secundaire replica's bevragen, kunnen verouderde gegevens retourneren. Als er een herstelwachtlijn optreedt, zijn recente wijzigingen in de primaire replicadatabase nog niet zichtbaar op de secundaire database wanneer u dezelfde gegevens opvraagt.

De wijzigingen komen op de secundaire replica terecht en worden naar het logboekbestand van de database geschreven, maar zijn pas leesbaar nadat redo ze op de gegevensbestanden heeft toegepast.

Zie de sectie Gegevenslatentie op secundaire replica van 'Verschillen tussen beschikbaarheidsmodi voor een AlwaysOn-beschikbaarheidsgroep' voor meer informatie.

Langere tijd voor failover of RTO overschreden

Recovery Time Objective (RTO) is de maximale downtime van de database die een organisatie kan tolereren en hoe snel de organisatie weer gebruik kan maken van de database na een storing. Als er bij een failover een grote herstelwachtrij aanwezig is op een secundaire replica, kan redo op de nieuwe primaire replica langer duren dan de RTO. Nadat het opnieuw uitvoeren is voltooid, wordt de database overgezet naar de primaire rol en wordt de status weergegeven die vóór de failover bestond. Een langere hersteltijd betekent dat de productie minder snel weer wordt hervat.

Diagnostische hulpprogramma's melden een niet-gezonde beschikbaarheidsgroep

Wanneer de redo-wachtrij groot is, kan het Always On-dashboard in SQL Server Management Studio (SSMS) de beschikbaarheidsgroep als niet in orde weergeven.

Controleren of herstel in de wachtrij staat

De herstelwachtrij is een meting per database. U kunt dit controleren via het AlwaysOn-dashboard op de primaire replica of door een query uit te voeren op de sys.dm_hadr_database_replica_states dynamische beheerweergave (DMV) op de primaire of secundaire replica. Performance Monitor tellers rapporteren ook de grootte van de herstelwachtrij en de herbewerkingsfrequentie. Controleer deze tellers op de secundaire replica.

De volgende secties bieden methoden voor het actief bewaken van de databaseherstelwachtrij van uw beschikbaarheidsgroep.

Een query uitvoeren op sys.dm_hadr_database_replica_states

De sys.dm_hadr_database_replica_states DMV rapporteert een rij voor elke database met beschikbaarheidsgroepen. De redo_queue_size kolom toont de grootte van de herstelwachtrij in kilobytes. Als u de trend in de herstelwachtrij elke 30 seconden wilt bewaken, stelt u een query in zoals de volgende. Voer deze uit op de primaire replica. Hierbij wordt het is_local=0 predicaat gebruikt om gegevens voor de secundaire replica te rapporteren, waar redo_queue_size en redo_rate relevant zijn.

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

Hier ziet u hoe de uitvoer eruitziet.

Schermopname van de uitvoer voor het queryrapport de gegevens voor de secundaire replica, waarbij redo_queue_size en redo_rate relevant zijn.

Controleer de herstelwachtrij in het AlwaysOn-dashboard

Volg deze stappen om de herstelwachtrij te controleren:

  1. Selecteer in SSMS Objectverkenner een beschikbaarheidsgroep (of klik erop met de rechtermuisknop) om het contextmenu te openen.

  2. Selecteer Dashboard weergeven.

    De databases van de beschikbaarheidsgroep worden als laatste weergegeven, waarbij sommige gegevens voor elke database worden gerapporteerd. Grootte van de redo-wachtrij (KB) en redo-snelheid (KB/sec) worden niet standaard vermeld, maar u kunt ze aan de weergave toevoegen, zoals in de volgende stap wordt weergegeven.

  3. Als u deze tellers wilt toevoegen, selecteert en houdt u de koptekst boven de databaserapporten ingedrukt (of klikt u erop met de rechtermuisknop) en kiest u vervolgens de kolommen die u wilt weergeven.

  4. Als u Grootte van redo-wachtrij (KB) en Redo-snelheid (KB/sec) wilt toevoegen, houdt u de koptekst die in de volgende schermopname rood is gemarkeerd ingedrukt (of klikt u erop met de rechtermuisknop).

    Schermafbeelding waarop te zien is hoe de tellers Grootte van redo-wachtrij (KB) en Redofrequentie (KB/sec) worden toegevoegd.

    Standaard wordt in het AlwaysOn-dashboard elke 60 seconden de grootte van de redo-wachtrij (KB) en de heropmaakfrequentie (KB/sec) vernieuwd.

    Schermafbeelding waarop verversingstellers zijn ingesteld op 60 seconden.

De herstelwachtrij controleren in Prestatiemeter

Elke secundaire replica en database hebben een eigen herstelwachtrijgrootte. Voer de volgende stappen uit om de herstelwachtrij voor een beschikbaarheidsgroepdatabase te controleren:

  1. Open Prestatiemeter op de secundaire replica.

  2. Selecteer de knop Toevoegen (teller).

  3. Selecteer onder Beschikbare tellersSQLServer:Database Replica en selecteer vervolgens de tellers Herstelwachtrij en Opnieuw uitgevoerde bytes/sec.

  4. Selecteer in de keuzelijst Instance de database van de beschikbaarheidsgroep die u wilt controleren op wachtrijvorming voor herstel.

  5. Selecteer Add>OK.

    Hier ziet u hoe toenemende herstelwachtrijen eruit kunnen zien.

    Schermopname van een toename van de herstelwachtrij.

Wachtrijwaarden voor herstel interpreteren

In deze sectie wordt uitgelegd hoe u de wachtrijwaarden voor herstel interpreteert die u in de vorige sectie hebt verzameld.

Wanneer het in de wachtrij plaatsen van herstel een probleem is

Een waarde van 0 voor de herstelwachtrij betekent dat er op het moment van het rapport geen redo-achterstand was. In een drukke productieomgeving rapporteert de herstelwachtrij vaak een niet-nulwaarde, zelfs wanneer de beschikbaarheidsgroep in orde is. Tijdens de typische productie verwacht u dat de waarde tussen 0 en een niet-nulwaarde fluctueert.

Als de herstelwachtrij na verloop van tijd groeit, onderzoek dit dan verder. Groei geeft aan dat er iets is veranderd. Wanneer u plotselinge groei ziet, zijn de volgende metingen handig voor het oplossen van problemen:

  • Snelheid voor opnieuw uitvoeren van logboek (KB/sec) (Always On-dashboard)
  • redo_rate Inch sys.dm_hadr_database_replica_states

Basislijnherstelpercentages vaststellen

Controleer bij goed functionerende Always On-prestaties de redo-snelheid van uw intensief gebruikte beschikbaarheidsgroepdatabases. Leg tarieven vast tijdens normale kantooruren en tijdens onderhoudsvensters wanneer grote transacties (zoals indexrebouw of ETL-processen) een hogere doorvoer stimuleren. Vergelijk deze basislijnen wanneer u de groei van de herstelwachtrij ziet om te bepalen wat er is gewijzigd. De werklast kan groter zijn dan gebruikelijk, of het herbewerkingspercentage kan lager zijn dan verwacht, wat nader moet worden onderzocht.

Rekening houden met het workloadvolume

Zware workloads (zoals een UPDATE-bewerking op één miljoen rijen, het opnieuw opbouwen van een index op een tabel van 1 TB, of een ETL-batch die miljoenen rijen invoegt) veroorzaken doorgaans enige groei van de herstelwachtrij, hetzij onmiddellijk, hetzij na verloop van tijd. Deze groei wordt verwacht wanneer er plotseling veel wijzigingen worden aangebracht in de database van de beschikbaarheidsgroep.

Problemen met de herstelwachtrij vaststellen

Nadat u wachtrijvorming voor herstel hebt vastgesteld voor een specifieke beschikbaarheidsgroepdatabase op een secundaire replica, maakt u verbinding met de secundaire replica en voert u vervolgens een query uit op sys.dm_exec_requests om de wait_type en wait_time van herstelthreads te controleren. U zoekt een hoge frequentie van een of meer wachttypen en grote wachttijden voor deze wachttypen. De volgende voorbeeldquery wordt elke vijf seconden uitgevoerd en rapporteert wachttypen en wachttijden voor de beschikbaarheidsgroepdatabase 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

Belangrijk

Voor zinvolle uitvoer over wachttypen moet de herstelwachtrij toenemen wanneer u deze gegevens verzamelt met behulp van een van de eerder beschreven methoden.

In het volgende voorbeeld worden sommige I/O-gerelateerde wachttypen gerapporteerd (PAGEIOLATCH_UP, PAGEIOLATCH_EX). Controleer of deze wachttypen de grootste wait_time waarden blijven weergeven, zoals gerapporteerd in de volgende kolom.

Schermopname van de grootste wachttijden die in de volgende kolom zijn gerapporteerd.

Herstelwachttypen identificeren

Nadat u een wachttype hebt geïdentificeerd, raadpleegt u Redo-model en -prestaties van secundaire replica's van beschikbaarheidsgroepen ter referentie voor veelvoorkomende wachttypen die herstelwachtrijen veroorzaken en voor richtlijnen voor het oplossen van het probleem.

Geblokkeerde herstelthreads op alleen-lezen secundaire replica's

Als uw oplossing rapportagequery’s uitvoert op beschikbaarheidsgroepdatabases op een secundaire replica, verkrijgen deze alleen-lezenquery’s schema-stabiliteitsvergrendelingen (Sch-S). Sch-S-vergrendelingen kunnen redo-threads beletten schemawijzigingsvergrendelingen (Sch-M) te verkrijgen (ook wel schemawijzigingsvergrendelingen of LCK_M_SCH_M genoemd) die nodig zijn om data definition language (DDL)-wijzigingen toe te passen, zoals ALTER TABLE of ALTER INDEX. Een geblokkeerde redo-thread kan geen logboekrecords toepassen totdat deze is gedeblokkeerd, waardoor herstelwachtlijnen worden veroorzaakt.

Als u historische aanwijzingen voor een geblokkeerde redo wilt controleren, opent u met SSMS de traceringsbestanden van uitgebreide gebeurtenissen van AlwaysOn_health op de secundaire replica. lock_redo_blocked Zoek naar gebeurtenissen.

Schermopname waarop wordt gecontroleerd op historische aanwijzingen van een geblokkeerde opdracht Opnieuw uitvoeren.

Gebruik Prestatiemeter om actief de impact van geblokkeerde redo op de herstelwachtrij te bewaken. Voeg de SQL Server:Database Replica\Redo blocked/sec en SQL Server:Database Replica\Recovery Queue counters toe. In de volgende schermopname ziet u een ALTER TABLE ALTER COLUMN opdracht die wordt uitgevoerd op de primaire replica terwijl een langlopende query wordt uitgevoerd op dezelfde tabel op de secundaire replica. Het item Redo geblokkeerd/sec vertoont pieken wanneer de opdracht ALTER TABLE ALTER COLUMN wordt uitgevoerd. Hoewel de langlopende query actief is op dezelfde tabel op de secundaire replica, zorgen daaropvolgende wijzigingen op de primaire replica voor een toename van de herstelwachtrij.

Schermopname van een monitor voor het wachttype schemawijzigingsvergrendeling.

Controleer het wachttype voor de schemawijzigingsvergrendeling dat de redo-thread probeert te verwerven. Gebruik de eerdere query om te controleren welke wachttypen worden gerapporteerd voor redo-bewerkingen in sys.dm_exec_requests. U kunt zien dat de wachttijd voor LCK_M_SCH_M oploopt terwijl de redo is geblokkeerd.

Schermopname van de toenemende wachttijd voor de LCK_M_SCH_M.

Herstel met één thread

SQL Server 2016 heeft parallel herstel geïntroduceerd voor secundaire replicadatabases. Als u een eerdere versie gebruikt, zoals SQL Server 2014 of SQL Server 2012, upgrade dan naar een ondersteunde versie om parallelle redo en verbeterde redo-prestaties te krijgen.

Single-threaded redo kan nog steeds optreden in SQL Server-versies van 2016 tot en met 2019, die gebruikmaken van de parallelle herstelarchitectuur. In deze versies kan een SQL Server exemplaar maximaal 100 threads gebruiken voor parallel opnieuw uitvoeren. Het systeem wijst parallelle redo-threads toe voor databases van beschikbaarheidsgroepen op basis van het aantal processors en databases, tot dat totaal van 100 threads. Wanneer de limiet van 100 threads is bereikt, wijst het systeem enkele databases in de beschikbaarheidsgroep één nieuwe thread toe.

Als u wilt controleren of de database van uw beschikbaarheidsgroep parallel herstel gebruikt, maakt u verbinding met de secundaire replica en voert u de volgende query uit om de rijen (threads) te tellen die herstel voor de database toepassen. In het volgende voorbeeld, als de database agdb één rij heeft en de opdracht DB STARTUP is, kan de herstelwerklast baat hebben bij parallel herstel.

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')

Schermopname die laat zien hoe u kunt bepalen of uw beschikbaarheidsgroepdatabase parallel herstel gebruikt.

Als uw database gebruikmaakt van een redo met één thread, controleert u het eerdere algoritme om te controleren of SQL Server de 100 werkthreads overschrijdt die zijn toegewezen voor parallel herstel. Het bereiken van deze limiet kan de reden agdb zijn dat er slechts één redo-thread wordt gebruikt.

SQL Server 2022 en latere versies gebruiken een parallel herstelalgoritme dat workerthreads toewijst op basis van de werklast, waardoor wordt voorkomen dat een drukbezette database redo met één thread blijft gebruiken. Zie voor meer informatie de sectie Thread usage by availability groups van 'Vereisten, beperkingen en aanbevelingen voor Always On-beschikbaarheidsgroepen'.

Verwante inhoud

  • Last updated on