Rejestrowanie i odzyskiwanie w SQL Server

Autor: Paul S. Randal

Opublikowano: 21 sierpnia 2009

Zawartość strony

	Czym jest rejestrowanie?
	Czym jest odzyskiwanie?
	Dziennik transakcji
	Modele odzyskiwania
	Podsumowanie

Jednymi z najczęściej źle rozumianych części SQL Server są mechanizmy rejestrowania i odzyskiwania. Fakt, że dziennik transakcji istnieje i może być przyczyną problemów, jeśli nie jest właściwie zarządzany, wydaje się wprawiać w zakłopotanie wielu „mimowolnych administratorów DBA". Jak to jest możliwe, że dziennik transakcji rozrasta się bez granic? Dlaczego czasami tak dużo potrzeba czasu, aby baza danych przeszła do trybu online po awarii systemu? Dlaczego nie można całkowicie wyłączyć rejestrowania? Dlaczego nie mogę właściwie odzyskać mojej bazy danych? Czym jest dziennik transakcji i po co w ogóle jest?

Są to pytania, które powtarzają się na forach i w grupach dyskusyjnych SQL Server, więc w tym artykule chcę podać przegląd systemu rejestrowania i odzyskiwania i wyjaśnić, dlaczego jest to integralna część mechanizmu bazy danych SQL Server. Objaśnię architekturę dziennika transakcji oraz to, jak trzy modele dostępne dla bazy danych mogą zmienić zachowanie dziennika transakcji oraz samego procesu rejestrowania. Jednocześnie podam kilka łączy do zasobów, dotyczących najlepszych praktyk zarządzania dziennikiem transakcji.

Czym jest rejestrowanie?

Rejestrowanie i odzyskiwanie nie są pojęciami używanymi wyłącznie w SQL Server – wszystkie komercyjne systemy zarządzania relacyjnymi bazami danych (RDBMS) muszą je zawierać do obsługi różnych właściwości ACID transakcji. ACID oznacza Atomicity (niepodzielność), Consistency (spójność), Isolation (izolacja) i Durability (trwałość), które są podstawowymi właściwościami systemu przetwarzania transakcji (takiego jak RDBMS). Więcej na ten temat w części CID Properties w MSDN Library.

Operacje w RDBMS są rejestrowane (czyli zapisywane) na poziomie fizycznym lub logicznym w zakresie tego, co dzieje się w strukturach pamięci bazy danych. Każda zmiana w strukturze pamięci ma swój własny zapis w dzienniku, który opisuje zmienioną strukturę oraz rodzaj zmiany. Jest to robione w taki sposób, aby zmiana mogła być w razie potrzeby powtórzona bądź cofnięta. Zapisy dziennika są przechowywane w specjalnym pliku o nazwie dziennik transakcji – opiszę to później bardziej szczegółowo, lecz chwilowo można go traktować jako plik o dostępie sekwencyjnym.

Zbiór jednej lub więcej takich zmian może być (a w rzeczywistości zawsze jest) zgrupowany w transakcję – co zapewnia podstawową jednostkę dokonywania zmian (niepodzielność) w bazie danych, jeśli chodzi o użytkowników, projektantów aplikacji oraz administratorów baz danych. Transakcja albo kończy się powodzeniem (zatwierdzenie), albo się nie udaje i jest anulowana (cofnięcie). W pierwszym przypadku mamy gwarancję, że operacje tworzące transakcję będą na pewno miały swoje odzwierciedlenie w bazie danych. W drugim przypadku mamy gwarancję, że tak nie będzie.

