Udostępnij za pośrednictwem

Dziennik transakcji

  • Artykuł

Dotyczy:programu SQL Server

Każda baza danych programu SQL Server ma dziennik transakcji, który rejestruje wszystkie transakcje i modyfikacje bazy danych wprowadzone przez każdą transakcję.

Dziennik transakcji jest krytycznym składnikiem bazy danych. Jeśli wystąpi awaria systemu, potrzebny jest ten dziennik, aby przywrócić bazę danych do stanu spójnego.

Ostrzeżenie

Nigdy nie usuwaj ani nie przenosij tego dziennika, chyba że w pełni zrozumiesz konsekwencje takiego działania.

Aby uzyskać informacje na temat architektury i wewnętrznych mechanizmów dziennika transakcji, zobacz przewodnik po architekturze i zarządzaniu dziennikiem transakcji programu SQL Server.

Napiwek

Znane dobre punkty, z których należy rozpocząć stosowanie dzienników transakcji podczas odzyskiwania bazy danych, są tworzone przez punkty kontrolne. Aby uzyskać więcej informacji, zobacz Database checkpoints (SQL Server).

Operacje obsługiwane przez dziennik transakcji

Dziennik transakcji obsługuje następujące operacje:

  • Odzyskiwanie poszczególnych transakcji.
  • Odzyskiwanie wszystkich niekompletnych transakcji po uruchomieniu programu SQL Server.
  • Przywracanie przywróconej bazy danych, pliku, grupy plików lub strony do momentu awarii.
  • Obsługa replikacji transakcyjnej.
  • Obsługa rozwiązań wysokiej dostępności i odzyskiwania po awarii: Always On Availability Groups, dublowanie baz danych i wysyłka dzienników.

Odzyskiwanie poszczególnych transakcji

Jeśli aplikacja wystawia instrukcję ROLLBACK lub jeśli aparat bazy danych wykryje błąd, taki jak utrata komunikacji z klientem, rekordy dziennika są używane do wycofywania modyfikacji wprowadzonych przez niekompletną transakcję.

Odzyskiwanie wszystkich niekompletnych transakcji po uruchomieniu programu SQL Server

Jeśli serwer ulegnie awarii, bazy danych mogą pozostać w stanie, w którym niektóre modyfikacje nigdy nie zostały zapisane z pamięci podręcznej buforu do plików danych i mogą wystąpić pewne modyfikacje z niekompletnych transakcji w plikach danych. Po uruchomieniu wystąpienia programu SQL Server jest uruchamiane odzyskiwanie każdej bazy danych. Każda modyfikacja zarejestrowana w dzienniku, która mogła nie zostać zapisana w plikach danych, zostanie przesunięta do przodu. Każda niekompletna transakcja znaleziona w dzienniku transakcji zostanie wycofana, aby upewnić się, że integralność bazy danych jest zachowana. Aby uzyskać więcej informacji, zobacz Restore and Recovery Overview (SQL Server).

Przenoszenie przywróconej bazy danych, pliku, grupy plików lub strony do punktu awarii

Po utracie sprzętu lub awarii dysku wpływającej na pliki bazy danych można przywrócić bazę danych do punktu awarii. Najpierw należy przywrócić ostatnią pełną kopię zapasową bazy danych i ostatnią różnicową kopię zapasową bazy danych, a następnie przywrócić kolejną sekwencję kopii zapasowych dziennika transakcji do punktu awarii.

Podczas przywracania każdej kopii zapasowej dziennika silnik bazy danych ponownie stosuje wszystkie modyfikacje zarejestrowane w dzienniku, aby przesunąć do przodu wszystkie transakcje. Po przywróceniu ostatniej kopii zapasowej dziennika aparat bazy danych używa informacji dziennika, aby wycofać wszystkie transakcje, które nie zostały ukończone w tym momencie. Aby uzyskać więcej informacji, zobacz Restore and Recovery Overview (SQL Server).

Obsługa replikacji transakcyjnej

Agent czytnika dzienników monitoruje dziennik transakcji każdej bazy danych skonfigurowanej do replikacji transakcyjnej i kopiuje transakcje oznaczone do replikacji z dziennika transakcji do bazy danych dystrybucji. Aby uzyskać więcej informacji, zobacz Jak działa replikacja transakcyjna.

