Súbor .ldf sa rozrástol na stovky GB: ako bezpečne zmenšiť protokol a stabilizovať databázu

Nárast transakčného súboru (.ldf) na desiatky alebo stovky gigabajtov znamená, že SQL Server nečistí (nekráti) transakčný log. To vytvára priame riziko:

• úplného zaplnenia disku,

• zastavenia práce programu,

• prepnutia databázy do stavov Recovery Pending alebo Suspect.

V praxi technickej podpory boli zaznamenané prípady, keď .ldf narástol na 190+ GB.

Kedy vzniká problém

Situácia je typická pre databázy, ktoré:

• dlhodobo fungujú bez pravidelnej údržby,

• majú aktívne záznamy akcií a zmien dokumentov,

• používajú SQL Server Express bez pravidelnej kontroly voľného miesta na disku.

Príčina

Súbor .ldf uchováva záznamy transakcií, kým SQL Server nedokáže uvoľniť (truncate) log. Ak:

• log sa nekráti,

• neexistujú pravidelné servisné postupy,

• na disku chýba voľné miesto,
  log môže rásť bez obmedzení, aj keď sa samotná databáza (.mdf) takmer nemení.

Samostatným prípadom je model obnovy Full: v tomto režime sa log neuvoľňuje automaticky a na jeho vyčistenie je potrebné zálohovať transakčný log. Model Full umožňuje obnovu do konkrétneho časového bodu, zatiaľ čo Simple — len obnovu zo zálohy. Prechod na Simple vedie k automatickému uvoľneniu logu a zmenšeniu veľkosti .ldf (ponechajú sa v ňom len záznamy potrebné pre aktuálne operácie).

Riešenie (bezpečný algoritmus)

Krok 1. Interné čistenie dát

Pred fyzickým zmenšením logu je potrebné znížiť objem informácií, ktoré SQL Server považuje za aktuálne.

Odporúča sa:

• vyčistiť „Protokol akcií používateľov“ za staršie obdobia,

• vyčistiť „Denník zmien dokumentov“, ponechať len aktuálne údaje (napríklad 2–3 mesiace),

• vykonať servisnú operáciu
  „Odstránenie štatistík uzavretých období“ (kód 006) — fyzicky odstráni staré dokumenty a zníži záťaž transakčného logu.

Príčinná súvislosť:
čím menej historických dát → tým menej aktívnych transakcií → tým efektívnejšie sa zmenší .ldf.

Krok 2. Zmenšenie log súboru (Shrink)

Po internom čistení sa vykoná fyzické zmenšenie súboru:

1. Pripojte sa k SQL Server cez SQL Server Management Studio (SSMS).

2. Vyberte požadovanú databázu (zvyčajne TorgSoftDB).

3. Pravým tlačidlom → Tasks → Shrink → Files.

4. Typ súboru: Log.

5. Spustite procedúru zmenšenia.

Výsledok:
SQL Server uvoľní obsadené miesto na disku bez poškodenia dát.

Špecifiká pre SQL Server Express

V bezplatnej edícii:

• .mdf má pevný limit:

• 10 GB — SQL Server 2008 R2 a novšie.

• 4 GB — SQL Server 2005.

• .ldf nemá formálny limit, ale:

• pri zaplnení disku SQL Server nedokáže pracovať,

• akékoľvek operácie (vrátane aktualizácie Torgsoft) môžu skončiť chybou.

Ak je databáza už v stave Suspect

Ak databáza prešla do stavu Suspect alebo Recovery Pending:

• štandardný Shrink nebude fungovať,

• najprv je potrebné dostať databázu z havarijného stavu pomocou špeciálnych SQL príkazov,

• až potom je možné zmenšiť log.

V takom prípade sú samostatné kroky bez skúseností nežiadúce.

Núdzová obnova pri strate alebo poškodení .ldf (riziko straty dát)

Používa sa iba vtedy, keď:

• databáza sa nespustí,

• súbor .ldf chýba alebo je poškodený,

• obnova štandardnými metódami nie je možná,

• existujú aktuálne zálohy alebo bolo prijaté rozhodnutie o možnej strate časti dát.

Postup krokov:

1. Zastavte službu SQL Server.

2. Odstráňte súbor transakčného logu (.ldf).

3. Spustite SQL Server.

4. V SQL Server Management Studio vykonajte:

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

Poznámky:

• Parameter REPAIR_ALLOW_DATA_LOSS môže spôsobiť stratu časti dát.

• Metóda sa nepoužíva na plánované zmenšovanie .ldf.

• Po obnove je potrebné skontrolovať integritu databázy a vykonať úplnú zálohu.

Prevencia (odporúčané)

Aby log znovu nerástol:

• pravidelne vykonávajte:
  „Obnoviť a reorganizovať indexy a aktualizovať štatistiky“,

• kontrolujte voľné miesto na systémovom disku,

• vyhnite sa práci „na doraz“ pri takmer plnom disku,

• zapnite zálohovanie:
  „Bezpečnosť dát: archív v cloude“ (kód 057).

• venujte pozornosť automatickému rastu (Autogrowth). V nastaveniach databázy v SSMS je lepšie nastaviť limit rastu log súboru (napríklad na 5–10 GB), aby fyzicky nemohol „zjesť“ celý diskový priestor a nespôsobil zlyhanie operačného systému.

Zhrnutie

Nárast .ldf je symptóm, nie chyba.
Správna postupnosť:

1. čistenie interných logov,

2. odstránenie zastaraných štatistík,

3. fyzické zmenšenie logu,

4. pravidelná prevencia.

Takýto prístup umožňuje stabilizovať systém bez rizika straty dát a bez opakovania problému.