The Transaction Log (SQL Server) (Polski)

• 10/23/2019
• 11 minutes to read
• • M
  • D
  • f
  • M
  • s
  • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

dziennik transakcji jest kluczowym składnikiem bazy danych. Jeśli wystąpi awaria systemu, będziesz potrzebował tego dziennika, aby przywrócić bazę danych do spójnego stanu.

aby uzyskać informacje na temat architektury dziennika transakcji i wewnętrznych informacji, zobacz Przewodnik Architektury i zarządzania dziennikami transakcji SQL Server.

operacje obsługiwane przez dziennik transakcji

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

• odzyskiwanie pojedynczych transakcji.
• odzyskiwanie wszystkich niekompletnych transakcji po uruchomieniu SQL Server.
• przewijanie przywróconej bazy danych, Pliku, grupy plików lub strony do punktu awarii.
• Obsługa replikacji transakcyjnej.
• Obsługa rozwiązań wysokiej dostępności i odzyskiwania po awarii: zawsze w grupach dostępności, dublowaniu baz danych i wysyłaniu dziennika.,

odzyskiwanie poszczególnych transakcji

Jeśli aplikacja wyda polecenie ROLLBACK lub jeśli silnik bazy danych wykryje błąd, taki jak utrata komunikacji z klientem, rekordy dziennika są używane do cofnięcia modyfikacji dokonanych przez niekompletną transakcję.,

odzyskiwanie wszystkich niekompletnych transakcji po uruchomieniu SQL Server

Jeśli serwer zawiedzie, bazy danych mogą pozostać w stanie, w którym niektóre modyfikacje nigdy nie zostały zapisane z bufora cache do plików danych, i mogą być pewne modyfikacje z niekompletnych transakcji w plikach danych. Po uruchomieniu instancji SQL Server uruchamia odzyskiwanie każdej bazy danych. Każda zmiana zapisana w dzienniku, która mogła nie być zapisana w plikach danych, jest przewijana do przodu., Każda niekompletna transakcja znaleziona w dzienniku transakcji jest następnie wycofywana, aby upewnić się, że integralność bazy danych jest zachowana. Aby uzyskać więcej informacji, zobacz Przegląd przywracania i odzyskiwania (SQL Server).

przewijanie 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 przywracasz ostatnią pełną kopię zapasową bazy danych i ostatnią kopię zapasową bazy różnicowej, a następnie przywracasz kolejną sekwencję kopii zapasowych dziennika transakcji do punktu awarii.

podczas przywracania każdej kopii zapasowej dziennika, silnik bazy danych ponownie dopasowuje wszystkie zmiany zapisane w dzienniku, aby przewijać wszystkie transakcje. Po przywróceniu ostatniej kopii zapasowej dziennika, silnik bazy danych wykorzystuje informacje dziennika do cofnięcia wszystkich transakcji, które nie zostały zakończone w tym momencie. Aby uzyskać więcej informacji, zobacz Przegląd przywracania i odzyskiwania (SQL Server).,

Obsługa replikacji transakcyjnej

Agent Log Reader 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 wysokiej dostępności i rozwiązań do odzyskiwania po awarii

rozwiązania serwerowe w trybie gotowości, zawsze w grupach dostępności, dublowaniu baz danych i wysyłaniu dzienników, w dużej mierze opierają się na dzienniku transakcji.,

w scenariuszu Always On availability groups, każda aktualizacja do bazy danych, repliki podstawowej, jest natychmiast odtwarzana w oddzielnych, pełnych kopiach bazy danych, replikach wtórnych. Replika główna wysyła każdy rekord dziennika natychmiast do repliki wtórnej, która stosuje przychodzące rekordy dziennika do baz danych grupy dostępności, nieustannie przesuwając go do przodu. Aby uzyskać więcej informacji, zobacz instancje klastra przełączania awaryjnego zawsze

w scenariuszu wysyłki dziennika serwer główny wysyła aktywny dziennik transakcji podstawowej bazy danych do jednego lub więcej miejsc docelowych., Każdy serwer wtórny przywraca dziennik do lokalnej bazy danych wtórnej. Aby uzyskać więcej informacji, zobacz O Wysyłce dziennika.