Obsługa rozwiązań wysokiej dostępności i odzyskiwania po awarii

Rozwiązania rezerwowego serwera, grupy dostępności Always On, dublowanie baz danych i wysyłka dzienników w dużym stopniu opierają się na dzienniku transakcji.

W scenariuszu zawsze włączonych grup dostępności każda aktualizacja bazy danych w replice podstawowej jest natychmiast odtwarzana w osobnych kopiach bazy danych we wszystkich replikach pomocniczych. Replika podstawowa wysyła każdy rekord dziennika natychmiast do replik pomocniczych, które stosują przychodzące rekordy dziennika do baz danych dostępności, nieprzerwanie przesuwając dziennik do przodu. Aby uzyskać więcej informacji, zobacz zawsze włączone wystąpienia klastra trybu failover (SQL Server).

W scenariuszu wysyłania dziennika serwer podstawowy wysyła kopie zapasowe dziennika transakcji podstawowej bazy danych do co najmniej jednego miejsca docelowego. Każdy serwer pomocniczy przywraca kopie zapasowe dziennika do lokalnej pomocniczej bazy danych. Aby uzyskać więcej informacji, zobacz Informacje o wysyłaniu dzienników (SQL Server).

W scenariuszu dublowania bazy danych , każda aktualizacja bazy danych, główna baza danych, jest natychmiast odtwarzana w oddzielnej, pełnej kopii bazy danych, dublowanej bazy danych. Wystąpienie serwera głównego wysyła każdy rekord dziennika natychmiast do wystąpienia serwera lustrzanego, które stosuje przychodzące rekordy dziennika do bazy danych lustrzanych, ciągle je aktualizując. Aby uzyskać więcej informacji, zobacz Database Mirroring (SQL Server).

Właściwości dziennika transakcji

Charakterystyka dziennika transakcji silnika bazy danych SQL Server:

  • Dziennik transakcji jest implementowany jako oddzielny plik lub zestaw plików w bazie danych. Pamięć podręczna dzienników jest zarządzana oddzielnie od pamięci podręcznej buforu dla stron danych, co skutkuje prostym, szybkim i niezawodnym kodem w silniku baz danych programu SQL Server. Aby uzyskać więcej informacji, zobacz Transaction Log Physical Architecture.

  • Format rekordów dziennika i stron nie jest ograniczony do przestrzegania formatu stron danych.

  • Dziennik transakcji można zaimplementować w kilku plikach. Pliki można zdefiniować w celu automatycznego rozwijania, ustawiając wartość dziennika na FILEGROWTH. Zmniejsza to potencjał braku miejsca w dzienniku transakcji, jednocześnie zmniejszając nakład pracy administracyjnej. Aby uzyskać więcej informacji, zobacz ALTER DATABASE (Transact-SQL) Opcje plików i grup plików.

  • Mechanizm ponownego wykorzystania miejsca w plikach dziennika jest szybki i ma minimalny wpływ na przepływność transakcji.

Aby uzyskać informacje na temat architektury i mechanizmów wewnętrznych dziennika transakcji, zobacz przewodnik po architekturze i zarządzaniu dziennikiem transakcji programu SQL Server .

Obcinanie dziennika transakcji

Trunkowanie dziennika zwalnia miejsce w pliku dziennika na potrzeby ponownego użycia przez dziennik transakcji. Należy regularnie skracać dziennik transakcji, żeby uniemożliwić jego całkowite zapełnienie. Kilka czynników może opóźnić obcinanie dziennika, więc monitorowanie rozmiaru dziennika ma znaczenie. Niektóre operacje mogą być rejestrowane minimalnie, aby zmniejszyć ich wpływ na rozmiar dziennika transakcji.

Obcięcie dziennika usuwa nieaktywne pliki dziennika wirtualnego (VLFs) z dziennika logicznego bazy danych programu SQL Server, zwalniając miejsce w dzienniku logicznym do ponownego użycia przez dziennik transakcji fizycznych. Jeśli dziennik transakcji nigdy nie zostanie obcięty, ostatecznie wypełni wszystkie miejsce na dysku przydzielone do fizycznych plików dziennika.