Transakcje w SQL Server są jawne lub pośrednie. Transakcja jawna to taka transakcja, w której użytkownik lub aplikacja wydaje polecenie T-SQL, BEGIN TRANSACTION, sygnalizując rozpoczęcie przez tę sesję grupy powiązanych zmian. Transakcja jawna zostaje zatwierdzona, gdy zostanie wydane polecenie COMMIT TRANSACTION, sygnalizujące udane wykonanie grupy zmian. Jeśli zamiast tego zostanie wydana instrukcja ROLLBACK TRANSACTION, wszystkie dokonane przez tę sesję zmiany od momentu wydania instrukcji BEGIN TRANSACTION będę anulowane (cofnięte), a transakcja zostanie odrzucona. Cofnięcie transakcji może być także narzucone przez zdarzenie zewnętrzne, takie jak wyczerpanie miejsca na dysku dla bazy danych lub awaria serwera, co wyjaśnię później.

Transakcja pośrednia to taka transakcja, w której użytkownik lub aplikacja nie wydaje bezpośrednio instrukcji BEGIN TRANSACTION przed wydaniem instrukcji T-SQL. Jednak biorąc pod uwagę, że wszystkie zmiany w bazie danych muszą być transakcyjne, mechanizm bazy danych będzie automatycznie rozpoczynać transakcję pod przykryciem. Kiedy instrukcja T-SQL zostanie wykonana, Storage Engine automatycznie zatwierdza transakcję, którą rozpoczęła, aby umieścić ją w instrukcji użytkownika.

Można pomyśleć, że nie jest to konieczne, ponieważ pojedyncza instrukcja T-SQL nie generuje dużej liczby zmian w strukturze przechowywania bazy danych, lecz warto rozważyć instrukcję, jak ALTER INDEX REBUILD. Chociaż ta instrukcja nie może być zawarta w jawnej transakcji, może generować ogromną liczbę zmian w bazie danych. Musi więc istnieć mechanizm zapewnienia, aby gdy coś się nie powiedzie (na przykład instrukcja zostanie anulowana), wszystkie zmiany będą poprawnie wycofane.

Jako przykład rozważmy, co się stanie, gdy pojedynczy wiersz tabeli będzie zaktualizowany w transakcji jawnej. Wyobraźmy sobie prostą tabelę sterty z kolumną c1 typu integer oraz kolumną c2 typu char. Tabela ma 10 000 wierszy, a użytkownik składa następujące zapytanie aktualizujące:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

Będą wykonane następujące operacje:

• Strony danych z SimpleTable są wczytywane z dysku do pamięci (pula bufora), więc mogą być przeszukiwane pod kątem pasujących wierszy. Okazuje się, że trzy strony danych zawierają pięć wierszy, które pasują do predykatu klauzuli WHERE.
• Mechanizm bazy danych automatycznie uruchamia jawną transakcję.
• Trzy strony danych i pięć wierszy danych zostaje zablokowanych, aby pozwolić na wystąpienie aktualizacji.
• Zmiany są dokonywane w pamięci, w pięciu rekordach danych na trzech stronach danych.
• Zmiany są także zapisywane w rekordach dziennika, w dzienniku transakcji na dysku.
• Mechanizm bazy danych automatycznie zatwierdza transakcję pośrednią.

Zwróćmy uwagę, że nie został wymieniony krok, w którym trzy zaktualizowane strony danych są zapisywane z powrotem na dysku. Powód jest taki, że nie muszą być zapisane; dopóki zapisy dziennika opisujące zmiany znajdują się na dysku w dzienniku transakcji, zmiany są chronione. Jeśli strony muszą być kolejno odczytane lub ponownie zmieniane, wtedy najbardziej aktualna kopia strony jest już w pamięci, a nie na dysku (jeszcze). Strony danych będą wypisane na dysk, gdy pojawi się następna operacja punktu kontrolnego lub gdy pamięć używana przez nie w puli bufora jest wymagana przez obraz innej strony.

Punkty kontrolne istnieją z dwóch powodów – aby wykonać plik wsadowy zapisu we/wy w celu polepszenia wydajności oraz skrócenia czasu wymaganego do odzyskania po awarii. W kategoriach wydajności, jeśli strona danych byłaby wypychana na dysk za każdym razem, gdy zostanie zaktualizowana, liczba operacji we/wy zapisu pojawiająca się w aktywnym systemie może z łatwością przytłoczyć podsystem we/wy. Lepiej okresowo wypisać brudne strony (strony, które zostały zmienione od chwili ich przeczytania z dysku), niż wypisywać strony natychmiast po ich zmianie. Aspekt odzyskiwania punktów kontrolnych omówię za chwilę.

