Symptom
Anta att du använder gruppen AlwaysOn-tillgänglighet i en Microsoft SQL Server 2012-eller SQL Server 2014-databas och en stor öppen aktiv transaktion finns och kräver ytterligare logg utrymme. När logg filen inte kan växa av någon av följande orsaker Miss lyckas transaktionen.
-
Avsaknad av ytterligare fil utrymme
-
Logg filen har kon figurer ATS för att inte växa
-
Logg filen har nått sin konfigurerade Max storlek
Dessutom visas följande felmeddelande:
Fel: 9002, allvarlighets grad: 17, State: 9. transaktions loggen för databasen <databasens namn> är full på grund av "LOG_BACKUP".
När du har kört en logg säkerhets kopiering får du ett annat 9002-fel meddelande:
Fel: 9002, allvarlighets grad: 17, State: 9. transaktions loggen för databasen <databasens namn> är full på grund av "ACTIVE_TRANSACTION".
Efter en annan logg säkerhets kopiering får du ett ytterligare 9002-felmeddelande följt av ett fel meddelande om 5901:
Fel: 9002, allvarlighets grad: 17, State: 9. transaktions loggen för databasen <databasens namn> är full på grund av "AVAILABILITY_REPLICA".
Det gick inte att skriva en kontroll punkts post i databasen <databas namnet> eftersom loggen är slut. Kontakta databas administratören för att trunkera loggen eller tilldela mer utrymme till databasens loggfiler. Fel: 5901, allvarlighets grad: 16, tillstånd: 1. en eller flera återställnings enheter som tillhör databasen <databas namnet> kunde inte skapa en kontroll punkt. Detta orsakas vanligt vis av saknade system resurser, till exempel disk eller minne, eller i vissa fall på grund av skada på databasen. Granska tidigare poster i fel loggen för mer information om felet.
När den efterföljande kontroll punkten eller logg säkerhets kopieringen görs när transaktionen återkallas kan följande fel meddelande visas:
Meddelande 3052, nivå 16, tillstånd 1, Line 4BACKUP LOG kunde inte logga uppdateringar för databasen <databas namnet>. Efterföljande logg säkerhets kopior måste kräva säkerhets kopierings punkten från "<LSN ID 1>" till "<LSN-ID 2>" efter att logg utrymmet är tillgängligt för loggning av dem.
När du får dessa meddelanden kan du inte längre skicka nya transaktioner till databasen, och du kan inte öka logg filen eller lägga till en till loggfil.
Lösning
Problemet är först åtgärdat i den kumulativa uppdateringen av SQL Server:
Varje ny kumulativ uppdatering för SQL Server innehåller alla snabb korrigeringar och alla säkerhets korrigeringar som ingick i den föregående kumulativa uppdateringen. Vi rekommenderar att du laddar ner och installerar de senaste kumulativa uppdateringarna för SQL Server:
Lösning
Du kan använda följande lösning för att trunkera aktivitets-och återställnings aktivitet.
-
Kontrol lera varje sekundär replik för att verifiera att den sekundära repliken last_hardened_lsn (se sys.dm_hadr_database_replica_states) matchar primär replik last_hardened_lsn. Du kan göra det genom att köra följande fråga som är ansluten till den primära replik instansen
SELECT ags.name as AGGroupName, ar.replica_server_name as InstanceName, hars.role_desc, db_name(drs.database_id)as DBName, drs.last_hardened_lsn, drs.log_send_queue_size, drs.synchronization_state_desc as SyncState, ar.availability_mode_desc as SyncMode, CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id LEFT JOIN sys.availability_groups ags ON ar.group_id = ags.group_id LEFT JOIN sys.dm_hadr_availability_replica_states hars ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id WHERE db_name(drs.database_id) = '<database name>'
-
På den primära repliken
-
Ta bort databasen från tillgänglighets gruppen.
-
Lägg till databasen i tillgänglighets gruppen igen.
-
-
För varje sekundär replik
-
Lägg till databasen i tillgänglighets gruppen igen.
-
Genom att ta bort databasen från tillgänglighets gruppen kommer den omedelbart att trunkera sina loggar och frigöra logg utrymme. Om last_hardened_lsn på varje sekundär replik är identiskt med den primära repliken, och ingen loggnings säkerhets kopiering görs under tiden för att ta bort databasen från tillgänglighets gruppen och sedan lägga till databasen på nytt, kommer den sekundära repliken att läggas till igen utan några fel eller behöva återställa loggnings säkerhets kopior på den sekundära. Om en sekundär replik inte är aktuell med den primära repliken och du måste ta bort databasen från tillgänglighets gruppen innan den sekundära kan komma igång, kan det hända att den sekundära repliken måste ha säkerhets kopior återställda innan du lägger till den i tillgänglighets gruppen, eller genom att släppa databasen på den sekundära repliken och dirigera om den med en fullständig och transaktions logg databas säkerhets kopiering.
Status
Microsoft har bekräftat att det här är ett problem i Microsoft-produkterna som nämns i "gäller".
