Delen via

Problemen met herstelwachtrijen in een AlwaysOn-beschikbaarheidsgroep oplossen

Dit artikel bevat oplossingen voor problemen met betrekking tot herstelwachtrijen.

Wat is herstelwachtrijen?

De wijzigingen die worden aangebracht in de primaire replica in een database van een beschikbaarheidsgroep, worden verzonden naar alle secundaire replica's die zijn gedefinieerd in dezelfde beschikbaarheidsgroep. Nadat deze wijzigingen bij de secundaire replica's zijn aangekomen, worden ze eerst naar het transactielogboekbestand van de database van de beschikbaarheidsgroep geschreven. Microsoft SQL Server gebruikt vervolgens de herstel - of herbewerking om de databasebestanden bij te werken.

Als de wijzigingen in een beschikbaarheidsgroep sneller binnenkomen en worden beveiligd in het databasetransactielogboekbestand dan ze kunnen worden hersteld, wordt er een herstelwachtrij gevormd. Deze wachtrij bestaat uit beveiligde transactielogboektransacties die niet zijn hersteld en daarna zijn hersteld in de database.

Symptomen en effect van herstel (opnieuw) wachtrijen

Het uitvoeren van query's op primaire en secundaire replica's retourneert verschillende resultaten

Alleen-lezenworkloads die een query uitvoeren op secundaire replica's, kunnen verouderde gegevens opvragen. Als er herstelwachtrijen optreden, worden wijzigingen in gegevens in de primaire replicadatabase mogelijk niet doorgevoerd in de secundaire database wanneer u dezelfde gegevens opvraagt.

Hoewel wijzigingen binnenkomen bij de secundaire database en naar het databaselogboekbestand worden geschreven, worden de wijzigingen pas opgevraagd nadat ze zijn hersteld en hersteld naar de databasebestanden. De herstelbewerking maakt deze wijzigingen leesbaar.

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

Failovertijd is langer of RTO wordt overschreden

Recovery Time Objective (RTO) is de maximale downtime van de database die een organisatie kan verwerken. RTO beschrijft ook hoe snel de organisatie weer toegang kan krijgen tot de database na een storing. Als er aanzienlijke herstelwachtrijen aanwezig zijn op een secundaire replica wanneer er een failover plaatsvindt, kan het herstel langer duren. Na het herstel wordt de database overgezet naar de primaire rol en wordt de status weergegeven van de database die vóór de failover bestond. Een langere hersteltijd kan vertragen hoe snel de productie na een failover wordt hervat.

Verschillende diagnostische functies rapporteren herstelwachtrijen voor beschikbaarheidsgroepen

In het geval van herstelwachtrijen kan het AlwaysOn-dashboard in SQL Server Management Studio (SSMS) een beschadigde beschikbaarheidsgroep rapporteren.

Controleren op herstelwachtrijen (opnieuw)

De herstelwachtrij is een meting per database die kan worden gecontroleerd met behulp van het AlwaysOn-dashboard op de primaire replica of met behulp van de sys.dm_hadr_database_replica_states Dynamische beheerweergave (DMV) op de primaire of secundaire replica. Prestatiemeteritems controleren de herstelwachtrijen en de herstelsnelheid. Deze tellers moeten worden gecontroleerd op de secundaire replica.

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

Query's uitvoeren sys.dm_hadr_database_replica_states

De sys.dm_hadr_database_replica_states DMV rapporteert een rij voor elke database met beschikbaarheidsgroepen. Eén kolom in het rapport is redo_queue_size. Deze waarde is de grootte van de herstelwachtrij, zoals gemeten in kilobytes. U kunt een query instellen die lijkt op de volgende query om elke trend in de herstelwachtrij elke 30 seconden te controleren. De query wordt uitgevoerd op de primaire replica. Hierbij wordt het is_local=0 predicaat gebruikt om de gegevens voor de secundaire replica te rapporteren, indien 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.

De herstelwachtrij controleren in AlwaysOn Dashboard

Volg deze stappen om de herstelwachtrij te controleren:

  1. Open het AlwaysOn-dashboard in SSMS door met de rechtermuisknop te klikken op een beschikbaarheidsgroep in SSMS Objectverkenner.

  2. Selecteer Dashboard weergeven.

    De databases van de beschikbaarheidsgroep worden als laatste weergegeven en er zijn enkele gegevens die zijn gerapporteerd in de databases. Hoewel de grootte van de wachtrij opnieuw (KB) en de redofrequentie (KB/sec) niet standaard worden vermeld, kunt u deze toevoegen aan deze weergave, zoals wordt weergegeven in de schermafbeelding in de volgende stap.

  3. Als u deze tellers wilt toevoegen, klikt u met de rechtermuisknop op de kop boven de databaserapporten en selecteert u deze in de lijst met beschikbare kolommen.

  4. Als u de grootte van de redo-wachtrij (KB) en de redo rate (KB/sec) wilt toevoegen, klikt u met de rechtermuisknop op de koptekst die rood wordt weergegeven in de volgende schermafbeelding.

    Schermopname van het toevoegen van de meteritems voor het opnieuw uitvoeren van de wachtrijgrootte (KB) en de herstartfrequentie (KB/sec).

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

    Schermopname van vernieuwingstellers ingesteld op elke 60 seconden.

