Proaktywne kontrole kondycji serwera SQL, część 4:ERRORLOG

Tyle można powiedzieć o historii i znaczeniu. Historia kraju, cywilizacji, każdego z nas. Uwielbiam cytaty i lubię ten od Teddy'ego Roosevelta (fajny facet):

Dlaczego na blogu poświęconym SQL Server piszę poetycko (lub próbuję) o historii? Ponieważ historia w SQL Server też jest ważna. Gdy w programie SQL Server występuje problem z wydajnością, idealnym rozwiązaniem jest rozwiązanie go na żywo, ale w niektórych przypadkach informacje historyczne mogą stanowić dymiącą broń lub przynajmniej punkt wyjścia. Świetnym źródłem informacji historycznych w SQL Server jest ERRORLOG. Wspomniałem w moim oryginalnym poście, Performance Issues:The First Encounter, że ERRORLOG był dla mnie refleksją. Już nie. Podczas audytów klientów zawsze rejestrujemy ERRORLOGI i chociaż jesteśmy powiadamiani o wszelkich alertach o wysokim stopniu ważności (które są zapisywane w dzienniku), nie jest niczym niezwykłym znalezienie innych interesujących informacji w dzienniku. Przygotowujemy się na przyszłość, korzystając z historycznych informacji zawartych w logach; informacje mogą nam pomóc rozwiązać problem lub potencjalny problem, zanim stanie się katastrofalny.

Wyświetlanie ERRORLOG

Na początek omówimy kilka opcji przeglądania ERROLOGU. Jeśli mam połączenie z instancją, zwykle przechodzę do niej przez SSMS (Zarządzanie | Dzienniki SQL Server, kliknij prawym przyciskiem myszy dziennik i wybierz Wyświetl dziennik SQL Server). Z tego okna mogę po prostu przewijać dziennik lub użyć opcji Filtruj lub Szukaj, aby zawęzić zestaw wyników. Mogę również wyświetlić wiele plików, wybierając je w panelu po lewej stronie.

Jeśli patrzę na dane przechwycone w jednym z naszych audytów zdrowia, po prostu otworzę pliki dziennika w edytorze tekstu i przejrzę je (mam też możliwość wejścia do przeglądarki i ich załadowania). Pliki dziennika znajdują się w folderze dziennika (domyślna lokalizacja:C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log), jeśli kiedykolwiek chciałem je przeglądać na serwerze. Wielu z was może preferować przeglądanie i/lub przeszukiwanie dziennika za pomocą nieudokumentowanej procedury sp_readerrorlog lub rozszerzonej procedury składowanej xp_readerrorlog.

I na koniec, jeśli wszyscy jesteście w PowerShell, jest to również opcja odczytywania dziennika w ten sposób (patrz ten post:Użyj PowerShell do analizowania dzienników błędów SQL Server 2012). Metoda zależy od Ciebie – wykorzystaj to, co wiesz i co działa dla Ciebie – to treść jest naprawdę ważna. I pamiętaj, że czasami będziesz musiał po prostu przeczytać dziennik, aby zrozumieć kolejność zdarzeń, a czasami możesz szukać konkretnego błędu lub informacji.

Co zawiera ERRORLOG?

Jakie więc informacje możemy znaleźć w ERRORLOGU poza błędami? Poniżej wymieniłem wiele przedmiotów, które uważam za najbardziej przydatne. Pamiętaj, że nie jest to wyczerpująca lista (i jestem pewien, że wielu z was będzie mieć sugestie, co można dodać – zachęcam do napisania komentarza, a ja mogę to zaktualizować!), ale znowu jestem tym szukam pierwszego kiedy aktywnie patrzę na instancję.

• Czy serwer jest fizyczny czy wirtualny (poszukaj wpisu producenta systemu)
• Flagi śledzenia włączone podczas uruchamiania
  • We wpisie parametrów uruchamiania Rejestru, jeśli przewiniesz do końca w prawo, zobaczysz, czy włączone są jakiekolwiek flagi śledzenia:
    
    Flagi śledzenia włączone podczas uruchamiania
