Delen via

Problemen met herstelwachtrijen oplossen in een AlwaysOn-beschikbaarheidsgroep

  • Artikel

Dit artikel bevat oplossingen voor problemen met betrekking tot herstelwachtrijen.

Wat is een herstelwachtrij?

Wijzigingen die worden aangebracht in de primaire replica in een beschikbaarheidsgroepdatabase, 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 vervolgens de herstel- of redo-bewerking gebruiken 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 hersteld naar de database.

Symptomen en effect van een herstelwachtrij (opnieuw)

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

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

Hoewel wijzigingen binnenkomen in de secundaire database en naar het databaselogboekbestand worden geschreven, worden de wijzigingen pas opgevraagd als 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 is 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 een aanzienlijke herstelwachtrij aanwezig is op een secundaire replica wanneer er een failover optreedt, kan het herstel langer duren. Na het herstel gaat de database over naar de primaire rol en vertegenwoordigt deze de status van de database die bestond vóór de failover. Een langere hersteltijd kan vertragen hoe snel de productie na een failover wordt hervat.

Verschillende diagnostische functies rapporteren de wachtrij voor herstel van beschikbaarheidsgroepen

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

Controleren op herstelwachtrij (opnieuw)

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 herstelwachtrij en het herstelpercentage. Deze tellers moeten worden gecontroleerd op basis van de secundaire replica.

De volgende secties bevatten methoden om de databaseherstelwachtrij van uw beschikbaarheidsgroep actief te bewaken.

Query sys.dm_hadr_database_replica_states

De sys.dm_hadr_database_replica_states DMV rapporteert een rij voor elke beschikbaarheidsgroepdatabase. 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 30 seconden een trend in de grootte van de herstelwachtrij te bewaken. De query wordt uitgevoerd op de primaire replica. Het predicaat gebruikt om is_local=0 de 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

De uitvoer ziet er als volgt uit.

Schermopname van de uitvoer voor de query rapporteert de gegevens voor de secundaire replica waarbij redo_queue_size en redo_rate relevant zijn.

De herstelwachtrij controleren in AlwaysOn Dashboard

Voer de volgende stappen uit 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 beschikbaarheidsgroepdatabases worden als laatste vermeld en er zijn enkele gegevens gerapporteerd in de databases. Hoewel De grootte van de opnieuw uitgevoerde wachtrij (KB) en de frequentie voor opnieuw uitvoeren (kB/sec) niet standaard worden vermeld, kunt u ze toevoegen aan deze weergave, zoals wordt weergegeven in de schermafbeelding in de volgende stap.

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

  4. Als u De grootte van de opnieuw uitgevoerde wachtrij (KB) en de frequentie voor opnieuw uitvoeren (KB per seconde) wilt toevoegen, klikt u met de rechtermuisknop op de koptekst die wordt weergegeven als rood gemarkeerd in de volgende schermopname.

    Schermopname van het toevoegen van de tellers Wachtrijgrootte opnieuw (KB) en Frequentie van opnieuw uitvoeren (KB/sec).

    Standaard worden in het AlwaysOn-dashboard elke 60 seconden de grootte van de wachtrij opnieuw (KB) en de frequentie van opnieuw uitvoeren (KB/sec) automatisch vernieuwd.

    Schermopname van vernieuwingstellers die zijn 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 tellersde optie 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 herstelwachtrij.

  5. Selecteer Ok toevoegen>.

    Hier ziet u hoe het verhogen van de herstelwachtrij eruit kan zien.

    Schermopname van een toename in de herstelwachtrij.

Waarden voor herstelwachtrij 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 is er een probleem met het in de wachtrij plaatsen van herstel? Hoeveel herstelwachtrij moet u tolereren?

U kunt ervan uitgaan dat als de herstelwachtrij een waarde van 0 rapporteert, dit betekent dat er geen herstelwachtrij plaatsvindt op het moment van dat rapport. 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 normale productie moet u verwachten dat deze waarde schommelt tussen 0 en een niet-nulwaarde.

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

  • Tarief voor opnieuw uitvoeren van logboeken (KB/sec) (AlwaysOn-dashboard)
  • Redo_rate in de DMV-sys.dm_hadr_database_replica_states

Basislijntarieven ophalen voor hernieuwingsfrequentie

Bewaak tijdens de goede AlwaysOn-prestaties de heruitvoeringsfrequentie voor de beschikbaarheidsgroepdatabases die bezet zijn. Hoe zien ze eruit tijdens normaal gesproken drukke kantooruren? Wat zijn deze tarieven tijdens onderhoudsperioden, wanneer grote transacties (indexrebouw, ETL-processen) een hogere transactiedoorvoer op het systeem genereren? U kunt deze waarden vergelijken wanneer u de groei van de herstelwachtrij ziet om te bepalen wat er is gewijzigd. De workload is mogelijk groter dan normaal. Als het aantal opnieuw uitvoeren lager is, is mogelijk verder onderzoek nodig om te bepalen waarom.