Jednym z typowych nieporozumień na temat punktów kontrolnych jest przekonanie, że wypisują one tylko strony ze zmianami z zatwierdzonych transakcji. To jest nieprawdą – punkt kontrolny zawsze wypisuje wszystkie brudne strony, niezależnie od tego, czy transakcja, która zmieniła stronę, została zatwierdzona, czy nie.

Rejestrowanie z zapisem z wyprzedzeniem jest mechanizmem, w którym rekordy dziennika opisujące zmianę są zapisywane na dysku przed zapisaniem samych zmian. Zapewnia to czynnik trwałości spośród właściwości ACID. Dopóki rekordy dziennika opisujące zmiany są na dysku, w razie awarii, rekordy dziennika (a więc i same zmiany) mogą być powtórzone, a efekty transakcji nie będą utracone.

 Do początku strony

Czym jest odzyskiwanie?

Rejestrowanie istnieje w celu obsługi różnych operacji w SQL Server. Gwarantuje, że, jeśli nastąpi awaria, zatwierdzona transakcja będzie prawidłowo odzwierciedlona w bazie danych po awarii. Daje także pewność, że niezatwierdzona transakcja będzie właściwie wycofana i nie będzie miała swojego odbicia w bazie danych po awarii. Dzięki temu możliwe jest anulowanie transakcji „w locie” i wycofanie wszystkich jej operacji. Umożliwia to pobranie kopii zapasowej dziennika transakcji, aby baza danych mogła być przywrócona, a kopia zapasowa dziennika transakcji powtórzona, aby przenieść bazę do określonej punktu czasu z zachowaniem spójności transakcyjnej. Obsługuje także funkcje, które opierają się na czytaniu dziennika transakcji, takie jak replikacja, tworzenie kopii lustrzanej bazy danych oraz przechwytywanie zmian danych.

W większości z tych zastosowań rejestrowania obejmują mechanizm zwany odzyskiwaniem. Odzyskiwanie jest procesem powtarzania lub odwracania w bazie danych zmian opisanych w rekordach dziennika. Powtarzanie rekordów dziennika nosi nazwę fazy odzyskiwania REDO (roll forward – przewiń w przód). Anulowanie zapisów dziennika jest nazywane fazą UNDO odzyskiwania (roll back – cofanie). Innymi słowy, odzyskiwanie daje pewność, że transakcja i wszystkie jej składowe zapisy dziennika są albo powtarzane, albo anulowane.

Prostą postacią odzyskiwania jest sytuacja, gdy pojedyncza transakcja jest anulowana, czyli jest cofana i nie ma efektu w bazie danych. Najbardziej złożoną formą jest odzyskiwanie po awarii – gdy SQL Server ulega awarii (z jakiegokolwiek powodu), a dziennik transakcji musi zostać odzyskany, aby przenieść bazę danych do punktu transakcyjnie spójnego. To oznacza, że wszystkie transakcje, które były zatwierdzone w momencie awarii, muszą być przewinięte do przodu, aby ich efekty zostały utrzymane w bazie danych. A wszystkie transakcje w trakcie, które nie były zatwierdzone w momencie awarii, muszą być cofnięte, aby ich efekty nie były utrzymane w bazie danych.

Wynika to stąd, że w SQL Server nie ma możliwości, aby transakcja była kontynuowana po awarii. W ten sposób, jeśli efekty częściowo wykonanej transakcji nie zostałyby cofnięte, baza danych byłaby pozostawiona w stanie niespójnym (możliwe, że nawet uszkodzona strukturalnie, zależnie od tego, w trakcie jakiego działania była transakcja).

