Każda baza danych SQL Server’a składa się ze zbioru plików na poziomie system operacyjnego. Pliki te przechowują dane oraz informacje o zmianach w bazie. Poszczególne pliki mogą być używane tylko przez jedną bazę, a dane i informacja o zmianach w bazie nigdy nie są zapisywane w tym samym pliku. Dane przechowywane są w plikach MDF, natomiast wszystkie transakcje modyfikujące dane oraz transakcje modyfikujące na poziomie bazy danych, przechowywane są w drugim podstawowym komponencie bazy danych, w pliku LDF czyli w pliku logu transakcyjnego. Plik logu jest ciągiem rekordów. Fizycznie, rekordy logu transakcyjnego są przechowywane w jednym lub w wielu fizycznych plikach LDF.
Głównym celem logu transakcyjnego jest umożliwienie realizacji koncepcji ACID – Atomicity (Atomowość, niepodzielność), Consistency (Spójność), Isolation (Izolacja), and Durability (Trwałość).
- Niepodzielność – oznacza, że każda transakcja wykona się w całości lub nie wykona się w ogóle; innymi słowy jeżeli jedna część transakcji zakończy się niepowodzeniem to cała transakcja zakończy się niepowodzeniem i baza pozostanie niezmieniona,
- Spójność – każda transakcja wykonana na bazie przeniesie ją z jednego poprawnego stanu w kolejny poprawny stan,
- Izolacja – wykonanie jednoczesnych transakcji, zmianę bazy tak jakby transakcje były wykonywane jedna po drugiej,
- Trwałość – raz zapisane dane pozostają w bazie, nawet jeśli system uległ awarii, na przykład po utracie zasilania.
Plik LDF przechowuje wystarczająco dużo informacji do powtórzenia lub wycofania zmian lub do odtworzenia bazy do określonego punktu w czasie. Jest to powód, dla którego chcemy czasami otworzyć plik LDF i zobaczyć jego zawartość. Ale wyświetlanie pliku LDF nie jest zadaniem trywialnym.
Istnieje kilka wbudowanych funkcji i komend SQL Server’a (np. fn_dblog, fn_dump_dblog, and DBCC PAGE), które dają możliwość wyświetlania zawartości pliku LDF. Ich użycie wymaga jednak znajomości T-SQL’a, a dodatkowo, ponieważ nie wszystkie funkcje są udokumentowane, to nie jest łatwo przekształcić otrzymany wynik działania funkcji na format czytelny dla człowieka. Poniżej widzimy kilka przykładów zawartości pliku LDF, wyświetlonej przy pomocy wbudowanych funkcji i komend:
-
Użycie funkcji fn_dblog do czytania logu transakcyjnego, daje w wyniku 129 kolumn (poniżej widzimy tylko 7):
-
Funkcja fn_dump_dblog użyta do przeczytania kopi zapasowej logu transakcyjnego (także skompresowanej) daje podobny rezultat:
Niestety, podobnie jak w przypadku funkcji fn_dblog, również nie istnieje oficjalna dokumentacja dla funkcji fn_dump_dblog. Aby przetłumaczyć widoczne powyżej kolumny, trzeba znać wewnętrzną strukturę zbioru wynikowego, format danych, różnorodne flagi i ich całkowitą liczbę w wierszach z danymi.
-
Komenda DBCC PAGE używana jest do czytania używanych online plików bazy danych – plików MDF i LDF. Wynik wyświetlany szesnastkowo, jest nieczytelny, jeśli nie posiada się edytora szesnastkowego:
Użycie ApexSQL Log do czytania logu transakcyjnego
ApexSQL Log jest narzędziem do czytania logu transakcyjnego SQL Server’a zarówno plików online, jak i odłączonych plików logu oraz kopii zapasowych plików logu (także tych skompresowanych). Aplikacja ApexSQL Log, będąc m.in. przeglądarką plików LDF jest skoncentrowana na wykonanych działaniach, zarówno tych, które zmieniają same dane (DML), jak i tych, które tworzą lub zmieniają strukturę obiektów bazy (DDL) – jest to w sumie 45 różnych działań.
Oprócz wyświetlania logicznej zawartości pliku LDF, ApexSQL Log dostarcza dodatkowe funkcjonalności, takie jak tworzenie skryptów Undo/Redo, historii działań dla poleceń DML i więcej
Aby otworzyć i wyświetlić plik LDF przy pomocy ApexSQL Log należy:
-
Połączyć się z bazą danych, do której należy plik logu.
-
2. W kolejnym kroku należy dodać wszystkie pliki LDF, które zawierają interesujące nas informacje do czytania: kopie zapasowe plików logu, odłączone pliki logów. Trzeba upewnić się, że dodane są wszystkie pliki logów w pełnym łańcuchu logów. Łańcuch logów jest ciągłą sekwencją kopii zapasowych logów transakcyjnych. Łańcuch logów rozpoczyna się pełną kopią zapasową bazy danych, po której następują kopie zapasowe logów transakcyjnych aż do momentu, który chcemy przejrzeć. Przerwanie sekwencji logów transakcyjnych powoduje, że mogą być wyświetlone tylko transakcje w logach do ostatniej kopii zapasowej przed kopią, którą utraciliśmy (np. schemat i nazwa obiektu, historia wierszy).
Szczególnym przypadkiem działań na bazie jest operacja UPDATE, dla której – w przeciwieństwie do operacji INSERT i DELETE, które są w pełni logowane w plikach LDF – logowanie wykonywane jest na minimalnym poziomie, ponieważ logowane są tylko zmiany, a nie są zapamiętywane wartość oryginalna i wartość nowa. SQL Server, logując do logu transakcyjnego operację UPDATE nie zapisuje stanu wiersza przed i po zmianie, zapisuje tylko przyrostowo co zostało zmienione. Na przykład, jeśli słowo „log” zostało zamienione na słowo „blog”, to SQL Server w tym przypadku zapisze do logu dodanie litery „b” na pozycji (indeksie) 0. Taki sposób zapisu jest wystarczający z punktu widzenia konieczności zapewnienia koncepcji ACID, ale nie umożliwia łatwego pokazania wartości sprzed i po zmianie. W celu zrozumienia co faktycznie zostało zmienione, ApexSQL Log na podstawie pozostałych logów transakcyjnych lub kopii zapasowych logów i kopii bazy rekonstruuje kontekst, w którym zaszła zmiana.
Aby to osiągnąć, narzędzie stosuje wiele różnorodnych, wzajemnie komplementarnych technik rekonstruujących, wykorzystując pełny łańcuch logów. Tylko poprawne wyspecyfikowanie pełnego łańcucha logów, włączając ostatnią pełną kopię zapasową bazy danych i różnicowe kopie zapasowe umożliwia aplikacji ApexSQL Log zrekonstruować kontekst dla polecenia UPDATE, rozpoczynając od stanu zaktualizowanego wiersza w czasie ostatniej kopii zapasowej i odtwarzając wszystkie działania, które wpłynęły na aktualizowany wiersz. W naszym przykładzie, ApexSQL Log znalazłby stan wiersza w czasie ostatniej kopii zapasowej, czyli zobaczyłby wartość „log”, a następnie na podstawie zalogowanej w logu transakcyjnym zmiany, która dodała literę „b” na indeksie 0, zrekonstruował nową wartość „blog”.
Co więcej, łańcuch logów umożliwia czytanie transakcji szybciej, jeśli wykorzystujemy kilka kopii zapasowych logów transakcyjnych, niż gdy używany jest tylko pojedynczy online’owy log transakcyjny, który często jest kilkukrotnie większy niż wszystkie użyte kopie logów transakcyjnych. Dodatkowo, jako źródło do czytania danych przez ApexSQL Log może być użyty odłączony plik LDF.
Dodawanie logów do analizy wykonywane jest poleceniem Add w kroku Select SQL logs to analyze step
-
Zakładka Database backups umożliwia wybranie pełnej kopii zapasowej bazy danych, która będzie użyta jako punkt początkowy analizowanych transakcji.
-
Sekcja Time range w kroku Filter setup, pozwala określić zakres czasu, w którym były wykonywane interesujące nas transakcje. Przyspieszy to cały proces, przez zawężenie liczby operacji do analizy .
- Po ustawieniu opcji opisanych powyżej, przycisk Open uruchamia proces czytania plików LDF.
Wszystkie transakcje, zgodnie z wyspecyfikowanymi źródłami i zbiorem filtrów, zostaną wyświetlone głównym oknie ApexSQL Log’a.
Wnioski o czytaniu pliku LDF
Podsumowując, są różne sposoby otwierania pliku LDF i większość z nich po prostu je otwiera. Nie jest łatwo wydobyć z wyświetlanych informacji dane w formacie czytelnym dla człowieka. ApexSQL Log, oprócz prostego otwierana pliku LDF, dostarcza dodatkową wartość w postaci możliwości obejrzenia różnych typów operacji wykonywanych na bazie, nazw zmienianych obiektów wraz ze schematami, czasu wykonania operacji, nazwy użytkownika, który operację wykonał i wiele innych.
Do głównych zalet przetwarzania plików LDF przy pomocy ApexSQL Log’a należą:
- Pokazania w formacie czytelnym dla człowieka informacji, pochodzących ze 129 kolumn natywnie zapisanych w logu, w sposób powiązany ze sobą
- Połączenie w łańcuch różnych plików LDF
- Łączne analizowanie plików logów online, kopi zapasowych plików (zarówno bazy danych jak i logów transakcyjnych), w celu dostarczenia szczegółowych informacji o wykonanych transakcjach
- W pełni odtworzenie polecenia UPDATE, włączając możliwość odtworzenia wartości oryginalnej i nowej
- Możliwość pokazania pełnej historii zmian dla operacji typu DML, włączają dane o użytkowniku, który wykonał każdą operację oraz o czasie jej wykonania
- Wstępne filtrowanie informacji, które będą z logu czytane w celu przyspieszenia procesu czytania i zmniejszenia wykorzystania zasobów systemu
- Mapowanie starych (usuniętych) identyfikatorów tabel, w celu umożliwienia odtworzenia danych z tablic, które zostały usunięte
- Przetwarzanie i wyświetlanie zawartości pliku LDF bez konieczności znajomości języka T-SQL
Oprócz czytania logu, ApexSQL Log także pozwala na:
- Sortowanie, grupowanie, filtrowanie i zaawansowane przeszukiwanie danych odczytanych z logu
- Zapisywanie odczytanych i odpowiednio przekonwertowanych danych z logu w plikach w formacie CSV, HTML, XML lub SQL w celu późniejszej analizy
- Tworzenie skryptów, umożliwiających ponowne wykonanie lub wycofanie wykonanych transakcji, co może być użyteczne w przypadku różnych scenariuszy odtwarzania bazy danych lub w przypadku wycofania zmian wykonanych na schemacie bazy danych, bez konieczności odtwarzania danych z pełnej kopii zapasowej
- Przejrzenie oficjalnej dokumentacji dla całej funkcjonalności aplikacji
- Zadanie pytań obsłudze technicznej i wiele innych
Autor: Ivan Stankovic
Tłumacz: Anna Lesniak
November 4, 2015