W moim poprzednim poście na temat usprawniania operacji dziennika transakcji omówiłem dwie najczęstsze przyczyny generowania dodatkowych rekordów dziennika:martwą wagę z nieużywanych indeksów nieklastrowanych i operacje podziału strony (które powodują fragmentację indeksu). Zakładając, że przeczytałeś ten post, wspomniałem, że istnieją bardziej subtelne problemy, które mogą mieć negatywny wpływ na wydajność dziennika transakcji, i omówię je tutaj.
Wiele, wiele małych transakcji
Co jakiś czas program SQL Server opróżni część dziennika transakcji na dysk. Opróżnianie dziennika następuje zawsze, gdy:
- Generowany jest zapis dziennika zatwierdzania transakcji.
- Rekord dziennika przerwania transakcji jest generowany na koniec wycofywania transakcji.
- 60 KB rekordów dziennika zostało wygenerowanych od czasu poprzedniego czyszczenia dziennika.
Najmniejsze możliwe opróżnianie dziennika to pojedynczy 512-bajtowy blok dziennika. Jeśli wszystkie transakcje w obciążeniu są bardzo małe (np. wstawienie pojedynczego, małego wiersza tabeli), wystąpi wiele opróżnień dziennika o minimalnym rozmiarze. Opróżnianie dziennika jest wykonywane asynchronicznie, aby umożliwić przyzwoitą przepustowość dziennika transakcji, ale istnieje stały limit 32 jednoczesnych operacji we/wy opróżniania dziennika w dowolnym momencie (podniesiony do 112 w SQL Server 2012).
Może to mieć dwa możliwe skutki:
- W wolno działającym podsystemie we/wy ilość niewielkich zapisów w dzienniku transakcji może przeciążyć podsystem we/wy, prowadząc do zapisów o dużych opóźnieniach i późniejszego obniżenia przepustowości dziennika transakcji. Sytuację tę można rozpoznać po dużych opóźnieniach zapisu w pliku dziennika transakcji w danych wyjściowych sys.dm_io_virtual_file_stats (zobacz linki do wersji demonstracyjnych na początku poprzedniego postu)
- W podsystemie we/wy o wysokiej wydajności zapisy mogą zakończyć się niezwykle szybko, ale limit 32 równoczesnych operacji we/wy opróżniających dzienniki tworzy wąskie gardło podczas próby zapewnienia trwałości rekordów dziennika na dysku. Sytuację tę można rozpoznać po niskich opóźnieniach zapisu i prawie stałej liczbie zaległych zapisów dziennika transakcji, bliskiej 32 w zagregowanych danych wyjściowych sys.dm_io_pending_io_requests (zobacz te same łącza demonstracyjne).
W obu przypadkach wydłużenie transakcji (co jest bardzo sprzeczne z intuicją!) może zmniejszyć częstotliwość opróżniania dziennika transakcji i zwiększyć wydajność. Dodatkowo, w przypadku nr 1, przejście do podsystemu We/Wy o wyższej wydajności może pomóc, ale może prowadzić do przypadku nr 2. W przypadku nr 2, jeśli transakcji nie można wykonać dłużej, jedyną alternatywą jest rozdzielenie obciążenia na wiele baz danych w celu obejścia stałego limitu 32 współbieżnych operacji we/wy opróżniających dzienniki lub uaktualnienie do wersji SQL Server 2012 lub nowszej.
Automatyczny wzrost dziennika transakcji
Za każdym razem, gdy do dziennika transakcji dodawane jest nowe miejsce, musi być ono zainicjowane zerami (wypisywanie zer w celu nadpisania poprzedniego użycia tej części dysku), bez względu na to, czy funkcja natychmiastowej inicjalizacji pliku jest włączona, czy nie. Dotyczy to tworzenia, ręcznego i automatycznego powiększania dziennika transakcji. Podczas gdy inicjalizacja zera ma miejsce, rekordy dziennika nie mogą być opróżniane do dziennika, więc automatyczny wzrost podczas obciążenia, które zmienia dane, może prowadzić do zauważalnego spadku przepustowości, zwłaszcza jeśli rozmiar automatycznego wzrostu jest ustawiony na duży ( powiedz gigabajty lub pozostaw domyślnie 10%).
Należy zatem unikać automatycznego wzrostu, jeśli to w ogóle możliwe, pozwalając na wyczyszczenie dziennika transakcji, aby zawsze było wolne miejsce, które można ponownie wykorzystać na nowe rekordy dziennika. Czyszczenie dziennika transakcji (znane również jako obcinanie dziennika transakcji, którego nie należy mylić ze zmniejszaniem dziennika transakcji) jest wykonywane przez kopie zapasowe dziennika transakcji w trybie odzyskiwania pełnego lub zbiorczego, a także przez punkty kontrolne w trybie odzyskiwania prostego.
Czyszczenie dziennika może nastąpić tylko wtedy, gdy nic nie wymaga usunięcia zapisów dziennika w sekcji dziennika transakcji. Jednym z powszechnych problemów, które uniemożliwiają czyszczenie dziennika, jest posiadanie długotrwałych transakcji. Dopóki transakcja nie zostanie zatwierdzona lub wycofana, wszystkie rekordy dziennika od początku transakcji są wymagane w przypadku wycofania transakcji — w tym wszystkie rekordy dziennika z innych transakcji, które są przeplatane z tymi z transakcji długoterminowej. Transakcje długotrwałe mogą być spowodowane na przykład złym projektem, kodem czekającym na wkład ludzki lub niewłaściwym wykorzystaniem transakcji zagnieżdżonych. Wszystkich tych można uniknąć, gdy zostaną zidentyfikowane jako problem.
Możesz przeczytać więcej na ten temat tutaj i tutaj.
Funkcje wysokiej dostępności
Niektóre funkcje wysokiej dostępności mogą również opóźnić czyszczenie dziennika transakcji:
- Grupy dublowania i dostępności bazy danych, gdy działają asynchronicznie, mogą tworzyć kolejkę rekordów dziennika, które nie zostały jeszcze wysłane do nadmiarowej kopii bazy danych. Te zapisy dziennika muszą być przechowywane, dopóki nie zostaną wysłane, opóźniając czyszczenie dziennika transakcji.
- Replikacja transakcyjna (a także zmiana przechwytywania danych) opiera się na zadaniu agenta odczytującego dzienniki, które okresowo skanuje dziennik transakcji w poszukiwaniu transakcji, które modyfikują tabelę zawartą w publikacji replikacji. Jeśli Agent odczytujący dzienniki pozostaje w tyle z jakiegokolwiek powodu lub celowo jest uruchamiany rzadko, wszystkie zapisy dziennika, które nie zostały zeskanowane przez zadanie, muszą być przechowywane w pobliżu, opóźniając czyszczenie dziennika transakcji.
W trybie synchronicznym dublowanie bazy danych i grupy dostępności mogą powodować inne problemy z mechanizmem rejestrowania. Korzystając z synchronicznego dublowania bazy danych jako przykładu, każda transakcja, która zostaje zatwierdzona dla podmiotu zabezpieczeń, nie może w rzeczywistości powrócić do użytkownika lub aplikacji, dopóki wszystkie wygenerowane przez nią rekordy dziennika nie zostaną pomyślnie wysłane do serwera lustrzanego, co spowoduje dodanie opóźnienia zatwierdzenia na podmiotu zabezpieczeń. Jeśli średni rozmiar transakcji jest długi, a opóźnienie krótkie, może to nie być zauważalne, ale jeśli średnia transakcja jest bardzo krótka, a opóźnienie dość długie, może to mieć zauważalny wpływ na przepustowość obciążenia. W takim przypadku należy zmienić cele wydajności obciążenia, zmienić technologię wysokiej dostępności na tryb asynchroniczny lub zwiększyć przepustowość sieci i prędkość między główną i nadmiarową bazą danych.
Nawiasem mówiąc, ten sam rodzaj problemu może wystąpić, jeśli sam podsystem we/wy jest synchronicznie dublowany – z potencjalnym opóźnieniem dla wszystkich zapisów wykonywanych przez SQL Server.
Podsumowanie
Jak widać, wydajność dziennika transakcji to nie tylko generowanie dodatkowych rekordów dziennika transakcji – istnieje wiele czynników środowiskowych, które również mogą mieć ogromny wpływ.
Najważniejsze jest to, że kondycja i wydajność dziennika transakcji mają ogromne znaczenie dla utrzymania ogólnej wydajności obciążenia. W tych dwóch postach szczegółowo opisałem główne przyczyny problemów z wydajnością dziennika transakcji, więc mam nadzieję, że będziesz w stanie zidentyfikować i naprawić wszystkie, które masz.
Jeśli chcesz dowiedzieć się znacznie więcej o operacjach dziennika transakcji i dostrajaniu wydajności, polecam zapoznać się z moim 7,5-godzinnym kursem szkoleniowym online na temat rejestrowania, odzyskiwania i dziennika transakcji, dostępnym za pośrednictwem Pluralsight.
