Monitorowanie dziennika transakcji

W ciągu ostatniego roku kilka razy pisałem na blogu SQLPerformance.com o problemach z wydajnością dziennika transakcji (patrz tutaj) i obiecałem omówić monitorowanie dziennika transakcji, co zrobię w tym poście. Przedstawię niektóre metryki, które możesz śledzić, dlaczego powinieneś się tym przejmować oraz wszelkie porady dotyczące rozwiązania wskazanego problemu.

DMV

Najłatwiejszym sposobem monitorowania opóźnień we/wy dziennika transakcji jest użycie sys.dm_io_virtual_file_stats DMV. Będziesz musiał wykonać trochę matematyki, aby uzyskać przydatne wyniki, a przykładowy kod możesz uzyskać w skrypcie VirtualFileStats.sql w tym demonstracyjnym pliku zip. Naprawdę chcesz zobaczyć opóźnienia zapisu mniejsze niż 5 ms dla dziennika transakcji.

Wcześniej w listopadzie napisałem na blogu wyniki ankiety pokazującej opóźnienia dziennika transakcji i plików danych tempdb dla ponad 25 000 baz danych na całym świecie (patrz tutaj), przy czym 80% baz danych osiąga 5 ms lub mniej opóźnienia w zapisie dziennika transakcji.

Jeśli opóźnienie zapisu przekracza 5 ms, możesz:

• Pracuj nad zmniejszeniem ilości generowanych logów i/lub ilości opróżnień logów występujących w przypadku małych transakcji, jak opisałem we wcześniejszych postach.
• Wykonaj niektóre z kroków rozwiązywania problemów, które opisałem w powyższym poście na blogu z ankietą.
• Przejdź do szybszego podsystemu I/O, pamiętając, że jeśli zdecydujesz się na użycie dysku SSD, musisz użyć dwóch w konfiguracji RAID-1.

Inną rzeczą, którą możesz sprawdzić, jest upewnienie się, że nie przekroczysz sztywnego limitu 32 zaległych operacji we/wy dla każdej bazy danych w dzienniku transakcji w 2008 R2 i wcześniejszych (podniesionych do 2012 r. od SQL Server 2012 i nowszych). Możesz spróbować to zrobić, patrząc na Dysk fizyczny/Śr. Długość kolejki zapisu dysku, ale dotyczy to całego woluminu, a nie pliku, więc jeśli na woluminie jest coś innego oprócz pliku dziennika, który Cię interesuje, nie da Ci to prawidłowego numeru. Lepszym sposobem jest zagregowanie wyników sys.dm_io_pending_io_requests DMV, który zawiera listę wszystkich zaległych wejść/wyjść. Oto kod, który to zrobi:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Możesz łatwo to zmodyfikować, aby wyświetlać tylko wyniki dla plików dziennika (filtr na type_desc ='LOG' ) i tylko dla identyfikatora bazy danych, który Cię interesuje.

Jeśli stwierdzisz, że osiągasz limit 32 dla określonej bazy danych, możesz:

• Zmniejsz liczbę opróżnień dziennika, zmniejszając liczbę małych transakcji i uważając na takie rzeczy, jak podziały stron i nieużywane/duplikaty indeksów, które są zmieniane podczas operacji modyfikacji danych. Możesz przeczytać więcej o optymalizacji opróżniania dzienników w tym poście na blogu
• Spróbuj użyć szybszego podsystemu we/wy
• Uaktualnij do wersji SQL Server 2012 lub nowszej, gdzie limit wynosi 112
• Wypróbuj delayed durability feature DMV, który został dodany w SQL Server 2014
• W ostateczności podziel obciążenie na wiele baz danych lub serwerów

Jeśli chcesz zobaczyć, ile dziennika transakcji jest generowane przez Twoje transakcje, możesz użyć sys.dm_tran_database_transactions DMV, w kodzie podobnym do poniższego:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Możesz być bardzo zaskoczony, ile logów jest generowanych, zwłaszcza w tempdb dla kodu, który wykorzystuje obiekty tymczasowe. I oczywiście dziennik transakcji tempdb może być wąskim gardłem, podobnie jak w przypadku bazy danych użytkowników.

Liczniki monitora wydajności

Wszystkie liczniki wydajności związane z dziennikiem znajdują się w obiekcie wydajności Bazy danych. Oto niektóre z najważniejszych do obejrzenia (z samym Monitorem wydajności, za pomocą alertów agenta SQL lub za pomocą DMV sys.dm_os_performance_counters lub w ulubionym narzędziu do monitorowania innej firmy):