Więc skąd proces odzyskiwania wie, co robić? Wszelkie działania opierają się fakcie, że każdy rekord dziennika jest oznaczony za pomocą numeru kolejnego w dzienniku (log sequence number, LSN). Numer kolejny dziennika jest zawsze rosnącym, trzyczęściowym numerem, który jednoznacznie definiuje pozycję zapisu dziennika w dzienniku transakcji. Każdy zapis dziennika transakcji jest przechowywany w porządku sekwencyjnym w dzienniku transakcji i zawiera identyfikator (ID) transakcji oraz LSN poprzedniego zapisu dziennika dla danej transakcji. Innymi słowy, każda operacja zarejestrowana jako część transakcji ma „łącze” powrotne do operacji, która ją bezpośrednio poprzedzała.

Dla prostego przypadku pojedynczej transakcji, która jest wycofywana, mechanizm odtwarzania może łatwo i szybko podążać wstecz wzdłuż łańcucha zarejestrowanych operacji, od operacji najnowszej aż do pierwszej, i anulować ich efekty w odwrotnej kolejności niż ta, w jakiej się pojawiały. Strony bazy danych, które były objęte transakcją, są albo nadal w puli bufora, albo na dysku. W obu przypadkach mamy gwarancję, że na dostępnym obrazie strony efekt transakcji ma swoje odzwierciedlenie na stronie i musi być anulowany.

Mechanizm odzyskiwania po awarii jest bardziej skomplikowany. Fakt, że strony bazy danych nie są zapisywane na dysku, gdy transakcja jest zatwierdzana, oznacza, że nie ma gwarancji, że zestaw stron bazy danych na dysku dokładnie odzwierciedla zestaw zmian opisanych w dzienniku transakcji –zarówno dla transakcji zatwierdzonych, jak i niezatwierdzonych. Jednak ostatnim kawałkiem tej układanki, o którym jeszcze nie wspomniałem, jest fakt, że wszystkie strony bazy danych mają pole w swoim nagłówku strony (część 96-bajtowa strony 8192-bajtowej zawierająca metadane o stronie), które zawiera LSN ostatniego zapisu dziennika, który miał wpływ na stronę. Dzięki temu system odzyskiwania może zdecydować, co ma zrobić z określonym zapisem dziennika, który musi być odzyskany:

• Dla zapisu dziennika z zatwierdzonej transakcji, gdzie strona bazy danych ma LSN równe lub większe od LSN zapisu dziennika, nic nie musi być zrobione. Efekt zapisu dziennika już jest utrzymywany na stronie na dysku.
• Dla zapisu dziennika z zatwierdzonej transakcji, gdzie strona bazy danych ma LSN mniejsze od LSN zapisu dziennika, zapis dziennika musi być ponownie wykonany, aby zapewnić utrzymanie efektów transakcji.
• Dla zapisu dziennika z niezatwierdzonej transakcji, gdzie strona bazy danych ma LSN równe lub większe od LSN zapisu dziennika, zapis dziennika musi być anulowany, aby mieć pewność, że efekty transakcji nie będą utrzymane.
• Dla zapisu dziennika z niezatwierdzonej transakcji, gdzie strona bazy danych ma LSN mniejsze od LSN zapisu dziennika, nic nie musi być zrobione. Efekt zapisu dziennika nie został utrzymany na stronie na dysku i jako taki nie musi być anulowany.

Podczas odzyskiwania po awarii odczytywany jest dziennik transakcji zapewniając, że wszystkie efekty zatwierdzonych transakcji są utrzymywane w bazie danych, zaś efekty wszystkich transakcji niezatwierdzonych nie są w nim utrzymywane – są to odpowiednio fazy REDO i UNDO. Gdy odtwarzanie po awarii zostanie zakończone, baza danych jest transakcyjnie spójna i dostępna do użytku.

Jak wspomniałem wcześniej, jednym z zastosowań operacji punktu kontrolnego jest skrócenie czasu trwania odzyskiwania po awarii. Poprzez okresowe wysyłanie wszystkich brudnych stron na dysk zmniejsza się liczba stron, które zostały zmienione na skutek zatwierdzonych transakcji, lecz ich obrazu nie ma na dysku. To, z kolei, zmniejsza liczbę stron, które muszą mieć zastosowane odzyskiwanie REDO podczas odzyskiwania po awarii.

 Do początku strony

