Przez całą moją karierę jako profesjonalista ds. danych, zarówno w firmie Microsoft, jak i jako konsultant, odkryłem, że jedną z najbardziej niezrozumiałych części bazy danych SQL Server jest dziennik transakcji. Brak wiedzy o tym, jak działa dziennik transakcji i jak należy nim zarządzać, lub po prostu proste nieporozumienia, mogą prowadzić do wszelkiego rodzaju problemów produkcyjnych, w tym:
- Dziennik transakcji wymyka się spod kontroli i potencjalnie zaczyna brakować miejsca
- Problemy z wydajnością spowodowane wielokrotnym zmniejszaniem dziennika transakcji
- Problemy z wydajnością związane z problemem znanym jako fragmentacja VLF , o którym pisałem w tym poście
- Niemożność przywrócenia do żądanego punktu w czasie za pomocą kopii zapasowych dziennika transakcji
- Niemożność wykonania kopii zapasowej końcowego dziennika podczas odzyskiwania po awarii (zobacz tutaj wyjaśnienie kopii zapasowych końcowego dziennika)
- Różne problemy dotyczące przełączania awaryjnego i przywracania wydajności
W tym poście rozpoczynam okazjonalną serię na temat dziennika transakcji oraz tego, jak to działa i jak należy nim zarządzać, a w trakcie poruszę wszystkie powyższe problemy. W tym poście wyjaśnię, czym jest logowanie i dlaczego jest wymagane.
Podstawowa terminologia dotycząca rejestrowania
Kiedy mówię o dowolnym mechanizmie w SQL Server, stwierdzam, że istnieje problem z kurczakiem i jajkiem, w którym muszę użyć słowa lub frazy, zanim to wyjaśnię. Aby uniknąć tego problemu w tej serii, zacznę od wyjaśnienia terminologii, której należy używać podczas omawiania rejestrowania, a w miarę postępu serii będę rozwijać wiele z tych terminów.
Transakcja, zatwierdzenie i wycofanie
Transakcja obejmuje zmianę lub zestaw zmian w bazie danych. Ma określony początek i określony koniec. Początek jest wtedy, gdy używana jest instrukcja BEGIN TRANSACTION lub SQL Server automatycznie rozpoczyna transakcję za Ciebie. Koniec może być jedną z czterech rzeczy:
- Transakcja zostaje zatwierdzona po wykonaniu instrukcji COMMIT TRANSACTION
- Transakcja zostaje zatwierdzona, gdy SQL Server automatycznie zatwierdza transakcję w przypadku transakcji autocommit
- Transakcja kończy się wycofywanie po wykonaniu instrukcji ROLLBACK TRANSACTION
- Transakcja kończy się wycofywać po wystąpieniu problemu, a SQL Server automatycznie wycofał transakcję
Gdy transakcja zostanie zatwierdzona, dokonane przez nią zmiany są finalizowane w bazie danych i są trwałe w dzienniku transakcji programu SQL Server na dysku. Zauważ, że powiedziałem „w dzienniku transakcji”. Rzeczywiste zmiany stron pliku danych w pamięci *nie* są zapisywane na dysku podczas zatwierdzania transakcji. Nie muszą być trwałe w plikach danych, ponieważ zmiany są już trwałe w dzienniku transakcji. Ostatecznie strony pliku danych zostaną zapisane na dysku przez operację punktu kontrolnego.
I odwrotnie, gdy transakcja zostanie wycofana, zmiany danych dokonane przez transakcję nie są już obecne w bazie danych. W bazie danych nadal będą występować pewne fizyczne zmiany, ponieważ wycofanie transakcji oznacza wykonanie większej liczby zmian, ale można pomyśleć, że wycofana transakcja nie wpłynęła na dane w bazie danych.
Punkty kontrolne i operacje wycofywania to tematy godne własnych postów, więc wyjaśnię je w dalszej części serii.
Omówię te trzy terminy znacznie bardziej szczegółowo w samouczku Wprowadzenie do transakcji SQL Server na blogu SentryOne.
Logowanie, zapisy dziennika i dziennik transakcji SQL Server
Logowanie to po prostu tworzenie trwałego opisu zmiany w bazie danych, prawie zawsze w kontekście transakcji. Po wprowadzeniu zmiany jest ona opisana w rekordzie dziennika. Rekord dziennika zwykle zawiera wystarczającą ilość informacji, aby umożliwić odtworzenie zmiany w bazie danych lub wycofanie jej w razie potrzeby.
Ten rekord dziennika będzie początkowo znajdował się w pamięci i może zostać zapisany na dysku przed zatwierdzeniem transakcji, ale zdecydowanie musi zostać zapisany na dysku przed transakcja może zakończyć popełnienie, w przeciwnym razie transakcja nie byłaby trwała. Wyjątkiem od tej reguły jest sytuacja, gdy opóźniona trwałość funkcja jest włączona, o czym Aaron Bertrand omawia w tym poście.
Rekordy dziennika są przechowywane w dzienniku transakcji (jeden lub więcej plików dziennika na dysku), który ma nieco złożoną architekturę wewnętrzną, i omówię to i wiele więcej o rekordach dziennika w następnym poście z tej serii.
Odzyskiwanie po awarii
Awaria to sytuacja, w której SQL Server został nieoczekiwanie zamknięty, a różne zmienione bazy danych nie mogły zostać poprawnie zamknięte (upewniając się, że wszystkie zmienione strony plików danych są zapisywane na dysku, a baza danych jest oznaczona jako czysto zamknięta).
Kiedy SQL Server uruchamia się, sprawdza wszystkie bazy danych, aby zobaczyć, czy żadna z nich nie została oznaczona jako czysto zamknięta. Jeśli go znajdzie, ta baza danych musi przejść przez odzyskiwanie po awarii. Gwarantuje to, że:
- W przypadku każdej transakcji, która została zatwierdzona przed awarią, upewnij się, że wszystkie zmiany w transakcji są odzwierciedlone w bazie danych (tj. Odtwórz transakcję)
- W przypadku każdej transakcji, która nie została zatwierdzona przed awarią, upewnij się, że żadne zmiany w transakcji nie są odzwierciedlone w bazie danych (tj. wycofaj transakcję)
Innymi słowy, odzyskiwanie po awarii sprawia, że baza danych spójna transakcyjnie od czasu awarii. Stosowane jest odzyskiwanie po awarii:
- Kiedy SQL Server zostanie uruchomiony i znajdzie bazę danych, którą należy odzyskać
- Podczas przełączania awaryjnego na dodatkową kopię bazy danych
- Pod koniec sekwencji przywracania obejmującej kopie zapasowe (patrz tutaj)
Odzyskiwanie po awarii to złożony proces i wymaga jeszcze kilku wpisów z serii, zanim będę mógł go szczegółowo wyjaśnić.
Dlaczego logowanie jest wymagane?
Najbardziej podstawowym powodem rejestrowania jest umożliwienie bazie danych SQL Server uczynienia transakcji trwałymi, dzięki czemu można je odzyskać podczas odzyskiwania po awarii lub wycofać je w razie potrzeby podczas normalnych operacji na bazie danych. Gdyby nie było logowania, baza danych byłaby niespójna transakcyjnie i prawdopodobnie strukturalnie uszkodzona po awarii.
Jednak bez logowania wiele innych funkcji SQL Server nie byłoby możliwe, w tym:
- Kopie zapasowe danych, które można konsekwentnie odzyskiwać
- Kopie zapasowe dziennika transakcji SQL Server, które mogą być używane podczas operacji przywracania i wdrażania przesyłania dziennika
- Replikacja, która polega na możliwości zbierania transakcji z dziennika transakcji
- Zmiana przechwytywania danych, która wykorzystuje agenta odczytu dziennika replikacji transakcyjnej do przechwytywania zmian z dziennika transakcji
- Grupy dublowania i dostępności bazy danych, które polegają na wysyłaniu rekordów dziennika do wtórnych kopii bazy danych w celu odtworzenia
SQL Server (i wszystkie podobne serwery baz danych) używają tak zwanego rejestrowania z wyprzedzeniem . Oznacza to, że opisy zmian muszą zostać zapisane na dysku przed samymi zmianami, aby zagwarantować możliwość prawidłowego awaryjnego odzyskania bazy danych. Jeśli zmiana została zapisana w pliku danych przed zapisami w dzienniku, które ją opisują, a program SQL Server uległ awarii, nie byłoby możliwości sprawdzenia, co należy wycofać, a baza danych byłaby niespójna. Ta kolejność jest niezmienna, bez względu na poziom izolacji, rodzaj transakcji lub czy używana jest funkcja opóźnionej trwałości. Najpierw rejestruj rekordy, później strony danych.
Tylko wierzchołek góry lodowej
Jak widać z tego wpisu wprowadzającego, ogromna ilość trafia do dziennika transakcji i logowania do bazy danych SQL Server, a wszystko, co do tej pory zrobiłem, to zdefiniowanie terminologii wysokiego poziomu i wyjaśnienie, dlaczego logowanie jest wymagane. Mam nadzieję, że dołączysz do mnie, gdy będę się rozwijał i zagłębiał się w toku serii!
