Dela via

Fel 9002: Transaktionsloggen för databasen är full på grund av felmeddelandet AVAILABILITY_REPLICA i SQL Server

Den här artikeln hjälper dig att lösa 9002-felet som uppstår när transaktionsloggen blir stor eller får slut på utrymme i SQL Server.

Ursprunglig produktversion: SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Ursprungligt KB-nummer: 2922898

Symptom

Föreställ dig följande scenario:

  • Du har Microsoft SQL Server 2012 eller en senare version installerad på en server.
  • Instansen av SQL Server är en primär replik i miljön AlwaysOn-tillgänglighetsgrupper.
  • Alternativet autogrow för transaktionsloggfiler anges i SQL Server.

I det här scenariot kan transaktionsloggen bli stor och få slut på diskutrymme eller överskrida maxstorleksalternativuppsättningen för transaktionsloggen på den primära repliken och du får ett felmeddelande som liknar följande:

Fel: 9002, Allvarlighetsgrad: 17, Tillstånd: 9. Transaktionsloggen för databasen %.*ls är full på grund av "AVAILABILITY_REPLICA"

Orsak

Detta inträffar när de loggade ändringarna på den primära repliken ännu inte är härdade på den sekundära repliken. Mer information om datasynkroniseringsprocessen i AlwaysOn-miljön finns i Datasynkroniseringsprocess.

Felsökning

Det finns två scenarier som kan leda till loggtillväxt i en tillgänglighetsdatabas och 'AVAILABILITY_REPLICA' log_reuse_wait_desc:

  • Scenario 1: Svarstid som levererar loggade ändringar till sekundär

    När transaktioner ändrar data i den primära repliken kapslas dessa ändringar in i loggpostblock och dessa loggade block levereras och härdas till databasloggfilen på den sekundära repliken. Den primära repliken kan inte skriva över loggblock i sin egen loggfil förrän dessa loggblock har levererats och förstärkts till motsvarande databasloggfil i alla sekundära repliker. Eventuella fördröjningar i leveransen eller härdningen av dessa block till en replik i tillgänglighetsgruppen förhindrar trunkering av de loggade ändringarna i databasen på den primära repliken och gör att loggfilens användning växer.

    Mer information finns i Hög nätverkssvarstid eller lågt nätverksdataflöde orsakar logguppbyggnad på den primära repliken.

  • Scenario 2: Gör om svarstiden

    När den härdats till den sekundära databasloggfilen tillämpar en dedikerad omtrådningstråd i den sekundära replikinstansen de inneslutna loggposterna på motsvarande datafiler. Den primära repliken kan inte skriva över loggblock i sin egen loggfil förrän alla omgjorda trådar i alla sekundära repliker har tillämpat de inneslutna loggposterna.

    Om åtgärden gör om på en sekundär replik inte kan hålla jämna drag med den hastighet med vilken loggblocken är härdade vid den sekundära repliken, leder det till loggtillväxt på den primära repliken. Den primära repliken kan bara trunkera och återanvända sin egen transaktionslogg upp till den punkt som alla sekundära replikernas omarbetningstrådar har tillämpats. Om det finns mer än en sekundär kan du jämföra truncation_lsn kolumnen i den sys.dm_hadr_database_replica_states dynamiska hanteringsvyn över flera sekundärfiler för att identifiera vilken sekundär databas som fördröjer loggtrunkeringen mest.

    Du kan använda alwayson-instrumentpanelen och sys.dm_hadr_database_replica_states dynamiska hanteringsvyer för att övervaka loggens sändningskö och göra om kön. Några viktiga fält är:

    Fält beskrivning
    log_send_queue_size Antal loggposter som inte har kommit till den sekundära repliken
    log_send_rate Hastighet med vilken loggposter skickas till de sekundära databaserna.
    redo_queue_size Mängden loggposter i loggfilerna för den sekundära repliken som ännu inte har gjorts om, i kilobyte (KB).
    redo_rate Den hastighet med vilken loggposterna görs om på en viss sekundär databas, i kilobyte (KB)/sekund.
    last_redone_lsn Verkligt loggsekvensnummer för den senaste loggposten som gjordes om på den sekundära databasen. last_redone_lsn är alltid mindre än last_hardened_lsn.
    last_received_lsn Loggblocks-ID:t som identifierar den punkt som alla loggblock har tagits emot av den sekundära repliken som är värd för den sekundära databasen. Visar ett loggblocks-ID med nollor. Det är inte ett verkligt loggsekvensnummer.

    Kör till exempel följande fråga mot den primära repliken för att rapportera repliken med den tidigaste truncation_lsn och är den övre gränsen som den primära kan frigöra i sin egen transaktionslogg:

    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

    Korrigerande åtgärder kan omfatta men är inte begränsade till följande:

    • Kontrollera att det inte finns någon resurs- eller prestandaflaskhals på den sekundära.
    • Kontrollera att Gör om-tråden inte är blockerad på den sekundära. Använd den lock_redo_blocked utökade händelsen för att identifiera när detta inträffar och vilka objekt som omgjorda tråden blockeras.

Lösning

När du har identifierat den sekundära databas som gör detta kan du prova en eller flera av följande metoder för att tillfälligt lösa problemet:

  • Ta bort databasen från tillgänglighetsgruppen för den felaktiga sekundära.

    Kommentar

    Den här metoden resulterar i förlust av scenariot hög tillgänglighet/haveriberedskap för den sekundära. Du kan behöva konfigurera tillgänglighetsgruppen igen i framtiden.

  • Om om du ofta blockerar omtråden Readable Secondary inaktiverar du funktionen genom att ändra parametern SECONDARY_ROLE ALLOW_CONNECTIONS för repliken till NEJ.

    Kommentar

    Detta hindrar användare från att läsa data i den sekundära repliken, vilket är rotorsaken till blockeringen. När redo-kön har sjunkit till en acceptabel storlek kan du överväga att aktivera funktionen igen.

  • Aktivera autogrow-inställningen om den är inaktiverad och det finns tillgängligt diskutrymme.

  • Öka MaxSize-värdet för transaktionsloggfilen om den har nåtts och det finns tillgängligt diskutrymme.

  • Lägg till ytterligare en transaktionsloggfil om den aktuella har nått systemets maximalt 2 TB eller om ytterligare utrymme är tillgängligt på en annan tillgänglig volym.

Mer information

Gäller för

  • 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