Dziennik transakcji

Odzyskiwanie po awarii jest możliwe tylko wtedy, gdy dziennik transakcji jest nienaruszony. W zasadzie dziennik transakcji jest najważniejszą częścią bazy danych – to jedyne miejsce, w którym, w przypadku awarii, wszystkie zmiany w bazie danych są na pewno opisane.

Jeśli dziennik transakcji zostanie utracony lub zniszczony po awarii, wtedy odzyskanie po awarii nie może się zakończyć, czego efektem jest wątpliwa baza danych. W tym przypadku baza danych musi być przywracana z kopii zapasowych lub odzyskiwana przy użyciu mniej pożądanych opcji, takich jak naprawa w trybie awaryjnym (te procedury wykraczają poza zakres tego artykułu, lecz będą szczegółowo opisane w późniejszych artykułach w tym roku).

Dziennik transakcji jest specjalnym plikiem, który musi mieć każda baza danych, aby prawidłowo funkcjonować. Przechowuje on zapisy dziennika, które są tworzone przy rejestrowaniu i są odczytywane ponownie podczas odzyskiwania (lub dowolnego innego zastosowania rejestracji, o których wspomniałem wcześniej). Tak jak obszar zajmowany przez same zapisy dziennika, transakcja także rezerwuje obszar w dzienniku transakcji dla potencjalnych zapisów dziennika wymaganych, w przypadku gdyby transakcja miała być anulowana, i potrzebnych do wycofania. To wyjaśnia zachowanie, które można zaobserwować, gdy, powiedzmy, transakcja, która aktualizuje 50 MB danych w bazie danych, może faktycznie wymagać 100 MB miejsca na dziennik transakcji.

Po utworzeniu nowej bazy danych dziennik transakcji jest w zasadzie pusty. Gdy pojawiają się transakcje, rekordy dziennika są kolejno zapisywane w dzienniku transakcji, co oznacza, że nie ma zysku w wydajności, jeśli utworzymy wiele plików dziennika transakcji – to rozpowszechnione błędne mniemanie. Dziennik transakcji będzie używał kolejno każdego pliku dziennika.

Zapisy dziennika dla jednoczesnych transakcji mogą być rozrzucone w dzienniku transakcji. Pamiętajmy, że zapisy dziennika dla pojedynczej transakcji są połączone swoimi numerami LSN, więc nie ma potrzeby grupowania w dzienniku wszystkich zapisów dziennika dla transakcji. Numery LSN można traktować prawie jak znaczniki czasu.

Fizyczna architektura dziennika transakcji jest pokazana na rysunku 1. Jest on podzielony wewnętrznie na mniejsze kawałki zwane wirtualnymi plikami dziennika (virtual log files, VLF). Ułatwiają one wewnętrzne zarządzanie dziennikiem transakcji. Kiedy VLF stanie się pełny, rejestrowanie automatycznie przejdzie do użycia następnego VLF w dzienniku transakcji. Można sądzić, że w końcu dziennik transakcji wyczerpie miejsce, lecz w tym aspekcie dziennik transakcji bardzo różni się od plików danych.

Rysunek 1: Architektura fizyczna dziennika transakcji (Virtual log – dziennik wirtualny, unused – nieużywane, start of logic log – początek dziennika logicznego, last checkpoint – ostatni punkt kontrolny, end of logic log – koniec dziennika logicznego).

Dziennik transakcji jest w rzeczywistości plikiem cyklicznym – jeśli zapisy dziennika na początku dziennika transakcji są obcinane (czyli czyszczone). Wtedy, gdy rejestrowanie osiąga koniec dziennika transakcji, wraca znów do początku i zaczyna zastępowanie tego, co było tam wcześniej.