Workloadvolumes zijn belangrijk

Wanneer u grote workloads hebt (zoals een UPDATE-instructie voor een miljoen rijen, een index opnieuw opbouwen in een tabel van 1 terabyte of zelfs een ETL-batch die miljoenen rijen invoegt), zou u direct of na verloop van tijd enige groei van de herstelwachtrij moeten verwachten. Dit wordt verwacht wanneer er plotseling een groot aantal wijzigingen wordt aangebracht in de database van de beschikbaarheidsgroep.

Een herstelwachtrij vaststellen (opnieuw uitvoeren)

Nadat u de herstelwachtrij voor een specifieke database van een secundaire replica-beschikbaarheidsgroep hebt geïdentificeerd, maakt u verbinding met de secundaire replica en voert u een query sys.dm_exec_requests uit om de wait_type en wait_time te bepalen voor herstelthreads. 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 voor de beschikbaarheidsgroep agdb rapporteert:

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 een zinvolle uitvoer van het wachttype moet worden vastgesteld dat de herstelwachtrij toeneemt wanneer u een van de methoden gebruikt die eerder zijn beschreven om deze voorwaarde te bewaken.

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

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

wachttypen opnieuw SQL Server

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

Geblokkeerde threads voor opnieuw uitvoeren op secundaire rapportageservers

Als uw oplossing rapportage (query's) omstuurt naar beschikbaarheidsgroepdatabases op de secundaire replica, krijgen deze alleen-lezenquery's schemastabiliteitsvergrendelingen (Sch-S). Deze Sch-S-vergrendelingen kunnen redo-threads blokkeren voor het verkrijgen van schemawijzigingsvergrendelingen (ook wel bekend als 'schemawijzigingsvergrendelingen' of LCK_M_SCH_M) om DDL-wijzigingen (Data Definition Language) aan te brengen, zoals ALTER TABLE of ALTER INDEX. Met een geblokkeerde redo-thread kunnen geen logboekrecords worden toegepast totdat de blokkering is opgeheven. Dit kan leiden tot een herstelwachtrij.

Als u wilt controleren op historisch bewijs van een geblokkeerde redo, 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 redo.

Gebruik Prestatiemeter om de impact van geblokkeerde redo's op de herstelwachtrij actief te bewaken. Voeg de SQL Server::D atabase Replica::Opnieuw geblokkeerd per seconde en SQL Server::D atabase Replica::Recovery Queue 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 op dezelfde tabel op de secundaire replica, veroorzaken eventuele volgende wijzigingen op de primaire replica een toename van de herstelwachtrij.

Schermopname van een monitor voor het wachttype vergrendeling voor schemawijziging.

Controleer op het wachttype voor het wijzigen van het vergrendelingsslot van het schema dat de opnieuw-thread probeert te verkrijgen. Hiervoor gebruikt u de query die eerder is beschreven om de wachttypen te controleren die worden gerapporteerd voor redo-bewerkingen voor sys.dm_exec_requests. U kunt de toenemende wachttijd voor de LCK_M_SCH_M in de doorlopende blokkering voor opnieuw uitvoeren observeren.

Schermopname van de toenemende wachttijd voor de LCK_M_SCH_M.

Opnieuw met één thread

SQL Server parallel herstel geïntroduceerd voor secundaire replicadatabases in Microsoft SQL Server 2016. Als u te maken krijgt met een herstelwachtrij wanneer u SQL Microsoft Server 2012 of Microsoft SQL Server 2014 uitvoert, kunt u upgraden naar een latere versie van het programma om de redo-prestaties in uw productieomgeving te verbeteren.

Een opnieuw uitvoeren met één thread kan zelfs in latere, geavanceerdere SQL Server versies plaatsvinden 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 beschikbaarheidsgroepdatabases worden parallelle opnieuw threads toegewezen tot een maximum van 100 threads in totaal. Als de limiet voor opnieuw uitvoeren van 100 threads is bereikt, wordt aan sommige databases in de beschikbaarheidsgroep één opnieuw thread toegewezen.

Als u wilt bepalen of de database van uw beschikbaarheidsgroep gebruikmaakt van parallel herstel, maakt u verbinding met de secundaire replica en gebruikt u de volgende query om het aantal rijen (threads) te bepalen dat herstel toepast voor de database van de beschikbaarheidsgroep. In het volgende voorbeeld, als de 'agdb'-database éé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 gebruikmaakt van parallel herstel.

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