• Flagi śledzenia włączone lub wyłączone po uruchomieniu instancji
  • Jeśli użytkownicy (lub aplikacja) włączą lub wyłączą flagę śledzenia za pomocą DBCC TRACEON lub DBCC TRACEOFF, w dzienniku pojawi się wpis
• Liczba rdzeni i gniazd wykrytych przez SQL Server
  • Zawsze lubię sprawdzać, czy SQL Server widzi cały dostępny sprzęt – a jeśli nie, to jest to czerwona flaga do dalszego zbadania. Dobrym przykładem jest post Jonathana Performance Problems with SQL Server 0212 Enterprise Edition Under CAL Licensing oraz post Glenna Równoważenie dostępnych licencji SQL Server Core na wszystkich węzłach NUMA, który zawiera również przydatny TSQL do przeszukiwania dziennika.
  • Zauważ, że tekst tego wpisu różni się w zależności od wersji SQL Server.
• Ilość pamięci wykryta przez SQL Server
  • Ponownie chcę sprawdzić, czy SQL Server widzi całą dostępną pamięć.
• Potwierdzenie, że zablokowane strony w pamięci (LPIM) są włączone
  • Gdy ta opcja jest włączona w zasadach bezpieczeństwa systemu Windows, możesz potwierdzić, że jest włączona, wyszukując w dzienniku komunikat „Używanie zablokowanych stron w menedżerze pamięci”.
  • Pamiętaj, że jeśli używasz Trace Flag 834, wtedy komunikat nie powie o zablokowanych stronach, powie, że duże strony są używane w puli buforów.
• Wersja CLR w użyciu
• Powodzenie lub niepowodzenie rejestracji głównej nazwy usługi (SPN)
• Ile czasu zajmuje udostępnienie bazy danych w trybie online
  • Dziennik rejestruje, kiedy baza danych jest uruchamiana i kiedy jest online – sprawdzam, czy jakakolwiek baza danych nie zajmuje zbyt dużo czasu.
• Status punktów końcowych Service Broker i Database Mirroring – ważne, jeśli używasz którejkolwiek funkcji
• Potwierdzenie, że natychmiastowa inicjalizacja pliku (IFI) jest włączona*
  • Domyślnie te informacje nie są rejestrowane, ale jeśli włączysz opcję Trace Flag 3004 (i 3605, aby wymusić wyjście do dziennika), podczas tworzenia lub powiększania pliku danych zobaczysz w dzienniku komunikaty wskazujące, czy IFI jest używany, czy nie.
• Stan śladów SQL
  • Kiedy uruchamiasz lub zatrzymujesz śledzenie SQL, jest on rejestrowany i sprawdzam, czy istnieją jakiekolwiek ślady poza śladem domyślnym (czasowo lub długoterminowo). Jeśli używasz narzędzia do monitorowania innej firmy, takiego jak Performance Advisor programu SQL Sentry, możesz zobaczyć aktywny śledzenie, który jest zawsze uruchomiony, ale przechwytuje tylko określone zdarzenia, lub możesz zobaczyć rozpoczęcie śledzenia, uruchamiane przez krótki czas, a następnie zatrzymać. Nie przejmuję się jednym lub dwoma dodatkowymi śladami, chyba że rejestrują wiele zdarzeń, ale zdecydowanie zwracam uwagę, gdy uruchomionych jest wiele śladów.