Jak więc zapisy dziennika są obcinane, aby zajmowany przez nie obszar mógł być ponownie użyty? Zapis dziennika nie jest już potrzebny w dzienniku transakcji, jeśli spełnione są następujące warunki:

• Transakcja, której część stanowi, jest zatwierdzona.
• Wszystkie strony bazy danych, które zmienił, zostały zapisane na dysku przez punkt kontrolny.
• Zapis dziennika nie jest potrzebny do kopii zapasowej (pełnej, różnicowej lub kopii dziennika).
• Zapis dziennika nie jest potrzebny żadnej funkcji, która odczytuje dziennik (takiej jak dublowanie lub replikacja bazy danych).

Zapis dziennika, który jest nadal potrzebny, nazywamy aktywnym, a VLF z przynajmniej jednym aktywnym zapisem dziennika także nazywamy aktywnym. Co jakiś czas dziennik transakcji jest sprawdzany, aby zobaczyć, czy wszystkie zapisy dziennika w pełnym VLF są aktywne, czy też nie; jeśli wszystkie są nieaktywne, VLF jest zaznaczany jako obcięty (w znaczeniu, że VLF może być nadpisany w przypadku zapętlenia dziennika transakcji). Kiedy VLF jest obcinany, nie jest zastępowany ani zerowany w żaden sposób – jest tylko zaznaczany jako obcięty i może być ponownie użyty.

Ten proces jest nazywany obcięciem dziennika – nie należy go mylić z rzeczywistym zmniejszeniem rozmiaru dziennika transakcji. Obcięcie dziennika nigdy nie zmienia fizycznego rozmiaru dziennika transakcji – tylko, które części dziennika są aktywne, a które nie. Na rysunku 2 pokazano dziennik transakcji z rysunku 1 po wystąpieniu obcięcia.

Rysunek 2: Dziennik transakcji po obcięciu.

Aktywne pliki VLF tworzą dziennik logiczny – część dziennika transakcji, która zawiera same aktywne zapisy dziennika. Sama baza danych „wie”, gdzie odzyskiwanie po awarii powinno się zaczynać, odczytując w aktywnej części dziennika zapis dziennika z początkiem najstarszej aktywnej transakcji w dzienniku, MinLSN (przechowywany na rozruchowej stronie bazy danych).

Proces odzyskiwania po awarii nie wie, gdzie zakończyć czytanie zapisów dziennika, więc działanie jest kontynuowane, aż osiągnie wyzerowaną część dziennika transakcji (jeśli dziennik transakcji nie rozpoczął kolejnego cyklu) lub zapis dziennika, którego bity parzystości nie pasują do sekwencji poprzedniego zapisu dziennika.

Gdy pliki VLF są obcinane, a nowe stają się aktywne, dziennik logiczny przesuwa się w pliku dziennika transakcji, aż w końcu powinien zawinąć się w kółko i zacząć od początku, jak pokazano na rysunku3.

Rysunek 3: Cykliczna natura dziennika transakcji.

Kontrola możliwości obcięcia dziennika może mieć miejsce w jednej z następujących okoliczności:

• Kiedy punkt kontrolny pojawia się w modelu odzyskiwania SIMPLE lub w id=" modelach odzyskiwania, gdy pełna kopia zapasowa nie była nigdy wykonana. (To sugeruje, że baza danych pozostaje w modelu odzyskiwania pseudo-SIMPLE po przełączeniu z modelu SIMPLE, dopóki nie zostanie wykonana pełna kopia zapasowa bazy danych).
• Kiedy zostaje wykonana kopia zapasowa dziennika.

Trzeba pamiętać, że obcięcie dziennika może nie być możliwe, ponieważ ze względu na wiele czynników zapis dziennika musi pozostawać aktywny. Kiedy nie może nastąpić obcięcie dziennika, pliki VLF nie mogą być obcinane i w końcu dziennik transakcji musi urosnąć (lub będzie dodany inny plik transakcji). Nadmierny wzrost dziennika transakcji może być przyczyną problemów z wydajnością przez zjawisko zwane fragmentacją pliku VLF. Usunięcie fragmentacji pliku VLF może czasami prowadzić do radykalnego poprawienia wydajności działań związanych z dziennikiem.

