RESTORE LOG

RESTORE LOG przywraca kopię dziennika transakcji, kontynuując odtwarzanie od ostatniej kopii pełnej lub różnicowej.

RESTORE LOG w Microsoft SQL Server

RESTORE LOG to instrukcja języka Transact-SQL używana w Microsoft SQL Server do odtworzenia kopii zapasowej dziennika transakcji. Dziennik transakcji rejestruje zmiany wykonywane w bazie danych, między innymi operacje zapisu, modyfikacje struktury oraz informacje potrzebne silnikowi do odtworzenia spójnego stanu. Przywrócenie kopii dziennika nie jest niezależnym sposobem odtworzenia bazy. Wymaga wcześniejszego przywrócenia kopii pełnej, a jeżeli w używanym łańcuchu kopii występuje także kopia różnicowa, dziennik odtwarza się po niej.

Operacja RESTORE LOG wykorzystuje ciągłość zapisów dziennika określaną między innymi przez numery LSN, czyli Log Sequence Number. Kolejna kopia dziennika musi należeć do tego samego łańcucha i obejmować zakres następujący po ostatniej poprawnie przywróconej kopii. Nie można dowolnie pominąć kopii dziennika znajdującej się w środku sekwencji. Jeżeli zabraknie jednego elementu łańcucha, późniejsze kopie mogą nie dać się zastosować do przygotowywanej bazy.

Warunki wykonania łańcucha kopii dziennika

Możliwość wykonywania kopii dziennika transakcji zależy od modelu odzyskiwania bazy danych w SQL Server. Model SIMPLE nie obsługuje regularnych kopii dziennika, ponieważ silnik automatycznie zarządza obcinaniem jego niepotrzebnych fragmentów. Modele FULL oraz BULK_LOGGED pozwalają wykonywać kopie dziennika, ale po przełączeniu bazy na model FULL trzeba najpierw wykonać kopię pełną. Sama zmiana modelu odzyskiwania nie tworzy kompletnego łańcucha, który można od razu wykorzystać do odtwarzania.

Typowy proces rozpoczyna się od przywrócenia kopii pełnej za pomocą RESTORE DATABASE, opcjonalnie z użyciem kopii różnicowej. Następnie wykonuje się kolejne polecenia RESTORE LOG w dokładnej kolejności utworzenia kopii. Każda kopia powinna obejmować wymagany ciąg zmian od miejsca, w którym zakończyła się poprzednia. Przed rozpoczęciem pracy warto sprawdzić metadane kopii, na przykład za pomocą RESTORE HEADERONLY oraz RESTORE FILELISTONLY, a także zweryfikować zgodność zakresów LSN i nazw plików bazy.

NORECOVERY, RECOVERY i odtwarzanie do punktu w czasie

Podczas przywracania kolejnych kopii dziennika baza pozostaje zwykle w stanie odtwarzania dzięki opcji WITH NORECOVERY. W takim stanie SQL Server nie udostępnia jej użytkownikom, ale zachowuje możliwość zastosowania następnej kopii. Użycie WITH RECOVERY kończy sekwencję odtwarzania, wykonuje fazę odzyskiwania i otwiera bazę do normalnej pracy. Po zakończeniu tej fazy nie można już zastosować kolejnych kopii dziennika do tej samej sekwencji.

RESTORE LOG może również służyć do odtworzenia stanu z określonego momentu, z użyciem opcji STOPAT. SQL Server stosuje wtedy zapisane operacje tylko do wskazanej daty i godziny, a pominięte późniejsze zmiany nie są wprowadzane do odzyskiwanej bazy. Wymaga to jednak kompletnego i nieuszkodzonego łańcucha kopii aż do momentu obejmującego żądany punkt. Jeżeli po awarii istnieje jeszcze dostęp do aktywnego końca dziennika, przed odtwarzaniem wykonuje się tak zwaną kopię tail-log backup, aby zachować ostatnie zapisane transakcje.

Kontrola błędów podczas przywracania dziennika

Problemy z RESTORE LOG często wynikają z niezgodności kolejności kopii, braku wcześniejszej kopii pełnej albo zakończenia poprzedniego etapu opcją RECOVERY. Komunikat o tym, że kopia dziennika nie może zostać zastosowana, nie oznacza automatycznie uszkodzenia samego pliku. Przyczyną może być również wybranie kopii należącej do innej bazy, przerwanie łańcucha po zmianie modelu odzyskiwania, odtworzenie niewłaściwej kopii różnicowej lub pominięcie wymaganej kopii dziennika.

Przy analizie należy porównać daty utworzenia kopii, identyfikator bazy, zakresy LSN, opcje odzyskiwania oraz stan bazy po każdym etapie. Trzeba także sprawdzić, czy ścieżki wskazane w instrukcji RESTORE LOG odpowiadają rzeczywistym plikom backupu i czy SQL Server ma do nich dostęp. Po zakończeniu pełnego odtwarzania przydatne jest wykonanie kontroli spójności DBCC CHECKDB, ponieważ poprawne zastosowanie kopii dziennika potwierdza ciągłość operacji, ale nie zastępuje niezależnej weryfikacji logicznej struktury bazy.