W moich ostatnich dwóch postach omówiłem sposoby zmniejszenia ilości generowanego dziennika transakcji i zapewnienia, że dziennik transakcji zawsze może zostać poprawnie wyczyszczony. W tym poście chcę kontynuować temat wydajności dziennika transakcji i omówić niektóre problemy z konfiguracją dziennika transakcji, które mogą powodować problemy.
Zbyt wiele VLF
Dziennik transakcji jest podzielony na porcje zwane plikami dziennika wirtualnego (VLF), dzięki czemu system zarządzania dziennikiem może łatwo śledzić, które części dziennika transakcji są dostępne do ponownego wykorzystania. Istnieje formuła określająca, ile VLF otrzymujesz podczas tworzenia dziennika transakcji, ręcznego rozwijania go lub automatycznego:
| Do 1 MB | 2 VLF, każdy w przybliżeniu 1/2 całkowitego rozmiaru |
|---|---|
| 1 MB do 64 MB | 4 VLF, każdy w przybliżeniu 1/4 całkowitego rozmiaru |
| 64 MB do 1 GB | 8 VLF, każdy w przybliżeniu 1/8 całkowitego rozmiaru |
| Ponad 1 GB | 16 VLF, każdy w przybliżeniu 1/16 całkowitego rozmiaru |
Na przykład, jeśli utworzysz dziennik transakcji o rozmiarze 8 GB, otrzymasz 16 plików VLF, z których każdy ma około 512 MB. Jeśli następnie powiększysz dziennik o kolejne 4 GB, otrzymasz dodatkowe 16 plików VLF, z których każdy ma około 256 MB, co daje w sumie 32 pliki VLF.
Uwaga:ten algorytm zmienił się nieznacznie w SQL Server 2014, aby złagodzić problemy z fragmentacją VLF – zobacz ten wpis na blogu, aby uzyskać szczegółowe informacje
Ogólną najlepszą praktyką jest ustawienie automatycznego wzrostu dziennika na wartość inną niż domyślne 10%, aby można było kontrolować pauzę, która jest wymagana podczas inicjowania nowej przestrzeni dziennika transakcji od zera. Załóżmy, że tworzysz dziennik transakcji o wielkości 256 MB i ustawiasz automatyczny wzrost na 32 MB, a następnie dziennik rośnie do stałego rozmiaru 16 GB. Biorąc pod uwagę powyższy wzór, spowoduje to, że dziennik transakcji będzie zawierał ponad 2000 VLF.
Tak wiele VLF prawdopodobnie spowoduje pewne problemy z wydajnością operacji przetwarzających dziennik transakcji (np. odzyskiwanie po awarii, czyszczenie dziennika, tworzenie kopii zapasowych dziennika, replikacja transakcyjna, przywracanie bazy danych). Ta sytuacja nazywa się fragmentacją VLF. Ogólnie rzecz biorąc, dowolna liczba VLF powyżej tysiąca będzie problematyczna i wymaga rozwiązania (najwięcej, o czym kiedykolwiek słyszałem, to 1,54 miliona VLF w dzienniku transakcji, który miał ponad 1 TB!).
Sposobem na określenie, ile masz plików VLF, jest użycie nieudokumentowanego (i całkowicie bezpiecznego) DBCC LOGINFO Komenda. Liczba wierszy danych wyjściowych to liczba plików VLF w dzienniku transakcji. Jeśli uważasz, że masz ich za dużo, sposobem na ich zmniejszenie jest:
- Zezwól dziennikowi na wyczyszczenie
- Ręcznie zmniejsz dziennik
- Powtarzaj kroki 1 i 2, aż dziennik osiągnie mały rozmiar (co może być trudne w zajętym systemie produkcyjnym)
- Ręcznie powiększaj dziennik do odpowiedniego rozmiaru, w krokach do 8 GB, więc każdy plik VLF nie jest większy niż około 0,5 GB
Więcej informacji o problemach z fragmentacją VLF i sposobie ich naprawiania można znaleźć pod adresem:
- Artykuł Microsoft KB, który zaleca zmniejszanie liczb VLF
- Czy wzrost plików dziennika może wpływać na DML?
- 8 kroków do lepszej przepustowości dziennika transakcji
Tempdb
Tempdb musi mieć swój dziennik transakcji skonfigurowany tak, jak każda inna baza danych, i może rosnąć jak każda inna baza danych. Ale ma też pewne podstępne zachowanie, które może powodować problemy.
Po ponownym uruchomieniu instancji SQL Server z jakiegokolwiek powodu dane i pliki dziennika tempdb powrócą do ostatnio ustawionego rozmiaru. Różni się to od wszystkich innych baz danych, które pozostają w swoim obecnym rozmiarze po ponownym uruchomieniu instancji.
To zachowanie oznacza, że jeśli dziennik transakcji tempdb rozrósł się do normalnego obciążenia, należy wykonać ALTER DATABASE aby ustawić rozmiar pliku dziennika, w przeciwnym razie jego rozmiar zmniejszy się po ponownym uruchomieniu instancji i będzie musiał ponownie wzrosnąć. Za każdym razem, gdy plik dziennika powiększa się lub powiększa się automatycznie, nowe miejsce musi być zainicjowane zerem, a rejestrowanie jest wstrzymywane. Jeśli więc nie zarządzasz prawidłowo rozmiarem pliku dziennika tempdb, zapłacisz karę za wydajność, ponieważ rośnie ona po każdym ponownym uruchomieniu instancji.
Zwykłe zmniejszanie się pliku dziennika
Dość często słyszę, jak ludzie mówią, jak zwykle zmniejszają dziennik transakcji bazy danych po tym, jak wyrośnie z normalnej operacji (np. cotygodniowy import danych). To nie jest dobra rzecz.
Tak jak wyjaśniłem powyżej, za każdym razem, gdy dziennik transakcji rośnie lub rośnie automatycznie, następuje przerwa, podczas której nowa część pliku dziennika jest inicjowana od zera. Jeśli regularnie zmniejszasz dziennik transakcji, ponieważ rośnie on do rozmiaru X, oznacza to, że regularnie doświadczasz problemów z wydajnością, ponieważ dziennik transakcji automatycznie powraca do rozmiaru X.
Jeśli Twój dziennik transakcji rośnie do rozmiaru X, zostaw to w spokoju! Aktywnie ustaw go na rozmiar X, zarządzając swoimi VLF, jak wyjaśniłem powyżej, i zaakceptuj rozmiar X jako rozmiar wymagany do normalnego obciążenia pracą. Większy dziennik transakcji nie stanowi problemu.
Wiele plików dziennika
Tworzenie wielu plików dziennika dla bazy danych nie zwiększa wydajności. Dodanie drugiego pliku dziennika może być jednak konieczne, jeśli w istniejącym pliku dziennika zabraknie miejsca i nie chcesz wymusić wyczyszczenia dziennika transakcji przez przełączenie na prosty model odzyskiwania i wykonanie punktu kontrolnego (ponieważ spowoduje to przerwanie kopii zapasowej dziennika łańcuch).
Często jestem pytany, czy istnieje pilny powód, aby usunąć drugi plik dziennika, czy też można go pozostawić na miejscu. Odpowiedź jest taka, że powinieneś ją usunąć tak szybko, jak to możliwe.
Chociaż drugi plik dziennika nie powoduje problemów z wydajnością obciążenia, ma jednak wpływ na odzyskiwanie po awarii. Jeśli Twoja baza danych zostanie z jakiegoś powodu zniszczona, będziesz musiał ją przywrócić od zera. Pierwszą fazą każdej sekwencji przywracania jest utworzenie plików danych i dzienników, jeśli one nie istnieją.
Możesz sprawić, że tworzenie pliku danych będzie prawie natychmiastowe, włączając natychmiastową inicjalizację pliku, która pomija inicjalizację zerową, ale nie dotyczy to plików dziennika. Oznacza to, że przywracanie musi utworzyć wszystkie pliki dziennika, które istniały podczas wykonywania pełnej kopii zapasowej (lub zostały utworzone w okresie objętym kopią dziennika transakcji) i zainicjować je zerowo. Jeśli utworzysz drugi plik dziennika i zapomnisz go ponownie usunąć, inicjowanie go podczas operacji odzyskiwania po awarii wydłuży całkowity czas przestoju. Nie jest to problem z wydajnością obciążenia, ale wpływa na dostępność serwera jako całości.
Przywracanie zrzutu bazy danych
Ostatnim problemem na mojej liście jest błąd w SQL Server. Jeśli używasz migawki bazy danych jako sposobu na szybkie przywrócenie do znanego punktu w czasie bez konieczności przywracania kopii zapasowych (tzw. przywracanie z migawki), możesz zaoszczędzić dużo czasu. Jest jednak duży minus.
Gdy baza danych powraca z migawki bazy danych, dziennik transakcji jest odtwarzany z dwoma plikami VLF 0,25 MB. Oznacza to, że będziesz musiał zwiększyć swój dziennik transakcji z powrotem do optymalnego rozmiaru i liczby VLF (lub sam się powiększy), z wszystkimi zerowymi inicjalizacją i przerwami w obciążeniu, które omówiłem wcześniej. Oczywiście nie jest to pożądane zachowanie.
Podsumowanie
Jak widać z tego posta i moich poprzednich dwóch postów, jest wiele rzeczy, które mogą prowadzić do słabej wydajności dziennika transakcji, co z kolei ma wpływ na wydajność całego obciążenia.
Jeśli potrafisz zająć się tymi wszystkimi rzeczami, będziesz mieć zdrowe dzienniki transakcji. Ale to nie koniec, ponieważ musisz upewnić się, że monitorujesz dzienniki transakcji, aby otrzymywać alerty o takich rzeczach, jak automatyczny wzrost i nadmierne opóźnienia odczytu i zapisu we/wy. Omówię, jak to zrobić w przyszłym poście.