Więcej informacji na ten temat można znaleźć na blogu Kimberly Tripp, w poście „8 Steps to Better Transaction Log Throughput". Kimberly omawia najlepsze praktyki dotyczące planowania obciążenia dziennika transakcji, zarządzania nim i poprawy wydajności – to wszystko warto przeczytać!

Są dwa typowe problemy, które mogą uniemożliwić obcięcie dziennika:

• Długotrwała aktywna transakcja. Cały dziennik transakcji od pierwszego zapisu dziennika z najstarszą aktywną transakcją może nigdy nie być obcięty, dopóki transakcja nie będzie zatwierdzona lub odrzucona.
• Przełączanie do modelu odzyskiwania FULL, wykonanie pełnej kopii zapasowej, a potem nie zrobienie nigdy żadnych kopii zapasowych dziennika. Cała transakcja pozostanie aktywna, czekając na archiwizację przez kopię zapasową dziennika.

Pełną listę czynników i instrukcji na temat tego, jak określać, co staje na przeszkodzie obcięcia dziennika, można znaleźć w SQL Server Books Online, pod tytułem „Factors that Can Delay Log Truncation". Utworzyłem także pokaz wideo, który przedstawia efekt niekontrolowanego wzrostu dziennika transakcji i to, jak usuwać fragmentację VLF – to wideo można zobaczyć (oraz wcześniejsze zrzuty ekranowe na temat SQL) pod adresem technetmagazine.com/videos.

Jeśli dziennik transakcji osiągnie swój maksymalny rozmiar i nie może już się powiększać, wtedy zostanie zgłoszony błąd 9002 i trzeba będzie podjąć kroki w celu zapewnienia większego obszaru poprzez zwiększenie pliku dziennika, dodanie innego pliku dziennika lub usunięcie wszelkich utrudnień na drodze do obcięcia dziennika.

W żadnym wypadku nie należy usuwać dziennika transakcji, podejmować prób przebudowywania go za pomocą nieudokumentowanych poleceń lub po prostu obcinać go za pomocą opcji NO_LOG lub TRUNCATE_ONLY polecenia BACKUP LOG (które zostało usunięte w SQL Server 2008). Te opcje będą powodować niespójność transakcyjną (a jeszcze pewniej uszkodzenie) lub pozbawienie możliwości właściwego odzyskania bazy danych.

Więcej informacji o tym, jak rozwiązać problem zapełnionego dziennika transakcji, można znaleźć w Books Online, pod tematem „Troubleshooting a Full Transaction Log (Error 9002)".

 Do początku strony

Modele odzyskiwania

Jak widać, działanie dziennika transakcji zależy częściowo od stosowanego modelu odzyskiwania. Są trzy dostępne modele odzyskiwania, a wszystkie mają wpływ na zachowanie dziennika transakcji lub na to, jak są rejestrowane operacje, lub na jedno i drugie.

Model odzyskiwania FULL oznacza, że każda część każdej operacji jest rejestrowana, co jest określane jako pełne rejestrowanie. Kiedy pełna kopia zapasowa bazy danych zostanie zrobiona w modelu odzyskiwania FULL, dziennik transakcji nie będzie automatycznie obcinany, dopóki nie zostanie zrobiona kopia zapasowa dziennika. Jeśli nie chcemy robić użytku z kopii zapasowych dziennika i możliwości odzyskiwania bazy danych do określonego punktu w czasie, nie stosujemy modelu odzyskiwania FULL. Jednak, jeśli życzymy sobie zastosować dublowanie bazy danych, wtedy nie mamy wyboru, ponieważ obsługuje go tylko model odzyskiwania FULL.

