Simptome
Să presupunem că utilizați grup de disponibilitate cu AlwaysOn într-o bază de date Microsoft SQL Server 2012 sau SQL Server 2014 și o tranzacție activă deschisă mare există și necesită spațiu suplimentar de jurnal. Atunci când fișierul jurnal nu poate crește pentru unul dintre motivele următoare, tranzacția nu reușește.
-
Lipsă de spațiu suplimentar pentru fișiere
-
Fișierul jurnal este configurat să nu crească
-
Fișierul jurnal a atins dimensiunea maximă configurată
În plus, veți primi următorul mesaj de eroare:
Eroare: 9002, severitate: 17, stare: 9. Jurnalul de tranzacții pentru baza de date ' <numele bazei de date> ' este plin din cauza ' LOG_BACKUP '.
După ce ați rulat o copie de rezervă jurnal, primiți un alt mesaj de eroare 9002:
Eroare: 9002, severitate: 17, stare: 9. Jurnalul de tranzacții pentru baza de date ' <numele bazei de date> ' este plin din cauza ' ACTIVE_TRANSACTION '.
După un alt backup de jurnal, veți primi apoi un alt mesaj de eroare 9002 urmat de un mesaj de eroare 5901:
Eroare: 9002, severitate: 17, stare: 9. Jurnalul de tranzacții pentru baza de date ' <numele bazei de date> ' este plin din cauza ' AVAILABILITY_REPLICA '.
Imposibil de scris o înregistrare de Checkpoint în baza de date <numele bazei de date>, deoarece jurnalul este în afara spațiului. Contactați administratorul bazei de date pentru a trunchia Jurnalul sau a aloca mai mult spațiu în fișierele jurnal de bază de date. Eroare: 5901, severitate: 16, stare: 1. una sau mai multe unități de recuperare care aparțin bazei de date ' <Nume bază de date> ' nu a reușit să genereze un punct de control. Acest lucru este cauzat de obicei de lipsa resurselor de sistem, cum ar fi disc sau memorie sau, în unele cazuri, din cauza corupției bazei de date. Examinați intrările anterioare din jurnalul de erori pentru informații mai detaliate despre această eroare.
Atunci când vor fi efectuate apoi backupurile de Checkpoint sau jurnal ulterioare în timpul revenirii tranzacției, este posibil să primiți următorul mesaj de eroare:
MSG 3052, nivel 16, stat 1, 4BACKUP linie jurnal nu a reușit să se conecteze la actualizări pentru baza de date ' <numele bazei de date> '. Rezervările ulterioare de jurnal vor fi necesare pentru a avansa punctul de backup din ' <LSN ID 1> ' to ' <LSN ID 2> ' după ce spațiul jurnal este pus la dispoziție pentru înregistrarea lor.
Atunci când primiți aceste mesaje, nu mai puteți trimite nicio tranzacție nouă în baza de date și nu puteți să creșteți fișierul jurnal sau să adăugați un alt fișier jurnal.
Rezolvare
Problema a fost remediată pentru prima dată în următoarea actualizare cumulativă de SQL Server:
Fiecare nouă actualizare cumulativă pentru SQL Server conține toate remedierile rapide și toate remedierile de securitate care au fost incluse în actualizarea cumulativă anterioară. Vă recomandăm să descărcați și să instalați cele mai recente actualizări cumulative pentru SQL Server:
Soluție de evitare
Puteți utiliza următoarea soluție pentru a trunchia jurnalele și a relua activitatea.
-
Verificați fiecare dublură secundară pentru a verifica reproducerea secundară last_hardened_lsn (consultați sys.dm_hadr_database_replica_states) se potrivește cu last_hardened_lsnreplicare primară. Puteți face acest lucru executând următoarea interogare care este conectată la instanța replica principală
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>'
-
În reproducerea principală
-
Eliminați baza de date din grupul disponibilitate.
-
Adăugați din nou baza de date la grupul disponibilitate.
-
-
Pe fiecare dublură secundară
-
Adăugați din nou baza de date la grupul disponibilitate.
-
Prin eliminarea bazei de date din grupul disponibilitate, acesta va trunchia imediat jurnalele sale și va elibera spațiul din jurnal. Dacă last_hardened_lsn de pe fiecare dublură secundară este identică cu replica principală și nu se efectuează backupuri în jurnal în timpul eliminării bazei de date din grupul disponibilitate și adăugând din nou baza de date pe fiecare secundar, reproducerea secundară va fi readăugată cu succes fără erori sau trebuie să restaureze backupurile din jurnal pe secundar. Dacă o dublură secundară nu este curentă cu reproducerea principală și trebuie să eliminați baza de date din grupul disponibilitate înainte ca secundarul să poată recupera, replica secundară poate fi necesar să aibă backupuri de jurnal restaurate pentru a-l prinde înainte de a-l adăuga în grupul disponibilitate sau pentru a returna baza de date secundară și a-l reseeda cu o copie de
Stare
Microsoft a confirmat că aceasta este o problemă în produsele Microsoft enumerate în secțiunea „Se aplică la”.