De herstelwachtrij controleren in Prestatiemeter

De grootte van de herstelwachtrij is uniek voor elke secundaire replica en database. Voer daarom de volgende stappen uit om de herstelwachtrij van een beschikbaarheidsgroepdatabase te controleren:

  1. Open Prestatiemeter op de secundaire replica.

  2. Selecteer de knop Toevoegen (teller).

  3. Selecteer onder Beschikbare tellers SQLServer:Database Replica en selecteer vervolgens Herstelwachtrij en bytes per seconde opnieuw uitvoeren.

  4. Selecteer in de keuzelijst Exemplaar de database van de beschikbaarheidsgroep die u wilt bewaken voor herstelwachtrijen.

  5. Selecteer OK toevoegen>.

    Hier ziet u hoe toenemende herstelwachtrijen eruit kunnen zien.

    Schermopname van een toename van de herstelwachtrij.

Waarden voor herstelwachtrijen interpreteren

In deze sectie wordt uitgelegd hoe u de waarden kunt interpreteren die betrekking hebben op herstelwachtrijen die u in de vorige sectie hebt bepaald.

Wanneer wordt er een probleem in de wachtrij geplaatst voor herstel? Hoeveel herstelwachtrijen moet u tolereren?

U kunt ervan uitgaan dat als de herstelwachtrij een waarde van 0 rapporteert, dit betekent dat er op het moment van dat rapport geen herstelwachtrij plaatsvindt. Wanneer uw productieomgeving echter bezet is, moet u verwachten dat de herstelwachtrij regelmatig een andere waarde dan nul rapporteert, zelfs in een gezonde AlwaysOn-omgeving. Tijdens een typische productie moet u verwachten dat deze waarde fluctueert tussen 0 en een niet-nulwaarde.

Als u ziet dat de herstelwachtrij in de loop van de tijd toeneemt, is verder onderzoek gerechtvaardigd. Deze extra activiteit geeft aan dat er iets is veranderd. Als u een plotselinge groei in de herstelwachtrij ziet, zijn de volgende metingen handig voor het oplossen van problemen:

  • Logboek opnieuw uitvoeren (KB/sec) (AlwaysOn-dashboard)
  • Redo_rate in de DMV-sys.dm_hadr_database_replica_states

Basislijntarieven voor opnieuw uitvoeren

Controleer tijdens goede AlwaysOn-prestaties de herosnelheid van uw beschikbaarheidsgroepdatabases. Hoe zien ze eruit tijdens meestal drukke kantooruren? Wat zijn deze tarieven tijdens onderhoudsperioden, wanneer grote transacties (index herbouwen, ETL-processen) hogere transactiedoorvoer op het systeem stimuleren? U kunt deze waarden vergelijken wanneer u de groei van de herstelwachtrij bekijkt om te bepalen wat er is gewijzigd. De workload is mogelijk groter dan normaal. Als het heropercentage lager is, kan verder onderzoek nodig zijn om te bepalen waarom.

Workloadvolumes zijn belangrijk

Wanneer u grote werkbelastingen (zoals een UPDATE-instructie ten opzichte van één miljoen rijen, een index opnieuw opbouwt op een tabel van 1 terabyte of zelfs een ETL-batch die miljoenen rijen invoegt), moet u verwachten dat er onmiddellijk of na verloop van tijd een herstelwachtrij groeit. Dit wordt verwacht wanneer er plotseling een groot aantal wijzigingen wordt aangebracht in de database van de beschikbaarheidsgroep.

Herstelwachtrij vaststellen (opnieuw uitvoeren)

Nadat u herstelwachtrijen hebt geïdentificeerd voor een specifieke database van een secundaire replica-beschikbaarheidsgroep, maakt u verbinding met de secundaire replica en voert u vervolgens een query sys.dm_exec_requests uit om de wait_type en wait_time voor herstelthreads te bepalen. Hier volgt een query die in een lus kan worden uitgevoerd. U zoekt een hoge frequentie van een of meer wachttypen en zelfs wachttijden voor deze wachttypen. Hier volgt een voorbeeldquery die elke seconde wordt uitgevoerd en de wachttypen en wachttijden rapporteert voor de beschikbaarheidsgroep, '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 van wachttypen moet worden vastgesteld dat herstelwachtrijen toenemen wanneer u een van de eerder beschreven methoden gebruikt om deze voorwaarde te bewaken.

In dit voorbeeld worden sommige I/O-gerelateerde wachttypen gerapporteerd (PAGEIOLATCH_UP, PAGEIOATCH_EX). Controleer of deze wachttypen de grootste wait_times waarden blijven hebben, zoals vermeld in de volgende kolom.

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

