Błędy i diagnostyka

Błędy i diagnostyka to zbiorcze określenie mechanizmów SQL Server umożliwiających identyfikację i analizę przyczyn awarii.

Zakres błędów raportowanych przez SQL Server

Błędy i diagnostyka w SQL Server obejmują mechanizmy, które pozwalają ustalić, czy problem dotyczy składni zapytania, uprawnień, połączenia, zasobów serwera, struktury bazy danych, blokowania transakcji czy uszkodzenia stron danych. Informacja o błędzie może zawierać numer komunikatu, poziom ważności, stan, nazwę procedury lub wyzwalacza oraz numer wiersza, w którym wystąpił problem. Sam tekst komunikatu opisuje objaw, ale nie zawsze wskazuje pełną przyczynę, dlatego powinien być analizowany razem z kontekstem wykonania zapytania i stanem instancji.

SQL Server przypisuje komunikatom poziomy ważności od 0 do 25. Poziomy 0–10 informują o komunikatach, które nie wskazują błędu wymagającego obsługi wyjątku, poziomy 11–16 zwykle dotyczą problemów możliwych do naprawienia przez użytkownika lub administratora, a poziomy 17–19 oznaczają problemy z zasobami albo środowiskiem wymagające większej uwagi. Poziomy 20–25 wskazują błędy krytyczne; mogą powodować zamknięcie połączenia, a w niektórych sytuacjach wymagają sprawdzenia spójności bazy i stanu systemu.

Obsługa wyjątków w procedurach i zapytaniach

W kodzie T-SQL podstawowym mechanizmem obsługi błędów wykonawczych jest konstrukcja TRY...CATCH. Instrukcje mogące wygenerować wyjątek umieszcza się w bloku TRY, a działania diagnostyczne lub obsługę sytuacji awaryjnej w bloku CATCH. W bloku CATCH dostępne są funkcje ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_SEVERITY(), ERROR_STATE(), ERROR_PROCEDURE() i ERROR_LINE(). Pozwalają one zapisać nie tylko opis problemu, lecz także jego numer, poziom, procedurę i numer wiersza.

Obsługa błędu powinna uwzględniać stan transakcji. Funkcja XACT_STATE() zwraca wartość 1, gdy aktywna transakcja może zostać zatwierdzona, -1, gdy jest niezatwierdzona i możliwe jest wyłącznie jej wycofanie, oraz 0, gdy nie ma aktywnej transakcji. W bloku CATCH często wykonuje się ROLLBACK dla transakcji w stanie niezatwierdzalnym, a następnie przekazuje informację o błędzie za pomocą THROW. Rozróżnienie tych stanów zapobiega pozostawieniu otwartej transakcji, która mogłaby utrzymywać blokady i wpływać na kolejne operacje.

Źródła informacji o stanie instancji

SQL Server zapisuje część zdarzeń w dzienniku błędów instancji. Można go przeglądać w SQL Server Management Studio albo odczytywać za pomocą procedury sp_readerrorlog. Dziennik może zawierać informacje o uruchomieniu i zatrzymaniu usług, problemach z otwieraniem plików baz danych, błędach odzyskiwania, nieudanych próbach logowania oraz zdarzeniach związanych z dostępem do zasobów. Czas wystąpienia komunikatu jest istotny, ponieważ pozwala porównać go z historią restartów, zmianami konfiguracji i logami aplikacji.

Do obserwacji aktywnego obciążenia służą widoki dynamicznego zarządzania, między innymi sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_waiting_tasks i sys.dm_tran_locks. sys.dm_exec_requests pokazuje wykonywane żądania, ich status oraz czas trwania, natomiast sys.dm_os_waiting_tasks pomaga ustalić, na jaki zasób czeka konkretne zadanie. sys.dm_tran_locks przedstawia blokady związane z transakcjami. Przy analizie wydajności można połączyć te widoki z funkcją sys.dm_exec_sql_text, aby ustalić tekst zapytania odpowiadającego za obciążenie lub blokowanie.

Diagnostyka spójności i rejestrowanie zdarzeń

DBCC CHECKDB służy do sprawdzania logicznej i fizycznej spójności obiektów bazy danych. Polecenie analizuje między innymi alokację stron, powiązania indeksów oraz zgodność struktur systemowych. Wynik może wskazać błędy spójności wraz z poziomem ich ważności i zaleceniami dotyczącymi dalszego postępowania. Opcje naprawcze DBCC CHECKDB mogą prowadzić do utraty danych, dlatego podstawową metodą odzyskania poprawnego stanu jest przywrócenie bazy z prawidłowej kopii zapasowej, jeśli taka kopia istnieje.

Extended Events umożliwia definiowanie sesji zbierających wybrane zdarzenia diagnostyczne, na przykład błędy, deadlocki, przekroczenia czasu wykonania lub określone operacje zapytań. W porównaniu z analizą pojedynczego komunikatu daje możliwość obserwowania sekwencji zdarzeń wraz z czasem, identyfikatorem sesji, nazwą bazy i tekstem polecenia. W SQL Server dostępny jest także Query Store, który przechowuje historię zapytań, planów wykonania i statystyk ich działania, dzięki czemu można porównać zachowanie zapytania przed i po zmianie planu.