w scenariuszu dublowania bazy danych, każda aktualizacja do bazy danych, głównej bazy danych, jest natychmiast odtwarzana w oddzielnej, pełnej kopii bazy danych, bazy danych lustrzanych. Główna instancja serwera wysyła każdy rekord dziennika natychmiast do instancji serwera lustrzanego, która stosuje przychodzące rekordy dziennika do bazy danych lustrzanej, nieustannie przesuwając go do przodu. Aby uzyskać więcej informacji, zobacz dublowanie bazy danych.,

charakterystyka dziennika transakcji

charakterystyka silnika bazy danych SQL Server dziennik transakcji:

• dziennik transakcji jest zaimplementowany jako oddzielny plik lub zestaw plików w bazie danych. Pamięć podręczna dziennika jest zarządzana oddzielnie od pamięci podręcznej bufora dla stron danych, co skutkuje prostym, szybkim i solidnym kodem w silniku bazy danych SQL Server. Aby uzyskać więcej informacji, zobacz Architektura fizyczna dziennika transakcji.

• format rekordów dziennika i stron nie jest ograniczony do formatu stron z danymi.,

• dziennik transakcji może być zaimplementowany w kilku plikach. Pliki mogą być definiowane jako rozwijane automatycznie przez ustawienie wartościFILEGROWTH dla dziennika. Zmniejsza to możliwość wyczerpania miejsca w dzienniku transakcji, jednocześnie zmniejszając koszty administracyjne. Aby uzyskać więcej informacji, zobacz plik ALTER DATABASE (Transact-SQL) oraz opcje grupy plików.

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

aby uzyskać informacje na temat architektury dziennika transakcji i wewnętrznych informacji, zobacz Przewodnik Architektury i zarządzania dziennikami transakcji SQL Server.

obcinanie dziennika transakcji

obcinanie dziennika zwalnia miejsce w pliku dziennika do ponownego użycia przez dziennik transakcji. Musisz regularnie obcinać swój dziennik transakcji, aby nie wypełniał przydzielonego miejsca. Kilka czynników może opóźnić obcinanie dziennika, więc monitorowanie rozmiaru dziennika ma znaczenie. Niektóre operacje mogą być minimalnie rejestrowane, aby zmniejszyć ich wpływ na rozmiar dziennika transakcji.,

log truncation usuwa nieaktywne wirtualne pliki dziennika (VLF) z logicznego dziennika transakcji bazy danych SQL Server, zwalniając miejsce w logu logicznym do ponownego użycia przez fizyczny dziennik transakcji. Jeśli dziennik transakcji nigdy nie zostanie obcięty, ostatecznie wypełni on całą przestrzeń dyskową przydzieloną fizycznym plikom dziennika.

aby uniknąć braku miejsca, chyba że obcinanie logów jest z jakiegoś powodu opóźnione, obcinanie następuje automatycznie po następujących zdarzeniach:

• w modelu prostego odzyskiwania, po punkcie kontrolnym.,
• w modelu odzyskiwania pełnego lub modelu odzyskiwania rejestrowanego zbiorczo, jeśli od poprzedniej kopii zapasowej wystąpił punkt kontrolny, obcinanie następuje po kopii zapasowej dziennika(chyba że jest to kopia zapasowa dziennika tylko do kopiowania).

aby uzyskać więcej informacji, zobacz czynniki, które mogą opóźnić obcinanie dziennika, w dalszej części tego tematu.

czynniki, które mogą opóźnić 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 wspomnieliśmy wcześniej w tym długim temacie.,

tak naprawdę obcinanie logów może być opóźnione z wielu powodów. Dowiedz się, co, jeśli cokolwiek, uniemożliwia obcinanie logów, pytając o kolumny log_reuse_wait i log_reuse_wait_desc sys.widok katalogu baz danych. Poniższa tabela opisuje wartości tych kolumn.,

td>

