Katalog logów

Katalog logów to lokalizacja przechowywania plików dziennika transakcji bazy danych.

Gdzie silnik bazy zapisuje historię zmian

Dziennik transakcji to plik z rozszerzeniem .ldf towarzyszący plikowi danych .mdf, w którym SQL Server zapisuje każdą modyfikację jeszcze zanim trafi ona na strony danych. To zasada zapisu z wyprzedzeniem: transakcja jest uznana za zatwierdzoną dopiero wtedy, gdy jej rekord dziennika został fizycznie utrwalony. Dzięki temu po nagłym zaniku zasilania silnik przy starcie odtwarza zatwierdzone operacje i wycofuje niedokończone. Katalog, w którym te pliki leżą, ustala się przy tworzeniu bazy klauzulą LOG ON, a domyślną lokalizację dla nowych baz zmienia się we właściwościach instancji, w zakładce ustawień bazy danych. Bieżącą ścieżkę każdego pliku pokazuje widok sys.database_files albo sys.master_files dla całej instancji.

Osobny dysk to nie fanaberia

Zapis do dziennika jest sekwencyjny i synchroniczny, a zapis do plików danych losowy i odłożony w czasie. To dwa zupełnie różne wzorce, więc trzymanie ich na tym samym nośniku sprawia, że głowica lub kolejka kontrolera skacze między nimi i cierpią oba. Rozdzielenie na osobne woluminy było klasyczną poradą z czasów dysków talerzowych i nadal ma sens przy macierzach, gdzie zapis dziennika opłaca się umieścić na wolumenie o najniższym opóźnieniu. Osobna sprawa to model odzyskiwania. W modelu prostym silnik sam obcina nieużywaną część dziennika po każdym punkcie kontrolnym. W modelu pełnym dziennik rośnie do momentu wykonania kopii zapasowej dziennika i dopiero ona zwalnia miejsce do ponownego użycia — to jedyny model pozwalający odtworzyć bazę do wybranej minuty sprzed awarii.

Klasyczne kłopoty z rozrastającym się plikiem

Numer jeden: baza w modelu pełnym, dla której nikt nigdy nie wykonał kopii dziennika. Plik .ldf rośnie tygodniami, aż zapełni dysk, a wtedy baza przechodzi w stan tylko do odczytu i aplikacja zgłasza błąd 9002 o zapełnionym dzienniku. Numer dwa: skasowanie pliku dziennika przy zatrzymanej usłudze w nadziei, że sam się odtworzy — baza wraca wtedy w stanie podejrzanym i ratunek bywa częściowy. Numer trzy: cykliczne kurczenie pliku instrukcją zmniejszania, po którym dziennik i tak rośnie z powrotem, za to fragmentuje się wewnętrznie na tysiące wirtualnych plików dziennika i wydłuża czas startu bazy. Numer cztery: jedna gigantyczna transakcja, na przykład usuwanie milionów wierszy jednym poleceniem, która zajmuje cały dziennik naraz — rozbicie jej na porcje po kilkadziesiąt tysięcy wierszy rozwiązuje problem bez żadnych zmian w konfiguracji. Kolumna log_reuse_wait_desc w widoku sys.databases mówi wprost, co blokuje zwolnienie miejsca: brak kopii, otwarta transakcja albo zatrzymana replikacja.

Opieka nad bazami firmowymi

Przy programach handlowych opartych o SQL Server ustawiamy właściwy model odzyskiwania do faktycznych potrzeb firmy, planujemy harmonogram kopii pełnych i kopii dziennika, rozdzielamy pliki na nośniki i pilnujemy, żeby kopie faktycznie dawały się odtworzyć — nieprzetestowana kopia to tylko nadzieja. Przy okazji sprawdzamy autogrow, bo domyślny przyrost procentowy przy dużym pliku potrafi zatrzymać pracę na kilkadziesiąt sekund w środku dnia. Prace robimy zdalnie albo na miejscu u klienta, o porze, która nie zatrzymuje sprzedaży — zgłoszenia przyjmujemy przez całą dobę, również w niedzielę.