Zarządzanie plikami dzienników transakcyjnych
Baza danych musi zawierać przynajmniej jeden plik dziennika o domyślnym rozszerzeniu .ldf (Log Data File), w którym zapisywane są wykonywane w taj bazie operacje. Pliki dziennika nie należą do jakiejkolwiek grupy plików, a podczas ich zapisywania nie są używane algorytm karuzelowy i zasada proporcjonalnego wypełniania. Serwer SQL traktuje wszystkie pliki dziennika bazy danych jak jeden plik i wypełnia je po kolei — z tego powodu bazy danych powinny zawierać tylko jeden plik dziennika.
Zadaniem dziennika transakcyjnego jest umożliwienia ponownego wykonania lub wycofania wykonanych na bazie operacji. W tym celu:
- Każda wykonana w bazie danych operacja jest rejestrowana w dzienniku za pomocą odpowiedniego wpisu (serwer SQL loguje wszystkie wykonane w bazach użytkowników operacje, ale niektóre z nich, np. instrukcje TRUNCATE TABLE, mogą być logowane w minimalnym stopniu). Pojedyncza transakcja generuje wiele wpisów do dziennika: pierwszy z nich dotyczy operacji alokacji strony, kolejne – wykonywanych w ramach tej transakcji operacji wstawiania, modyfikowania lub usuwania wierszy.
- Każdy wpis w dzienniku ma swój unikatowy, monotonicznie rosnący numer LSN (Log Sequence Number).
- Każdy wpis zawiera m.in. numery modyfikowanych stron, zmieniane wartości wierszy, informacje o transakcji, w której ramach wykonywana jest operacja, oraz czas jej rozpoczęcia i zakończenia.
- Koniec każdej transakcji (oraz ewentualnie utworzonych w jej ramach punktów kontrolnych) jest oznaczany albo przez znacznik akceptacji (jeżeli transakcja została zatwierdzona), albo znacznik kompensacji (jeśli została przerwana lub wycofana).
- Numer LSN ostatniego wpisu dotyczącego strony danych jest zapisywany w nagłówku tej strony.
- Przed zakończeniem transakcji dziennik jest zapisywany na dysku. Ponieważ kolejność wpisów dziennika ma znaczenie, przed zakończeniem transakcji zapisywane są również wpisy dotyczące wszystkich trwających w tym czasie, w tym jeszcze niezakończonych, transakcji). Protokół rejestrowania z wyprzedzeniem WAL (ang. Write Ahead Log) gwarantuje, że znajdujący się w dzienniku transakcyjnym opis transakcji zostanie utrwalony na dysku, zanim do pliku danych zostaną zapisane zmienione przez nią strony.
To plik dziennika, a nie pliki danych, zawiera wszystkie informacje potrzebne do odtworzenia bazy z określonego czasu. Bezpieczeństwo tego najważniejszego do zapobiegania utracie danych pliku powinno zostać zapewnione poprzez umieszczenie go na osobnym, znajdującym się na macierzy RAID 10, dysku.
Serwer SQL okresowo synchronizuje bufory z plikami danych. Odbywa się to albo w ramach wykonywania punktu kontrolnego (Checkpoint), albo – jeżeli serwerowi brakuje pamięci – w trakcie zwalniania buforów przez wewnętrzny proces opóźnionego zapisu (Lazy Writer). W obu przypadkach w plikach danych zapisywane są wszystkie „brudne” (zmodyfikowane od czasu poprzedniej synchronizacji) strony, niezależnie od stanów modyfikujących je transakcji. W trakcie synchronizacji w pliku dziennika zapisywana jest również lista wszystkich otwartych w tym czasie transakcji.
Synchronizacja dzieli dziennik transakcyjny na część nieaktywną (w której znajdują się operacje odzwierciedlone w plikach danych) i aktywną. Punkt podziału wyznacza najstarsza aktywna transakcja, tj. taka transakcja, która nie została jeszcze ani zatwierdzona, ani wycofana. Taka synchronizacja pozwala zmniejszyć liczbę transakcji, które serwer SQL będzie musiał ponownie wykonać podczas odzyskiwania bazy danych (ponownie wykonane zostaną jedynie transakcje zapisane w aktywnej części dziennika) i w rezultacie skrócić czas odtwarzania kopii zapasowych oraz uruchamiania serwera.
Budowa i działanie dziennika transakcyjnego
Dzienniki transakcyjne mogą osiągać bardzo duże rozmiary. Żeby przyspieszyć ich przeszukiwanie, serwer SQL dzieli je na wirtualne pliki dziennika, VLF (Virtual Log File).
Początkowa liczba wirtualnych plików dziennika zależy od wielkości pliku dziennika transakcyjnego:
- Pliki mniejsze niż 64 MB zawierają 4 wirtualne pliki dziennika.
- Pliki mniejsze niż 1 GB mieszczą w sobie 8 wirtualnych plików dziennika.
- Pliki większe niż 1 GB zawierają 16 wirtualnych plików dziennika.
Te same formuły stosowane są podczas powiększania pliku dziennika, czyli jeżeli zostanie powiększony o 100 MB dodanych do niego zostanie 8 nowych wirtualnych plików dziennika.
Zasada działania dziennika transakcyjnego jest następująca:
- Początkowo wszystkie wirtualne pliki dziennika są nieaktywne i nieużywane. W przeciwieństwie do plików danych pliki dziennika zawsze są zerowane podczas inicjalizacji, a więc ich tworzenie i powiększanie jest znacznie bardziej czasochłonne.
- Pierwsza wykonana w bazie danych operacja uaktywnia wirtualny plik dziennika, w którym zostaje odnotowana.
- Po uaktywnieniu wirtualny plik dziennika nie może zostać nadpisany. Wirtualny plik dziennika pozostaje aktywny tak długo, jak zapisane w nim operacje są potrzebne do:
a) odtworzenia ostatniej kopii zapasowej,
b) wycofania otwartych transakcji,
c) odtworzenia spójności bazy danych,
d) replikacji transakcyjnej,
e) podwojenia bazy danych. - Po wypełnieniu wirtualnego pliku dziennika następny VLF zostaje uaktywniony (rysunek 1).
Rysunek 1. Logiczna struktura dziennika transakcyjnego
Dziennik transakcyjny jest cykliczny – po zapełnieniu ostatniego wirtualnego pliku dziennika serwer SQL próbuje ponownie użyć pierwszego. Jeżeli to niemożliwe (np. pierwszy VLF jest nadal aktywny), plik dziennika zostaje powiększony. To właśnie cykliczność dziennika transakcyjnego jest powodem, dla którego jego plik musi zostać zainicjowany poprzez wyzerowanie – natychmiastowa inicjalizacja nie umożliwiłaby jednoznacznego odróżnienia zapełnionych, zawierających aktywne wpisy wirtualnych dzienników od dzienników pustych lub zapełnionych nieaktywnymi wpisami wirtualnych dzienników.
Ponieważ niekontrolowane powiększanie się dziennika i związane z nim powiększanie się liczby wirtualnych plików dziennika obniża wydajność serwera SQL oraz wydłuża czas tworzenia i odtwarzania kopii zapasowych, nie należy do tego dopuszczać.
Sposób dezaktywacji wirtualnych plików dziennika zależy od trybu odtwarzania bazy danych:
- W trybie SIMPLE są automatycznie dezaktywowane podczas wykonywania punktu kontrolnego. Oznacza to, że dziennik transakcyjny nie zawiera historii wszystkich operacji, a jedynie wpisy dotyczące operacji, których efekty nie zostały jeszcze utrwalone w plikach danych.
- W pozostałych trybach jedynym sposobem ich dezaktywacji jest wykonanie kopii zapasowej dziennika transakcyjnego. Serwer SQL nie deaktywuje wirtualnych plików dziennika transakcyjnego podczas wykonywania pełnej kopii zapasowej bazy danych.
Podczas dezaktywacji wirtualne pliki dziennika nie są zerowane, nie jest też zmniejszany plik dziennika. Serwer SQL ustawia jedynie bit parzystości informujący o tym, czy dany VLF może zostać ponownie użyty. Informacje o użyciu wirtualnych plików dziennika transakcyjnego zwraca nieudokumentowana, ale całkowicie bezpieczna instrukcja DBCC LOGINFO:
DBCC LOGINFO;
—
FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
2 458752 8192 85 0 128 0
2 458752 466944 87 2 128 916690000000008000000
2 458752 925696 79 0 64 0
2 712704 1384448 84 0 64 0
Pierwsza kolumna zawiera identyfikator pliku dziennika transakcyjnego, druga – rozmiar poszczególnych VLF, trzecia – pozycję ich początku, czwarta – ich numery, piąta – status (2 oznacza aktywny, 0 nieaktywny VLF), czwarta – wartość bitu parzystości, ostatnia – numer LSN pierwszej zapisanej w tym wirtualnym pliku transakcji.