Aby uniknąć wyczerpania przestrzeni, chyba że skrócenie dziennika jest opóźnione z jakiejś przyczyny, skrócenie odbywa się automatycznie po następujących zdarzeniach:

  • W ramach prostego modelu odzyskiwania po punkcie kontrolnym.

  • W ramach modelu pełnego odzyskiwania lub modelu odzyskiwania rejestrowanego zbiorczo, jeśli punkt kontrolny wystąpił od czasu utworzenia poprzedniej kopii zapasowej, obcięcie odbywa się po utworzeniu kopii zapasowej dziennika (chyba że jest to kopia zapasowa dziennika tylko do kopiowania).

  • Podczas tworzenia bazy danych przy użyciu modelu pełnego odzyskiwania dziennik transakcji jest ponownie używany w razie potrzeby (podobnie jak w przypadku bazy danych przy użyciu prostego modelu odzyskiwania), aż do momentu utworzenia pełnej kopii zapasowej bazy danych.

Aby uzyskać więcej informacji, zobacz Czynniki, które mogą opóźnić obcinanie dziennikaw dalszej części tego artykułu.

Obcinanie dziennika nie zmniejsza rozmiaru pliku dziennika fizycznego. Aby zmniejszyć rozmiar fizyczny pliku dziennika fizycznego, należy zmniejszyć plik dziennika. Aby uzyskać informacje o zmniejszaniu rozmiaru pliku dziennika fizycznego, zobacz Zarządzanie rozmiarem pliku dziennika transakcji. Należy jednak pamiętać, Czynniki, które mogą opóźnić obcinanie dziennika. Jeśli przestrzeń dyskowa jest wymagana ponownie po zmniejszeniu dziennika, dziennik transakcji ponownie wzrośnie, co będzie powodować obciążenie wydajnościowe podczas procesu zwiększania rozmiaru dziennika.

Czynniki, które mogą opóźniać obcinanie dziennika

Gdy rekordy dziennika pozostają aktywne przez długi czas, obcinanie dziennika transakcji jest opóźnione, a dziennik transakcji może się wypełnić, jak wspomniano wcześniej w tym artykule.

Ważny

Aby uzyskać informacje o sposobie reagowania na pełny dziennik transakcji, zobacz Rozwiązywanie problemów z pełnym dziennikiem transakcji (błąd programu SQL Server 9002).

Obcinanie dziennika może być opóźnione z różnych powodów. Aby dowiedzieć się, co uniemożliwia obcięcie dziennika, wykonaj zapytanie o kolumny log_reuse_wait i log_reuse_wait_descsys.databases widoku wykazu. W poniższej tabeli opisano wartości tych kolumn.

log_reuse_wait wartość log_reuse_wait_desc wartość Opis
0 NOTHING Obecnie istnieje co najmniej jeden plik dziennika wirtualnego wielokrotnego użytku.
1 CHECKPOINT Żaden punkt kontrolny nie wystąpił od czasu ostatniego obcinania dziennika lub nagłówek dziennika nie został jeszcze przeniesiony poza wirtualnego pliku dziennika (VLF) (wszystkie modele odzyskiwania).

Jest to rutynowy powód opóźnienia skracania dziennika. Aby uzyskać więcej informacji, zobacz Database checkpoints (SQL Server).
2 LOG_BACKUP Kopia zapasowa dziennika transakcji jest wymagana przed jego skróceniem. (Tylko pełne lub zbiorkowo-rejestrowane modele odzyskiwania)

Po zakończeniu tworzenia następnej kopii zapasowej dziennika niektóre miejsca w dzienniku mogą stać się wielokrotnego użytku.
3 ACTIVE_BACKUP_OR_RESTORE Trwa tworzenie kopii zapasowej danych lub przywracanie (wszystkie modele odzyskiwania).

Jeśli kopia zapasowa danych zapobiega obcięciu dziennika, anulowanie operacji tworzenia kopii zapasowej może pomóc rozwiązać ten bezpośredni problem.
4 ACTIVE_TRANSACTION Transakcja jest aktywna (wszystkie modele odzyskiwania):

Długotrwała transakcja może istnieć na początku tworzenia kopii zapasowej dziennika. W takim przypadku zwolnienie miejsca może wymagać innej kopii zapasowej dziennika. Długotrwałe transakcje uniemożliwiają obcięcie dziennika we wszystkich modelach odzyskiwania, w tym prosty model odzyskiwania, w ramach którego dziennik transakcji jest zwykle obcięty na każdym automatycznym punkcie kontrolnym.

