recovery model

Recovery model to ustawienie bazy określające sposób prowadzenia dziennika transakcji i możliwości jej odtwarzania.

Recovery model w SQL Server i rola dziennika transakcji

Recovery model, czyli model odzyskiwania, jest właściwością bazy danych w Microsoft SQL Server. Określa sposób rejestrowania zmian w dzienniku transakcji oraz zakres operacji odtwarzania dostępnych po awarii. Nie jest to ustawienie samego serwera ani systemu Windows, lecz konkretnej bazy danych. W jednej instancji SQL Server różne bazy mogą korzystać z różnych modeli odzyskiwania.

SQL Server używa dziennika transakcji do zapisywania informacji potrzebnych między innymi do wycofywania niezatwierdzonych operacji i ponownego wykonania zmian po restarcie usługi. Model odzyskiwania wpływa na to, czy można wykonywać kopie zapasowe dziennika transakcji, jak szczegółowo można odtworzyć stan bazy oraz kiedy niewykorzystane fragmenty dziennika mogą zostać oznaczone jako możliwe do ponownego użycia. Sam model nie zastępuje kopii zapasowej bazy ani poprawnie zaplanowanej procedury odtwarzania.

Simple, Full i Bulk-logged — trzy modele odzyskiwania

SQL Server udostępnia trzy modele odzyskiwania: Simple, Full oraz Bulk-logged. W modelu Simple dziennik jest automatycznie skracany po wykonaniu punktu kontrolnego, gdy zapisane informacje nie są już potrzebne do odzyskania bazy. Nie można w nim wykonywać kopii zapasowych dziennika transakcji, dlatego odtwarzanie jest możliwe do czasu wykonania pełnej lub różnicowej kopii zapasowej, a nie do wybranego momentu pomiędzy takimi kopiami.

Model Full zachowuje pełny łańcuch kopii dziennika transakcji, pod warunkiem że po utworzeniu pełnej kopii zapasowej rozpoczęto wykonywanie kopii dziennika i nie przerwano tego łańcucha. Pozwala to odtwarzać bazę do określonego punktu w czasie, na przykład bezpośrednio przed niepożądaną zmianą. Model Bulk-logged również obsługuje kopie dziennika, ale wybrane operacje masowe mogą być rejestrowane w sposób minimalny. W takim przypadku odtworzenie do dowolnego punktu znajdującego się wewnątrz kopii dziennika zawierającej taką operację może nie być możliwe; przywracanie wymaga zastosowania całej odpowiedniej kopii dziennika.

Kopie dziennika, skracanie logu i odtwarzanie punktu w czasie

W modelu Full regularna kopia zapasowa dziennika transakcji jest niezbędna, ponieważ bez niej aktywne fragmenty logu mogą nadal zajmować miejsce w pliku dziennika. Częstotliwość wykonywania takich kopii powinna wynikać z dopuszczalnej utraty danych oraz wymaganej długości okna odtwarzania. Pełna kopia bazy nie zeruje automatycznie łańcucha kopii dziennika i nie zastępuje cyklicznych kopii logu. Kopia różnicowa także nie zastępuje kopii dziennika w modelu Full.

Odtwarzanie punktu w czasie wymaga odpowiedniej pełnej kopii bazy, opcjonalnie najnowszej kopii różnicowej oraz wszystkich kolejnych kopii dziennika obejmujących żądany moment. Przywracanie wykonuje się w stanie umożliwiającym zastosowanie następnych kopii, zwykle z użyciem opcji pozostawienia bazy niedostępnej po poszczególnych etapach. Dopiero ostatni etap, zakończony operacją recovery, udostępnia bazę użytkownikom. Jeżeli brakuje jednego elementu łańcucha albo kopia dziennika jest uszkodzona, odtworzenie do późniejszego punktu może zakończyć się niepowodzeniem.

Dobór modelu do sposobu pracy bazy

Model Simple jest przeznaczony dla baz, dla których wystarcza odtwarzanie z pełnych i różnicowych kopii zapasowych oraz akceptowana jest utrata zmian powstałych od ostatniej dostępnej kopii. Nie należy wybierać go wyłącznie dlatego, że plik dziennika rośnie. Rozrost logu może wynikać z długiej transakcji, oczekiwania na replikację, blokady, opóźnionych operacji wejścia-wyjścia albo innego powodu widocznego w stanie bazy. Zmiana modelu bez ustalenia przyczyny może jedynie ukryć problem i utrudnić późniejsze odtwarzanie.

Full jest właściwy wtedy, gdy wymagane jest odtwarzanie punktu w czasie i kontrola nad maksymalną utratą zmian. Bulk-logged bywa używany czasowo podczas określonych operacji masowych, gdy ważne jest ograniczenie rozmiaru dziennika, ale jego zastosowanie wymaga sprawdzenia wpływu na plan odtwarzania. Po zmianie modelu z Simple na Full należy wykonać pełną kopię zapasową, aby rozpocząć nowy łańcuch logu. Przed przyjęciem konfiguracji warto wykonać próbne odtworzenie na oddzielnym środowisku i potwierdzić, że kopie są czytelne, uporządkowane oraz obejmują wymagany zakres czasu.