Delen via

Fout 9002: Het transactielogboek voor de database is vol vanwege het foutbericht AVAILABILITY_REPLICA in SQL Server

Dit artikel helpt u bij het oplossen van de 9002-fout die optreedt wanneer het transactielogboek groot wordt of onvoldoende ruimte heeft in SQL Server.

Oorspronkelijke productversie: SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Oorspronkelijk KB-nummer: 2922898

Symptomen

Bekijk het volgende scenario:

  • U hebt Microsoft SQL Server 2012 of een latere versie geïnstalleerd op een server.
  • Het exemplaar van SQL Server is een primaire replica in de AlwaysOn-beschikbaarheidsgroepen-omgeving.
  • De optie voor automatische groei voor transactielogboekbestanden is ingesteld in SQL Server.

In dit scenario kan het transactielogboek groot worden en onvoldoende schijfruimte hebben of de optie MaxSize overschrijden die is ingesteld voor het transactielogboek op de primaire replica en u ontvangt een foutbericht dat er ongeveer als volgt uitziet:

Fout: 9002, Ernst: 17, Status: 9. Het transactielogboek voor database %.*ls is vol vanwege 'AVAILABILITY_REPLICA'

Oorzaak

Dit gebeurt wanneer de vastgelegde wijzigingen op de primaire replica nog niet zijn beperkt op de secundaire replica. Zie Het proces voor gegevenssynchronisatie in de AlwaysOn-omgeving voor meer informatie over het proces voor gegevenssynchronisatie.

Probleemoplossing

Er zijn twee scenario's die kunnen leiden tot logboekgroei in een beschikbaarheidsdatabase en het 'AVAILABILITY_REPLICA' log_reuse_wait_descvolgende:

  • Scenario 1: Latentie die vastgelegde wijzigingen aan secundaire gegevens levert

    Wanneer transacties gegevens in de primaire replica wijzigen, worden deze wijzigingen ingekapseld in logboekrecordblokken en worden deze vastgelegde blokken geleverd en beperkt tot het databaselogboekbestand op de secundaire replica. De primaire replica kan logboekblokken niet overschrijven in een eigen logboekbestand totdat deze logboekblokken zijn geleverd en worden beperkt tot het bijbehorende databaselogboekbestand in alle secundaire replica's. Elke vertraging in de levering of het beperken van deze blokken naar een replica in de beschikbaarheidsgroep voorkomt dat deze vastgelegde wijzigingen in de database op de primaire replica worden afgekapt en dat het logboekbestandsgebruik toeneemt.

    Zie Hoge netwerklatentie of lage netwerkdoorvoer zorgt ervoor dat logboeken worden opgebouwd op de primaire replica voor meer informatie.

  • Scenario 2: Latentie opnieuw uitvoeren

    Zodra het logboekbestand van de secundaire database is beperkt, past een toegewezen redo-thread in het secundaire replica-exemplaar de ingesloten logboekrecords toe op de bijbehorende gegevensbestanden. De primaire replica kan logboekblokken niet overschrijven in een eigen logboekbestand totdat alle threads in alle secundaire replica's de ingesloten logboekrecords hebben toegepast.

    Als de herbewerking op een secundaire replica niet kan worden bijgehouden met de snelheid waarmee logboekblokken worden beveiligd op die secundaire replica, leidt dit tot logboekgroei bij de primaire replica. De primaire replica kan alleen het eigen transactielogboek afkappen en opnieuw gebruiken tot het punt dat alle redo-threads van de secundaire replica zijn toegepast. Als er meer dan één secundaire database is, vergelijkt u de truncation_lsn kolom van de sys.dm_hadr_database_replica_states dynamische beheerweergave over de meerdere secundaire secundaire databases om te bepalen welke secundaire database het meest de afkapping van het logboek vertraagt.

    U kunt de alwayson-dashboardweergaven en sys.dm_hadr_database_replica_states dynamische beheerweergaven gebruiken om de wachtrij voor het verzenden van logboeken en de wachtrij opnieuw te bewaken. Enkele sleutelvelden zijn:

    Veld Beschrijving
    log_send_queue_size Hoeveelheid logboekrecords die niet bij de secundaire replica zijn aangekomen
    log_send_rate Snelheid waarmee logboekrecords naar de secundaire databases worden verzonden.
    redo_queue_size De hoeveelheid logboekrecords in de logboekbestanden van de secundaire replica die nog niet opnieuw is uitgevoerd, in kilobytes (KB).
    redo_rate De snelheid waarmee de logboekrecords opnieuw worden uitgevoerd op een bepaalde secundaire database, in kilobytes (KB)/seconde.
    last_redone_lsn Het werkelijke logboekvolgordenummer van de laatste logboekrecord die opnieuw is uitgevoerd op de secundaire database. last_redone_lsn is altijd minder dan last_hardened_lsn.
    last_received_lsn De logboekblok-id die het punt aangeeft waartoe alle logboekblokken zijn ontvangen door de secundaire replica die als host fungeert voor deze secundaire database. Geeft een logboekblok-id weer die is opgevuld met nullen. Het is geen echt volgnummer voor logboeken.

    Voer bijvoorbeeld de volgende query uit op de primaire replica om de replica te rapporteren met de vroegste truncation_lsn en is de bovengrens die de primaire kan vrijmaken in een eigen transactielogboek:

    SELECT ag.name AS [availability_group_name]