Transakcja jest odroczona. Transakcja odroczona to efektywnie aktywna transakcja, której wycofanie jest blokowane z powodu niedostępności niektórych zasobów. Aby uzyskać informacje o przyczynach odroczonych transakcji i sposobie ich przenoszenia ze stanu odroczonego, zobacz Odroczone transakcje (SQL Server).

Długotrwałe transakcje mogą również wypełnić dziennik transakcji tempdb. tempdb jest używana niejawnie przez transakcje użytkownika dla obiektów wewnętrznych, takich jak tabele robocze do sortowania, pliki robocze do tworzenia skrótów, tabele robocze kursora i przechowywanie wersji wierszy. Nawet jeśli transakcja użytkownika obejmuje tylko odczytywanie danych (SELECT zapytań), obiekty wewnętrzne mogą być tworzone i używane w ramach transakcji użytkownika. Następnie można wypełnić dziennik transakcji tempdb.
5 DATABASE_MIRRORING Dublowanie bazy danych jest wstrzymane lub w trybie wysokiej wydajności dublowana baza danych znacznie znajduje się za główną bazą danych. (Tylko model pełnego odzyskiwania).

Aby uzyskać więcej informacji, zobacz Database Mirroring (SQL Server).
6 REPLICATION Podczas replikacji transakcyjnej transakcje istotne dla publikacji są wciąż nieprzekazane do bazy danych dystrybucyjnej. (Tylko model pełnego odzyskiwania)

Aby uzyskać informacje na temat replikacji transakcyjnej, zobacz Replikacja programu SQL Server.
7 DATABASE_SNAPSHOT_CREATION Tworzona jest migawka bazy danych (wszystkie modele odzyskiwania).

Jest to rutynowa i zazwyczaj krótka przyczyna opóźnień w przycinaniu dziennika.
8 LOG_SCAN Trwa skanowanie dziennika (wszystkie modele odzyskiwania).

Jest to rutynowa i zazwyczaj krótka przyczyna opóźnionego obcinania dziennika.
9 AVAILABILITY_REPLICA Replika pomocnicza grupy dostępności stosuje rekordy dziennika transakcji tej bazy danych do odpowiedniej pomocniczej bazy danych. (Tylko pełny model odzyskiwania).

Aby uzyskać więcej informacji, zobacz Co to jest zawsze włączona grupa dostępności?.
10 - Tylko do użytku wewnętrznego
11 - Tylko do użytku wewnętrznego
12 - Tylko do użytku wewnętrznego
13 OLDEST_PAGE Jeśli baza danych jest skonfigurowana do używania punktów kontrolnych pośrednich, najstarsza strona w bazie danych może być starsza niż punkt kontrolny numer sekwencji dziennika (LSN). W takim przypadku najstarsza strona może opóźnić obcinanie dziennika (wszystkie modele odzyskiwania).

Aby uzyskać informacje o pośrednich punktach kontrolnych, zobacz Database checkpoints (SQL Server).
14 OTHER_TRANSIENT Ta wartość nie jest obecnie używana.
16 XTP_CHECKPOINT Należy wykonać punkt kontrolny OLTP In-Memory. W przypadku tabel zoptymalizowanych pod kątem pamięci automatyczny punkt kontrolny jest wykonywany, gdy plik dziennika transakcji staje się większy niż 1,5 GB od ostatniego punktu kontrolnego (obejmuje zarówno tabele oparte na dyskach, jak i zoptymalizowane pod kątem pamięci).