Model odzyskiwania BULK_LOGGED ma taką samą semantykę dziennika transakcji, jak model odzyskiwania FULL, lecz umożliwia częściową rejestrację niektórych operacji, które są określane jako operacja z minimalną rejestracją. Przykładami są przebudowa indeksu i niektóre masowe operacje ładowania – w modelu odzyskiwania FULL cała operacja jest rejestrowana.

Lecz w modelu odzyskiwania BULK_LOGGED rejestrowane są tylko zmiany alokacji, co radykalnie zmniejsza liczbę wykonanych zapisów dziennika, co z kolei zmniejsza możliwość wzrostu dziennika transakcji. Więcej informacji na temat operacji z minimalną rejestracją, patrz Books Online, część „Operations that Can Be Minimally Logged."

Wreszcie model odzyskiwania SIMPLE ma w rzeczywistości takie samo działanie rejestrujące jak odzyskiwanie BULK_LOGGED, lecz semantyka obcinania dziennika transakcji jest całkiem inna. Kopie zapasowe dziennika nie są możliwe do wykonania w modelu odzyskiwania SIMPLE, co oznacza, że dziennik może być obcięty (o ile nic innego nie trzyma zapisów dziennika w trybie aktywności), gdy pojawia się punkt kontrolny. Każdy model odzyskiwania ma swoje za i przeciw w kategoriach tego, jakie kopie zapasowe są możliwe (lub potrzebne) oraz możliwości odzyskiwania do różnych punktów w czasie (to będzie opisane w innym artykule w dalszej części tego roku).

 Do początku strony

Podsumowanie

Ten artykuł jest w zasadzie bardziej akademickim wyjaśnieniem, jak działa decydująca część SQL Server. Mam nadzieję, że poradziłem sobie z wyjaśnieniem błędnych wyobrażeń, jakie mogą mieć czytelnicy. Jeśli jest to dla kogoś pierwsze wprowadzenie do rejestrowania i odzyskiwania, oto najważniejsze zasady, które powinien wynieść z tego artykułu:

• Nie tworzymy wielu plików dzienników, ponieważ nie prowadzi to do przyrostu wydajności.
• Trzeba mieć świadomość, jaki model odzyskiwania jest stosowany w bazie danych i jaki ma to wpływ na dziennik transakcji – a w szczególności, czy można automatycznie go obcinać, gdy pojawia się punkt kontrolny.
• Trzeba mieć świadomość potencjalnego wzrostu dziennika transakcji, czynników, które do tego prowadzą, oraz jak odzyskać nad tym kontrolę.
• Trzeba wiedzieć, gdzie szukać pomocy przy rozwiązywaniu problemów wypełnionego dziennika transakcji.

Na moim blogu mam dużo więcej informacji o dzienniku transakcji i czynnikach, które na niego wpływają – można je znaleźć w kategorii postów „Transaction Log". Różne tematy Books Online dotyczące dziennika transakcji są także bardzo dobre – począwszy od Transaction Log Management.

Jak zwykle, opinie i pytania można kierować pod adres Paul@SQLskills.com.

Dziękuję Kimberly L. Tripp za redakcję techniczną tego artykułu.

Szukasz wskazówek na temat SQL Server?

• Więcej wskazówek na temat SQL Server można znaleźć na stronie Wskazówki dotyczące SQL Server.
• Więcej wskazówek o id=" produktach znajduje się na stronie TechNet Magazine Tips index.

O autorze

Paul S. Randal jest dyrektorem zarządzającym w SQLskills.com, ma tytuł MVP w obszarze SQL Server oraz jest dyrektorem regionalnym w firmie Microsoft. W latach 1999-2007 pracował w zespole SQL Server Storage Engine w firmie Microsoft. Paul pisał DBCC CHECKDB/repair dla SQL Server 2005 i był odpowiedzialny za Core Storage Engine w czasie projektowania SQL Server 2008. Jest ekspertem od przywracania do awarii, wysokiej dostępności oraz utrzymania bazy danych, a także jest regularnym prezenterem na konferencjach na całym świecie. Pisze blog na witrynie SQLskills.com/blogs/paul.

Do początku strony