• Ostatni raz, kiedy CHECKDB został ukończony
  • Ten komunikat jest często źle rozumiany przez ludzi — po uruchomieniu instancja odczytuje stronę startową dla każdej bazy danych i zauważa, kiedy CHECKDB został ostatnio uruchomiony pomyślnie. Większość ludzi nie czyta całej wiadomości:
    
    Data ostatniego pomyślnego zakończenia DBCC CHECKDB

    Data zakończenia CHECKDB to 11 listopada 2012 r., ale data ERRORLOG to 7 lipca 2015 r. Ważne jest, aby zrozumieć, że SQL Server nie uruchom CHECKDB z bazami danych podczas uruchamiania, sprawdza wartość dbcclastknowngood na stronie rozruchowej (aby zobaczyć, kiedy zostanie zaktualizowana, sprawdź mój post Co sprawdza aktualizację dbcclastknowngood. Ponadto, jeśli DBCC CHECKDB nigdy nie był uruchamiany w odniesieniu do bazy danych, nie ma wpisu pojawi się w bazie danych tutaj.

• Ukończenie SPRAWDZANIA DB
  • Gdy CHECKDB jest uruchamiany na bazie danych, dane wyjściowe są zapisywane w dzienniku.
• Zmiany w ustawieniach instancji
  • Jeśli zmienisz ustawienia na poziomie instancji (np. maksymalna pamięć serwera, próg kosztów dla równoległości) za pomocą sp_configure lub interfejsu użytkownika (pamiętaj, że nie rejestruje kto zmieniłem to).

• Zmiany w ustawieniach bazy danych
  • Czy ktoś włączył AUTO_SHRINK? Zmień opcję ODZYSKIWANIE na PROSTE, a następnie z powrotem na FULL? Znajdziesz to tutaj.
• Zmiany stanu bazy danych
  • Jeśli ktoś korzysta z bazy danych w trybie OFFLINE (lub przenosi ją do trybu ONLINE), zostaje to zarejestrowane.
• Informacje o zakleszczeniu*
  • Jeśli chcesz przechwycić informacje o zakleszczeniu, nie uruchamiaj śledzenia, i używasz programu SQL Server 2005 do 2008R2, użyj flagi śledzenia 1222, aby zapisać informacje o zakleszczeniu w dzienniku w formacie XML. Osoby korzystające z programu SQL Server 2000 i starszego mogą skorzystać z flagi śledzenia 1204 (ta flaga śledzenia jest również dostępna w programie SQL Server 2005+, ale podaje minimalną ilość informacji). Jeśli używasz programu SQL Server 2012 lub nowszego, nie jest to potrzebne, ponieważ sesja zdarzeń system_health przechwytuje te informacje (i są tam również w latach 2008 i 20082, ale musisz pobrać je z bufora pierścienia w porównaniu z celem pliku_zdarzenia).
• Wiadomości FlushCache
  • Jeśli pamięć podręczna jest opróżniana przez SQL Server, ponieważ proces punktu kontrolnego przekracza interwał odzyskiwania bazy danych, w dzienniku zobaczysz zestaw komunikatów FlushCache (więcej informacji znajdziesz w tym poście Boba Dorra). Nie myl tych wiadomości z tymi, które pojawiają się po uruchomieniu DBCC FREEPROCCACHE lub DBCC FREESYSTEMCACHE:
    
    Komunikat po uruchomieniu DBCC FREEPROCCACHE lub DBCC FREESYSTEMCACHE

• Wiadomości o wyładowaniu AppDomain
  • Dziennik odnotowuje również, kiedy tworzone są domeny aplikacji, a zobaczysz je tylko wtedy, gdy używasz CLR. Jeśli widzę komunikaty o wyładowaniu AppDomain z powodu obciążenia pamięci, jest to coś, co należy dokładniej zbadać.

W dzienniku znajdują się inne przydatne informacje, takie jak używany tryb uwierzytelniania, czy włączone jest dedykowane połączenie administratora (DAC) itp., ale mogę je również uzyskać z sys.configuration i sprawdzam je z liniami bazowymi instancji Omówiłem wcześniej (Proaktywne kontrole kondycji serwera SQL, część 3:ustawienia instancji i bazy danych).

Czego nie ma w ERROLOGU, czego możesz się spodziewać?

Na razie jest to krótka lista, ponieważ przypuszczam, że niektórzy z was mogli znaleźć inne rzeczy, o których myśleliście, że znajdą się w dzienniku, ale nie były…

• Dodawanie lub usuwanie plików bazy danych lub grup plików
• Rozpoczynanie lub zatrzymywanie sesji rozszerzonych zdarzeń
  • Jeśli jednak wdrożysz wyzwalacz DDL lub powiadomienie o zdarzeniu na poziomie serwera, możesz rejestrować te informacje. Zobacz post Jonathana, Rejestrowanie zmian rozszerzonych zdarzeń w ERRORLOG, aby uzyskać więcej szczegółów.
• Uruchomienie DBCC DROPCLEANBUFFERS pojawia się w ERRORLOG

Zarządzanie dziennikiem

Należy pamiętać, że domyślnie program SQL Server przechowuje tylko ostatnie sześć (6) plików dziennika (oprócz bieżącego pliku), a plik dziennika jest przewijany przy każdym ponownym uruchomieniu programu SQL Server. W rezultacie czasami możesz mieć bardzo duże pliki dziennika, których otwarcie zajmuje trochę czasu i jest trudne do przekopania się. Z drugiej strony, jeśli napotkasz przypadek, w którym instancja zostanie kilka razy ponownie uruchomiona, możesz utracić ważne informacje. Zaleca się zwiększenie liczby zachowywanych plików do wyższej wartości (np. 30) i utworzenie zadania Agenta, aby raz w tygodniu przewijać plik za pomocą sp_cycle_errorlog.

Oprócz zarządzania plikami możesz wpływać na to, jakie informacje są zapisywane w dzienniku. Jednym z najczęstszych wpisów, które tworzą bałagan w ERRORLOGu, jest pomyślna kopia zapasowa:

Utworzono kopię zapasową pomyślnie

Jeśli masz instancję z licznymi bazami danych, a kopie zapasowe dziennika transakcji są wykonywane z dowolną regularnością (np. co 15 minut), zobaczysz, że dziennik szybko zapełnia się wiadomościami, co utrudnia znalezienie prawdziwego problemu. Na szczęście możesz użyć flagi śledzenia 3226, aby wyłączyć komunikaty o udanych kopiach zapasowych (błędy będą nadal pojawiać się w dzienniku, a wszystkie wpisy będą nadal istnieć w msdb).

Kolejny zestaw komunikatów, które zaśmiecają dziennik, to komunikaty o udanym logowaniu. To jest opcja, którą konfigurujesz dla instancji na karcie Zabezpieczenia:

Opcja bezpieczeństwa do rejestrowania udanych i/lub nieudanych logowań

Jeśli logujesz udane logowania lub nieudane i udane logowania, możesz mieć bardzo duże pliki dziennika, nawet jeśli będziesz je codziennie przewijać (będzie to zależeć od liczby podłączonych użytkowników). Zalecam przechwytywanie tylko nieudanych logowań. W przypadku firm, które wymagają rejestrowania udanych logowań, rozważ użycie funkcji audytu, dodanej w SQL Server 2008. Uwaga dodatkowa:jeśli zmienisz ustawienie audytu logowania, nie będzie ono obowiązywać do czasu ponownego uruchomienia instancji.

Nie lekceważ ERRORLOG

Jak widać, w ERRORLOG znajduje się kilka świetnych informacji, które można wykorzystać nie tylko podczas rozwiązywania problemów z wydajnością lub badania błędów, ale także podczas aktywnego monitorowania instancji. Możesz znaleźć w dzienniku informacje, których nie znajdziesz nigdzie indziej; upewnij się, że sprawdzasz to regularnie i nie zostawiasz tego po namyśle.

Zobacz inne części z tej serii:

• Część 1:Miejsce na dysku
• Część 2:Konserwacja
• Część 3:Ustawienia instancji i bazy danych