Zrosty dziennika

Nie chcesz, aby ten licznik się zwiększał, ponieważ mówi, że w bazie danych dzieje się coś, co powoduje generowanie większej liczby dzienników transakcji niż jest dostępne miejsce. Oznacza to, że dziennik transakcji nie jest w stanie wyczyścić, dlatego należy zbadać przyczynę, wysyłając zapytanie do pola log_reuse_wait_desc w sys.databases i podjąć wszelkie wymagane działania (więcej informacji można znaleźć w temacie Books Online „Czynniki, które mogą opóźnić obcinanie dziennika”). Przykładowy kod to:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Za każdym razem, gdy pojawia się wzrost dziennika, nowo przydzielona część dziennika transakcji musi zostać wyzerowana, a ponadto dodaje się więcej wirtualnych plików dziennika – z których oba mogą powodować problemy, o czym pisałem wcześniej.

Log kurczy się

Jeśli nie jesteś osobą wykonującą operację zmniejszania, aby przywrócić kontrolę nad niekontrolowanym dziennikiem transakcji, nie chcesz, aby ten licznik się zwiększał. Jeśli ktoś po prostu zmniejszy dziennik transakcji bez uzasadnionego powodu, prawdopodobnie znów się rozrośnie, powodując problemy, o których pisałem wcześniej.

Procent używanego dziennika

Powinieneś monitorować ten licznik i obawiać się, jeśli wartość wzrośnie powyżej 90%, ponieważ oznacza to, że wzrost dziennika może być nieuchronny, a dziennik transakcji nie jest w stanie poprawnie wyczyścić, jak omówiłem powyżej.

Oczekiwanie na opróżnianie dziennika/s

Chcesz, aby ta wartość pozostała taka sama lub się zmniejszyła. Jeśli wzrośnie, oznacza to, że masz wąskie gardło podsystemu we/wy lub wąskie gardło w mechanizmie opróżniania dziennika, ponieważ opróżniasz wiele małych części dziennika. Wzrost tutaj może również korelować z trafieniem w 32 zaległe operacje we/wy dla dziennika. Zobacz dyskusję na temat sys.dm_io_pending_io_requests powyżej, aby uzyskać więcej informacji.

Opróżnianie dziennika bajtów/s i opróżnianie dziennika/s

Te dwa liczniki pozwalają obliczyć średni rozmiar opróżniania kłody, dzieląc pierwszy licznik przez drugi. Wynikiem będzie wartość od 512 do 61440 (odpowiednio minimalna i maksymalna wielkość spłukiwania kłód). Niższa wartość jest bardziej skorelowana ze wzrostem liczby oczekiwań na opróżnianie dziennika/s. Ponownie zobacz dyskusję na temat sys.dm_io_pending_io_requests powyżej, aby uzyskać więcej informacji.

Wydarzenia rozszerzone

Dla bardziej zaawansowanych spośród was istnieje kilka rozszerzonych zdarzeń, których można użyć do obserwowania, co dzieje się z dziennikiem. Zalecam rozpoczęcie od użycia szablonu śledzenia we/wy pliku dziennika bazy danych w programie SQL Server 2012 SSMS. Możesz się do tego dostać, przechodząc do Eksploratora obiektów, a następnie do swojej instancji -> Zarządzanie -> Zdarzenia rozszerzone i klikając prawym przyciskiem myszy Sesje, aby wybrać Kreator nowej sesji. W wyświetlonym oknie wpisz nazwę sesji i wybierz szablon śledzenia z listy rozwijanej. Następnie naciśnij Ctrl+Shift+N, a sesja zostanie przypisana do okna zapytania. Szczegóły tego wszystkiego są niestety poza zakresem tego postu, ale opis szablonu jest dość wyjaśniający:

W SQL Server 2012 pojawiło się również nowe zdarzenie Extended Event o nazwie transaction_log, którego można używać do wykonywania wszelkiego rodzaju interesujących analiz tego, jakie rekordy dziennika są generowane. To zdecydowanie temat, który omówię w przyszłym poście.

Podsumowanie

Biorąc pod uwagę wszystkie powyższe informacje, powinieneś być w stanie wymyślić całkiem dobry system monitorowania dzienników transakcji. Kondycja dziennika transakcji ma ogromne znaczenie dla zapewnienia prawidłowego działania obciążenia i mam nadzieję, że cztery posty z tej serii (oraz wszystkie inne linki) pomogły Ci poprawić ogólną wydajność środowiska SQL Server.