Aby uzyskać więcej informacji, zobacz Operation for Memory-Optimized Tables and Logging and Checkpoint process for In-Memory Optimized Tables (Operacja punktu kontrolnego dla tabel

Operacje, które mogą być rejestrowane minimalnie

Minimalne rejestrowanie obejmuje rejestrowanie tylko informacji niezbędnych do odzyskania transakcji, bez zapewnienia obsługi odzyskiwania do konkretnego punktu w czasie. W tym artykule opisano operacje, które są minimalnie rejestrowane w ramach modelu odzyskiwania rejestrowanego zbiorczo (a także w ramach prostego modelu odzyskiwania, z wyjątkiem sytuacji, gdy kopia zapasowa jest uruchomiona).

Minimalne rejestrowanie nie jest obsługiwane w przypadku tabel zoptymalizowanych pod kątem pamięci.

W ramach pełnego modelu odzyskiwania wszystkie operacje zbiorcze są w pełni rejestrowane. Można jednak zminimalizować rejestrowanie dla zestawu operacji zbiorczych, przełączając bazę danych na model odzyskiwania z rejestrowaniem zbiorczym na potrzeby operacji zbiorczych. Minimalne rejestrowanie jest bardziej wydajne niż pełne rejestrowanie i zmniejsza możliwość dużej operacji zbiorczej wypełniającej dostępną przestrzeń dziennika transakcji podczas transakcji zbiorczej. Jeśli jednak baza danych jest uszkodzona lub utracona, gdy minimalne logowanie jest włączone, nie można odzyskać bazy danych do punktu awarii.

Następujące operacje, które są w pełni rejestrowane w ramach pełnego modelu odzyskiwania, są minimalnie rejestrowane w ramach prostego i rejestrowanego zbiorczo modelu odzyskiwania:

  • Operacje importowania zbiorczego (bcp, BULK INSERTi INSERT). Aby uzyskać więcej informacji o tym, kiedy importowanie zbiorcze do tabeli jest minimalnie rejestrowane, zobacz Wymagania wstępne dotyczące minimalnego rejestrowania w importowaniu zbiorczym.

    Po włączeniu replikacji transakcyjnej operacje BULK INSERT są w pełni rejestrowane nawet przy użyciu modelu odzyskiwania z rejestrowaniem zbiorczym.

  • SELECT — operacje klauzuli INTO.

    Po włączeniu replikacji transakcyjnej, operacje SELECT INTO są w pełni rejestrowane, nawet w przypadku modelu odzyskiwania z rejestrowaniem zbiorczym.

  • Częściowe aktualizacje typów danych o dużej wartości przy użyciu klauzuli .WRITE w instrukcji UPDATE podczas wstawiania lub dołączania nowych danych. Minimalne logowanie nie jest stosowane przy aktualizacji istniejących wartości. Aby uzyskać więcej informacji na temat typów danych o dużej wartości, zobacz Typy danych.

  • instrukcje WRITETEXT i UPDATETEXT podczas wstawiania lub dołączania nowych danych do kolumn typu data text, ntexti image. Minimalne logowanie nie jest stosowane przy aktualizowaniu istniejących wartości.

    Ostrzeżenie

    Instrukcje WRITETEXT i UPDATETEXT są przestarzałe; unikaj używania ich w nowych aplikacjach.

  • Jeśli baza danych jest ustawiona na model odzyskiwania prosty lub rejestrowania zbiorczego, niektóre operacje DDL indeksu są minimalnie rejestrowane, bez względu na to, czy operacja jest wykonywana w trybie offline, czy w trybie online. Minimalnie zarejestrowane operacje indeksu są następujące:

    • operacje tworzenia indeksu (w tym widoki indeksowane).

    • operacja ALTER INDEX REBUILD lub DBCC DBREINDEX.

      Operacje kompilacji indeksu używają minimalnego rejestrowania, ale mogą być opóźnione w przypadku współbieżnego wykonywania kopii zapasowej. To opóźnienie jest spowodowane wymaganiami synchronizacji stron puli buforów z minimalnym logowaniem podczas korzystania z prostego lub modelu odzyskiwania z rejestrowaniem zbiorczym.

      Ostrzeżenie

      Instrukcja DBCC DBREINDEX jest przestarzała; unikaj używania go w nowych aplikacjach.

    • DROP INDEX ponowne kompilowanie stert (jeśli ma to zastosowanie). Cofnięcie przydziału strony indeksu podczas operacji DROP INDEX jest zawsze w pełni rejestrowane.

Zadanie Artykuł
Zarządzanie dziennikiem transakcji - Zarządzanie rozmiarem pliku dziennika transakcji

- Rozwiązywanie problemów z pełnym dziennikiem transakcji (błąd programu SQL Server 9002)
Tworzenie kopii zapasowej dziennika transakcji (tylko model pełnego odzyskiwania) - tworzenie kopii zapasowej dziennika transakcji

- utworzyć kopię zapasową dziennika transakcji, gdy baza danych jest uszkodzona (SQL Server)
Przywracanie dziennika transakcji (tylko model pełnego odzyskiwania) - przywracanie kopii zapasowej dziennika transakcji (SQL Server)

Powiązana zawartość