wartość log_reuse_wait	wartość log_reuse_wait_desc	opis
0	nic	obecnie istnieje jeden lub więcej wirtualnych plików dziennika wielokrotnego użytku (VLF).
1	punkt kontrolny	żaden punkt kontrolny nie wystąpił od ostatniego obcinania dziennika lub nagłówek dziennika nie przesunął się jeszcze poza wirtualny plik dziennika (VLF). (Wszystkie modele odzyskiwania) jest to rutynowa przyczyna opóźniania obcinania dziennika., Aby uzyskać więcej informacji, zobacz punkty kontrolne bazy danych (SQL Server).
2	LOG_BACKUP	przed obcięciem dziennika transakcji wymagana jest kopia zapasowa dziennika. (Tylko modele odzyskiwania z pełnym lub zbiorczym logowaniem) po zakończeniu następnej kopii zapasowej dziennika część przestrzeni dzienników może stać się wielokrotnego użytku.
3	active_backup_or_restore	trwa tworzenie kopii zapasowej lub przywracanie danych (wszystkie modele odzyskiwania). Jeśli kopia zapasowa danych uniemożliwia obcinanie logów, anulowanie operacji tworzenia kopii zapasowej może pomóc w natychmiastowym problemie.,
4	ACTIVE_TRANSACTION	transakcja jest aktywna (wszystkie modele odzyskiwania): na początku kopii zapasowej dziennika może istnieć długotrwała transakcja. W takim przypadku zwolnienie miejsca może wymagać kolejnej kopii zapasowej dziennika. Należy pamiętać, że długotrwałe transakcje zapobiegają obcinaniu dziennika we wszystkich modelach odzyskiwania, w tym prostym modelu odzyskiwania, w ramach którego dziennik transakcji jest zwykle obcinany w każdym automatycznym punkcie kontrolnym. transakcja zostaje odroczona., Transakcja odroczona jest aktywną transakcją, której wycofanie jest blokowane z powodu niedostępnego zasobu. Informacje na temat przyczyn transakcji odroczonych i sposobu ich przeniesienia ze stanu odroczonego można znaleźć w sekcji transakcje odroczone (SQL Server). długoterminowe transakcje mogą również wypełniać dziennik transakcji tempdb. Tempdb jest domyślnie używany przez transakcje użytkownika dla wewnętrznych obiektów, takich jak tabele robocze do sortowania, pliki robocze do mieszania, tabele robocze kursorów i wersjonowanie wierszy., Nawet jeśli transakcja użytkownika zawiera tylko odczyt danych (SELECT zapytania), wewnętrzne obiekty mogą być tworzone i używane w ramach transakcji użytkownika. Następnie można wypełnić dziennik transakcji tempdb.
5	database_mirroring	mirroring baz danych jest wstrzymany lub w trybie wysokiej wydajności baza danych lustrzanych znajduje się znacznie za główną bazą danych. (Tylko pełny model odzyskiwania) Aby uzyskać więcej informacji, zobacz dublowanie bazy danych (SQL Server).,
6	replikacja	podczas replikacji transakcyjnych transakcje istotne dla publikacji są nadal niedostarczane do bazy danych dystrybucji. (Tylko pełny model odzyskiwania) informacje na temat replikacji transakcyjnej można znaleźć w replikacji SQL Server.
7	DATABASE_SNAPSHOT_CREATION	tworzona jest migawka bazy danych. (Wszystkie modele odzyskiwania) jest to rutynowa i zazwyczaj krótka przyczyna opóźnionego obcinania logów.
8	LOG_SCAN	następuje skanowanie dziennika., (Wszystkie modele odzyskiwania) jest to rutynowa i zazwyczaj krótka przyczyna opóźnionego obcinania logów.
9	DOSTĘPNOŚĆ_REPLICA	wtórna replika grupy dostępności stosuje zapisy dziennika transakcji tej bazy danych do odpowiedniej wtórnej bazy danych. (Full recovery model) Aby uzyskać więcej informacji, zobacz Przegląd grup zawsze na dostępność (SQL Server).,
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 pośrednich punktów kontrolnych, najstarsza strona w bazie danych może być starsza niż numer sekwencji logu punktu kontrolnego (LSN). W takim przypadku najstarsza strona może opóźnić obcinanie dziennika. (Wszystkie modele odzyskiwania) informacje o pośrednich punktach kontrolnych można znaleźć w punkcie kontrolnym bazy danych (SQL Server).,
14	OTHER_TRANSIENT	ta wartość nie jest obecnie używana.
16	XTP_CHECKPOINT	należy wykonać punkt kontrolny OLTP w pamięci.W przypadku tabel zoptymalizowanych pod kątem pamięci automatyczny punkt kontrolny jest pobierany, gdy plik dziennika transakcji staje się większy niż 1.,5 GB od ostatniego punktu kontrolnego (obejmuje zarówno tabele oparte na dysku, jak i tabele zoptymalizowane pod kątem pamięci) Aby uzyskać więcej informacji, patrz operacja punktu kontrolnego dla tabel zoptymalizowanych pod kątem pamięci i (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

operacje, które mogą być minimalnie rejestrowane

minimalne logowanie polega na zapisaniu tylko tych informacji, które są wymagane do odzyskania transakcji bez obsługi odzyskiwania point-in-Time., Ten temat identyfikuje operacje, które są minimalnie rejestrowane w modelu odzyskiwania zapisanego zbiorczo (a także w modelu prostego odzyskiwania, z wyjątkiem sytuacji, gdy kopia zapasowa jest uruchomiona).

następujące operacje, które są w pełni rejestrowane w modelu pełnego odzyskiwania, są minimalnie rejestrowane w modelu prostego i zbiorczego odzyskiwania:

• operacje importu zbiorczego (bcp, bulk INSERT i INSERT… SELECT)., Aby uzyskać więcej informacji o minimalnym logowaniu importu zbiorczego do tabeli, zobacz Wymagania wstępne dotyczące minimalnego logowania importu zbiorczego.

gdy replikacja transakcyjna jest włączona, operacjeBULK INSERT są w pełni rejestrowane nawet w modelu odzyskiwania zbiorczego.

• wybierz do operacji.

gdy replikacja transakcyjna jest włączona, operacjeSELECT INTO są w pełni rejestrowane nawet w modelu odzyskiwania rejestrowanego zbiorczo.,

• częściowe aktualizacje typów danych o dużej wartości, przy użyciu klauzuli.WRITE w instrukcji UPDATE podczas wstawiania lub dodawania nowych danych. Należy pamiętać, że minimalne logowanie NIE jest używane, gdy istniejące wartości są aktualizowane. Aby uzyskać więcej informacji na temat typów danych o dużej wartości, zobacz Typy danych (Transact-SQL).

• polecenia writetext i UPDATETEXT podczas wstawiania lub dodawania nowych danych do kolumn typu danych tekstowych, ntext i image. Należy pamiętać, że minimalne logowanie NIE jest używane, gdy istniejące wartości są aktualizowane.,

  Ostrzeżenie

  poleceniaWRITETEXT IUPDATETEXT są przestarzałe; unikaj ich używania w nowych aplikacjach.

• Jeśli baza danych jest ustawiona na model odzyskiwania prostego lub zbiorczo rejestrowanego, niektóre operacje indeksu DDL są minimalnie rejestrowane, niezależnie od tego, czy operacja jest wykonywana w trybie offline czy online. Minimalnie rejestrowane operacje na indeksach są następujące:

  • tworzenie operacji na indeksach (w tym zindeksowanych widoków).

  • Zmień indeks lub operacje DBCC DBREINDEX.,

    Ostrzeżenie

    InstrukcjaDBCC DBREINDEX jest przestarzała; nie używaj jej w nowych aplikacjach.

    Uwaga

    operacje budowania indeksu używają minimalnego logowania, ale mogą być opóźnione, gdy jednocześnie wykonywana jest kopia zapasowa. Opóźnienie to jest spowodowane wymaganiami synchronizacji minimalnie zalogowanych stron puli buforów podczas korzystania z modelu odzyskiwania prostego lub zbiorczego.

  • DROP INDEX new heap rebuild (if applicable). Dealokacja strony indeksu podczas operacji DROP INDEX jest zawsze w pełni zalogowana.,n baza danych jest uszkodzona (SQL Server)

  Przywracanie dziennika transakcji (pełny model odzyskiwania)

  • przywracanie kopii zapasowej dziennika transakcji (SQL Server)

  patrz również

  SQL Server dziennik transakcji Przewodnik Architektury i zarządzania
  Kontrola trwałości transakcji
  wymagania wstępne dla minimalnego logowania importu zbiorczego
  Tworzenie kopii zapasowych i przywracanie baz danych SQL Server
  Przegląd przywracania i odzyskiwania (SQL Server)
  bazy danych checkpoints (SQL server)
  przeglądanie lub zmiana właściwości bazy danych
  modele odzyskiwania (SQL Server)
  kopie zapasowe dziennika transakcji (SQL server)
  sys.,dm_db_log_info (Transact-SQL)
  sys. dm_db_log_space_usage (Transact-SQL)