KB3095156 - REMEDIERE: Eroarea 9002 și eroarea 3052 atunci când încercați să adăugați sau să faceți backup fișierului jurnal în SQL Server 2012 sau SQL Server 2014

Se aplică la
SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Standard SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Simptome

Să presupunem că utilizați grupul de disponibilitate AlwaysOn într-o bază de date Microsoft SQL Server 2012 sau SQL Server 2014 și există o tranzacție mare deschisă, activă, care necesită spațiu suplimentar în jurnal. Atunci când fișierul jurnal nu poate crește din unul dintre motivele următoare, tranzacția nu reușește.

  • Lipsa spațiului suplimentar pentru fișiere
  • Fișierul jurnal este configurat să nu crească
  • Fișierul jurnal a atins dimensiunea maximă configurată

În plus, primiți următorul mesaj de eroare:

Notă

Eroare: 9002, Severitate: 17, Stare: 9.
Jurnalul de tranzacții pentru baza de date "<nume >bază de date" este plin datorită "LOG_BACKUP".

După ce rulați o copie backup de jurnal, primiți un alt mesaj de eroare 9002:

Notă

Eroare: 9002, Severitate: 17, Stare: 9.
Jurnalul de tranzacții pentru baza de date "<nume >bază de date" este plin datorită "ACTIVE_TRANSACTION".

După o altă copie de rezervă în jurnal, primiți un alt mesaj de eroare 9002 urmat de un mesaj de eroare 5901:

Notă

Eroare: 9002, Severitate: 17, Stare: 9.
Jurnalul de tranzacții pentru baza de date "<nume >bază de date" este plin datorită "AVAILABILITY_REPLICA".

      

Notă

Nu s-a putut scrie o înregistrare punct de verificare în numele >bazei de date< deoarece jurnalul nu mai are spațiu. Contactați administratorul bazei de date pentru a trunchia jurnalul sau a aloca mai mult spațiu fișierelor jurnal ale bazei 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 au reușit să genereze un punct de verificare. Acest lucru este cauzat de obicei de lipsa resurselor de sistem, cum ar fi discul sau memoria, sau, în unele cazuri, de deteriorarea bazei de date. Examinați intrările anterioare din jurnalul de erori pentru informații mai detaliate despre această eroare.

Atunci când sunt efectuate backupurile ulterioare ale punctului de verificare sau jurnalului în timpul readucerii tranzacției la varianta anterioară, este posibil să primiți următorul mesaj de eroare:

Notă

Msg 3052, Level 16, State 1, Line 4
BACKUP LOG nu a reușit să înregistreze actualizările pentru baza de date "<nume> bază de date". Vor fi necesare copii de rezervă ulterioare pentru a avansa punctul de backup de la "<LSN id 1>" la "<LSN id 2>" după ce spațiul de jurnal devine disponibil pentru înregistrarea în jurnal.

Când primiți aceste mesaje, nu mai puteți să remiteți tranzacții noi în baza de date și nu puteți să măriți fișierul jurnal sau să adăugați alt fișier jurnal.

Rezolvare

Problema a fost remediată mai întâi în următoarea actualizare cumulativă a SQL Server:

Recomandare: Instalați cea mai recentă actualizare cumulativă pentru SQL Server

Fiecare actualizare cumulativă nouă pentru SQL Server conține toate remedierile rapide și toate remedierile de securitate care au fost incluse cu 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

Puteți utiliza următoarea soluție pentru a trunchia jurnalele și a relua activitatea.

  1. Verificați fiecare reproducere secundară pentru a verifica dacă last_hardened_lsn de reproducere secundară (consultați sys.dm_hadr_database_replica_states) se potrivește cu replica principală last_hardened_lsn. Puteți face acest lucru rulând următoarea interogare care este conectată la instanța de reproducere 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>'

  2. În replica primară

    • Eliminați baza de date din grupul de disponibilitate.
    • Readăugați baza de date la grupul de disponibilitate.

  3. Pe fiecare reproducere secundară

    • Readăugați baza de date la grupul de disponibilitate.

Prin eliminarea bazei de date din grupul de disponibilitate, aceasta va trunchia imediat jurnalele și va elibera spațiu în jurnal.

Dacă last_hardened_lsn pentru fiecare reproducere secundară este identică cu replica principală și nu sunt efectuate copii backup în jurnal în timpul eliminării bazei de date din grupul de disponibilitate și readăugării bazei de date în fiecare reproducere secundară, replica secundară va fi adăugată din nou cu succes, fără erori sau fără a fi necesară restaurarea copiilor backup de jurnal pe cea secundară.

Dacă o reproducere secundară nu este la zi cu replica primară și trebuie să eliminați baza de date din grupul de disponibilitate pentru ca cea secundară să poată recupera din urmă, poate fi necesar ca acea reproducere secundară să aibă restaurate copiile backup ale jurnalului pentru a o recupera înainte de a o adăuga din nou la grupul de disponibilitate sau să elimine baza de date în replica secundară și să o reînscenați cu un backup complet al bazei de date în jurnalul de tranzacții.

Stare

Microsoft a confirmat că aceasta este o problemă în produsele Microsoft care sunt listate în secțiunea „Se aplică la”.