Wachttypen voor opnieuw uitvoeren van SQL Server

Wanneer een wachttype wordt geïdentificeerd, raadpleegt u het volgende artikel SQL Server 2016/2017: het secundaire replicamodel en de prestaties van de beschikbaarheidsgroep opnieuw uitvoeren - Microsoft Tech Community als kruisverwijzing naar veelvoorkomende wachttypen die herstelwachtrijen veroorzaken en voor hulp bij het oplossen van het probleem.

Geblokkeerde redo-threads op secundaire rapportageservers

Als in uw oplossing rapportage (query's) worden uitgevoerd op databases van beschikbaarheidsgroepen op de secundaire replica, krijgen deze alleen-lezenquery's schemastabiliteitsvergrendelingen (Sch-S). Deze Sch-S-vergrendelingen kunnen voorkomen dat opnieuw threads schemawijzigingen (Sch-M) worden verkregen (ook wel bekend als 'schema modify locks' of LCK_M_SCH_M) om eventuele DDL-wijzigingen (Data Definition Language) aan te brengen, zoals ALTER TABLE of ALTER INDEX. Een geblokkeerde redo-thread kan geen logboekrecords toepassen totdat deze is gedeblokkeerd. Dit kan leiden tot herstelwachtrijen.

Als u wilt controleren op historisch bewijs van een geblokkeerde hero, opent u de AlwaysOn_health Xevent-traceringsbestanden op de secundaire replica met behulp van SSMS. lock_redo_blocked Zoek naar gebeurtenissen.

Schermopname van het controleren op historisch bewijs van een geblokkeerde hero.

Gebruik Prestatiemeter om de gevolgen voor opnieuw uitvoeren actief te bewaken voor de herstelwachtrij. Voeg de SQL Server::D atabase Replica:::Redo blocked/sec en SQL Server::D atabase 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. De teller Opnieuw geblokkeerd per seconde geeft aan dat de ALTER TABLE ALTER COLUMN opdracht wordt uitgevoerd. Terwijl de langlopende query wordt uitgevoerd in dezelfde tabel op de secundaire replica, leiden alle volgende wijzigingen op de primaire replica tot een toename in de herstelwachtrij.

Schermopname van een monitor voor het wachttype schemawijzigingsvergrendeling.

Controleer op het wachttype voor schemawijzigingsvergrendeling dat de redo-thread probeert te verkrijgen. Als u dit wilt doen, gebruikt u de query die eerder is beschreven om de wachttypen te controleren die worden gerapporteerd voor opnieuw uitvoeren van bewerkingen sys.dm_exec_requests. U kunt de toenemende wachttijd voor de LCK_M_SCH_M lopende heroblokkering observeren.

Schermopname van de toenemende wachttijd voor de LCK_M_SCH_M.

Opnieuw met één thread

SQL Server heeft parallel herstel geïntroduceerd voor secundaire replicadatabases in Microsoft SQL Server 2016. Als u herstelwachtrijen ondervindt wanneer u SQL Microsoft Server 2012 of Microsoft SQL Server 2014 uitvoert, kunt u een upgrade uitvoeren naar een latere versie van het programma om de prestaties opnieuw in uw productieomgeving te verbeteren.

Een redo met één thread kan zelfs later plaatsvinden in meer geavanceerde SQL Server-versies waarin parallelle herstelarchitectuur wordt gebruikt. In deze versies kan een SQL Server-exemplaar maximaal 100 threads gebruiken voor een parallelle heruitvoering. Afhankelijk van het aantal processors en databases van beschikbaarheidsgroepen, worden parallelle redo-threads toegewezen tot maximaal 100 totale threads. Als de limiet voor opnieuw uitvoeren van 100 threads is bereikt, krijgen sommige databases in de beschikbaarheidsgroep één redo-thread toegewezen.

Als u wilt bepalen of uw beschikbaarheidsgroepdatabase parallel herstel gebruikt, maakt u verbinding met de secundaire replica en gebruikt u de volgende query om het aantal rijen (threads) te bepalen dat herstel toepast op de database van de beschikbaarheidsgroep. Als de 'agdb'-database in het volgende voorbeeld één thread is en de opdracht is, kan DB STARTUPde herstelworkload profiteren van 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 u controleert of uw database gebruikmaakt van een redo met één thread, controleert u het algoritme dat eerder is beschreven om te bepalen of SQL Server het aantal 100 werkthreads overschrijdt dat is toegewezen voor parallel herstel. Een dergelijke voorwaarde kan de reden zijn dat de 'agdb'-database slechts één thread gebruikt voor herstel.

SQL Server 2022 maakt nu gebruik van een nieuw algoritme voor parallel herstel, zodat werkrolthreads worden toegewezen voor parallel herstel op basis van de workload. Dit elimineert de kans dat een drukke database in een herstel met één thread blijft. Zie de sectie Threadgebruik per beschikbaarheidsgroep van Vereisten, Beperkingen en Aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen voor meer informatie.

  • Last updated on