, d.name AS [database_name]
, ar.replica_server_name AS [replica_instance_name]
, drs.truncation_lsn , drs.log_send_queue_size
, drs.redo_queue_size
FROM sys.availability_groups ag
INNER JOIN sys.availability_replicas ar
    ON ar.group_id = ag.group_id
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON drs.replica_id = ar.replica_id
INNER JOIN sys.databases d
    ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC

    Corrigerende maatregelen kunnen omvatten, maar zijn niet beperkt tot het volgende:

    • Zorg ervoor dat er geen knelpunten voor resources of prestaties zijn op het secundaire niveau.
    • Zorg ervoor dat de redo-thread niet is geblokkeerd op de secundaire. Gebruik de lock_redo_blocked uitgebreide gebeurtenis om te bepalen wanneer dit gebeurt en op welke objecten de redo-thread wordt geblokkeerd.

Tijdelijke oplossing

Nadat u de secundaire database hebt geïdentificeerd die dit doet, kunt u een of meer van de volgende methoden proberen om dit probleem tijdelijk te omzeilen:

  • Haal de database uit de beschikbaarheidsgroep voor de secundaire offending.

    Notitie

    Deze methode leidt tot het verlies van het scenario voor hoge beschikbaarheid/herstel na noodgevallen voor de secundaire. Mogelijk moet u de beschikbaarheidsgroep later opnieuw instellen.

  • Als de redo-thread vaak wordt geblokkeerd, schakelt u de Readable Secondary functie uit door de ALLOW_CONNECTIONS parameter van de SECONDARY_ROLE replica te wijzigen in NEE.

    Notitie

    Hiermee voorkomt u dat gebruikers de gegevens in de secundaire replica lezen. Dit is de hoofdoorzaak van de blokkering. Zodra de wachtrij opnieuw is uitgevoerd tot een acceptabele grootte, kunt u overwegen de functie opnieuw in te schakelen.

  • Schakel de instelling voor automatische groei in als deze is uitgeschakeld en er schijfruimte beschikbaar is.

  • Verhoog de waarde MaxSize voor het transactielogboekbestand als het is bereikt en er schijfruimte beschikbaar is.

  • Voeg een extra transactielogboekbestand toe als het huidige bestand het systeem maximum van 2 TB heeft bereikt of als er extra ruimte beschikbaar is op een ander beschikbaar volume.

Meer informatie

Van toepassing op

  • SQL Server 2012 Enterprise
  • SQL Server 2014 Enterprise
  • SQL Server 2014 Business Intelligence
  • SQL Server 2014 Standard
  • SQL Server 2016 Enterprise
  • SQL Server 2016 Standard
  • SQL Server 2017 Enterprise
  • SQL Server 2017 Standard Windows