Fișierul .ldf a crescut la sute de GB: cum să reduci în siguranță jurnalul și să stabilizezi baza de date

Creșterea fișierului de tranzacții (.ldf) la zeci sau sute de gigaocteți înseamnă că SQL Server nu curăță jurnalul tranzacțiilor. Acest lucru creează un risc direct:

• de umplere completă a discului,

• de oprire a funcționării programului,

• de trecere a bazei de date în stările Recovery Pending sau Suspect.

În practica suportului tehnic au fost înregistrate cazuri când .ldf a crescut până la 190+ GB.

Când apare problema

Situația este caracteristică bazelor de date care:

• funcționează mult timp fără mentenanță planificată,

• au jurnale active ale acțiunilor și modificărilor documentelor,

• folosesc SQL Server Express fără control regulat al spațiului pe disc.

Cauza

Fișierul .ldf păstrează înregistrările tranzacțiilor până când SQL Server poate elibera (truncate) jurnalul. Dacă:

• jurnalul nu se curăță,

• nu există proceduri de service regulate,

• nu este suficient spațiu liber pe disc,
  logul poate crește fără limită, chiar dacă baza însăși (.mdf) aproape nu se schimbă.

Un caz separat este modelul de recuperare Full: în acest mod jurnalul nu se eliberează automat, iar pentru curățarea lui este necesară copierea de rezervă a jurnalului tranzacțiilor. Modelul Full permite recuperarea până la un moment exact, în timp ce Simple — doar recuperarea din copia de rezervă. Trecerea la Simple duce la eliberarea automată a jurnalului și la reducerea dimensiunii .ldf (în el rămân înregistrările necesare operațiunilor curente).

Soluția (algoritm sigur)

Pasul 1. Curățare internă a datelor

Înainte de micșorarea fizică a logului, este necesar să reduceți volumul de informații pe care SQL Server îl consideră actual.

Se recomandă:

• curățarea „Protocolului acțiunilor utilizatorilor” pentru perioadele vechi,

• curățarea „Jurnalului modificărilor documentelor”, păstrând doar datele actuale (de exemplu, 2–3 luni),

• executarea operațiunii de service
  „Ștergerea statisticilor perioadelor închise” (cod 006) — aceasta șterge fizic documentele vechi și reduce încărcarea asupra jurnalului tranzacțiilor.

Legătura cauză-efect:
cu cât sunt mai puține date istorice → cu atât sunt mai puține tranzacții active → cu atât mai eficient se micșorează .ldf.

Pasul 2. Micșorarea fișierului log (Shrink)

După curățarea internă se realizează micșorarea fizică a fișierului:

1. Conectați-vă la SQL Server prin SQL Server Management Studio (SSMS).

2. Selectați baza necesară (de obicei TorgSoftDB).

3. Click dreapta → Tasks → Shrink → Files.

4. Tip fișier: Log.

5. Porniți procedura de micșorare.

Rezultat:
SQL Server eliberează spațiul ocupat pe disc fără deteriorarea datelor.

Particularități pentru SQL Server Express

În ediția gratuită:

• .mdf are o limită strictă:

• 10 GB — SQL Server 2008 R2 și mai nou.

• 4 GB — SQL Server 2005.

• .ldf nu are o limită formală, însă:

• când discul se umple, SQL Server nu mai poate funcționa,

• orice operațiuni (inclusiv actualizarea Torgsoft) se pot încheia cu eroare.

Dacă baza este deja în stare Suspect

Dacă baza a trecut în Suspect sau Recovery Pending:

• Shrink-ul standard nu va funcționa,

• este necesar mai întâi să scoateți baza din starea de avarie cu comenzi SQL speciale,

• abia după aceea este posibilă micșorarea logului.

În acest caz, acțiunile pe cont propriu fără experiență sunt nedorite.

Recuperare de urgență la pierderea sau deteriorarea .ldf (risc de pierdere a datelor)

Se aplică doar atunci când:

• baza nu pornește,

• fișierul .ldf lipsește sau este deteriorat,

• recuperarea prin metode standard este imposibilă,

• există copii de rezervă actuale sau s-a acceptat posibilitatea pierderii unei părți din date.

Secvența acțiunilor:

1. Opriți serviciul SQL Server.

2. Ștergeți fișierul jurnalului tranzacțiilor (.ldf).

3. Porniți SQL Server.

4. În SQL Server Management Studio executați:

USE master

GO

sp_configure 'allow updates', 1

RECONFIGURE WITH OVERRIDE

GO

ALTER DATABASE <db_name> SET EMERGENCY, SINGLE_USER

DBCC CHECKDB ('<db_name>', REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE <db_name> SET ONLINE, MULTI_USER

USE master

GO

sp_configure 'allow updates', 0

GO

Note:

• Parametrul REPAIR_ALLOW_DATA_LOSS permite pierderea unei părți din date.

• Metoda nu este folosită pentru micșorarea planificată a .ldf.

• După recuperare, este necesar să verificați integritatea bazei și să efectuați o copie de rezervă completă.

Prevenție (recomandat)

Ca logul să nu crească din nou:

• executați regulat:
  „Reconstruirea și reorganizarea indexurilor și actualizarea statisticilor”,

• monitorizați spațiul liber pe discul de sistem,

• evitați lucrul „la limită” cu discul aproape plin,

• activați copierea de rezervă:
  „Securitatea datelor: arhivă în cloud” (cod 057).

• acordați atenție extinderii automate (Autogrowth). În setările bazei din SSMS este mai bine să stabiliți o limită pentru creșterea fișierului de log (de exemplu, până la 5–10 GB), ca acesta să nu poată „consuma” tot spațiul pe disc și să nu ducă la blocarea sistemului de operare.

Rezumat

Creșterea .ldf este un simptom, nu o eroare.
Secvența corectă:

1. curățarea jurnalelor interne,

2. ștergerea statisticilor învechite,

3. micșorarea fizică a logului,

4. prevenție regulată.

Această abordare permite stabilizarea sistemului fără risc de pierdere a datelor și fără repetarea problemei.