Kod błędu SQL Server

Kod błędu SQL Server to numeryczny identyfikator problemu, którego opis można odnaleźć w widoku sys.messages.

Numericalny identyfikator komunikatu w SQL Server

Kod błędu SQL Server jest numerem przypisanym do konkretnego komunikatu diagnostycznego. W dokumentacji i narzędziach administracyjnych taki numer jest często określany jako numer błędu albo error number. Sam numer nie opisuje jeszcze przyczyny problemu. Znaczenie wynika z połączenia numeru z tekstem komunikatu, poziomem ważności, stanem błędu oraz miejscem jego wystąpienia. Te informacje pozwalają odróżnić błąd składni zapytania od problemu z obiektem, uprawnieniami, połączeniem lub transakcją.

Definicje komunikatów zainstalowanych w silniku można odczytać z widoku katalogowego sys.messages. Widok ten zawiera między innymi kolumny message_id, language_id, severity, is_event_logged oraz text. Kolumna message_id identyfikuje komunikat, a language_id wskazuje język jego wersji. Ten sam numer może więc występować w wielu wierszach, jeżeli SQL Server przechowuje tekst komunikatu w kilku językach.

Jak odczytać opis i kontekst błędu

Wyszukanie numeru w sys.messages pozwala sprawdzić treść komunikatu oraz domyślny poziom ważności przypisany do danej definicji. Przykładowe zapytanie może filtrować widok po kolumnie message_id i wyświetlać language_id, severity oraz text. Należy pamiętać, że tekst komunikatu może zawierać znaczniki zastępowane podczas działania silnika, takie jak nazwa obiektu, nazwa kolumny, identyfikator procesu lub fragment dodatkowych informacji. Dlatego opis z widoku katalogowego może być szablonem, a nie pełnym komunikatem widocznym w aplikacji.

W praktyce diagnostycznej trzeba odczytać również dane towarzyszące. W procedurze obsługi błędów języka T-SQL dostępne są funkcje ERROR_NUMBER(), ERROR_SEVERITY(), ERROR_STATE(), ERROR_PROCEDURE(), ERROR_LINE() i ERROR_MESSAGE(). Zwracają one odpowiednio numer, poziom ważności, stan, nazwę procedury, numer wiersza oraz sformatowany tekst błędu, ale ich użyteczność dotyczy przede wszystkim bloku CATCH po przechwyceniu wyjątku przez konstrukcję TRY...CATCH. Sam numer błędu bez informacji o instrukcji i kontekście wykonania często nie wystarcza do odtworzenia problemu.

Różnica między numerem błędu a poziomem ważności

Numer błędu nie jest tym samym co poziom ważności. Numer wskazuje konkretny komunikat, natomiast poziom ważności opisuje wpływ sytuacji na wykonanie instrukcji, sesję lub działanie silnika. SQL Server używa poziomów od 0 do 25. Poziomy 0–10 przekazują informacje lub ostrzeżenia, poziomy 11–16 zwykle wskazują błędy możliwe do skorygowania przez użytkownika lub aplikację, a wyższe poziomy sygnalizują poważniejsze problemy środowiska wykonawczego. Poziom 20 lub wyższy może spowodować zakończenie połączenia, dlatego taki komunikat wymaga szczególnej analizy logu oraz stanu sesji.

Znaczenie ma także wartość state. Jest to niewielki identyfikator wskazujący wariant lub miejsce wygenerowania danego błędu. Dwa komunikaty o tym samym numerze mogą mieć różny stan, jeżeli silnik wykrył problem w odmiennych ścieżkach wykonania. Przy analizie należy zachować pełną parę numeru i stanu, a następnie porównać ją z tekstem komunikatu oraz nazwą procedury i numerem wiersza. Nie należy automatycznie zakładać, że każdy kod wymaga tej samej naprawy tylko dlatego, że numer jest identyczny.

Wykorzystanie kodu podczas analizy awarii

Samodzielne sprawdzanie kodu błędu powinno rozpocząć się od zapisania całego komunikatu, a nie tylko liczby widocznej w interfejsie aplikacji. Ważne są również czas wystąpienia, nazwa bazy danych, polecenie lub procedura, typ operacji oraz informacja o tym, czy błąd powtarza się dla wszystkich danych, czy tylko dla określonego przypadku. Dla błędów związanych z obiektami warto zweryfikować ich nazwę i schemat. Dla błędów uprawnień należy rozdzielić tożsamość logowania od użytkownika bazy danych i sprawdzić wymagane uprawnienia do konkretnego obiektu.

Jeżeli komunikat został wygenerowany przez kod T-SQL, trzeba ustalić, czy pochodzi z silnika, czy został celowo zwrócony przez aplikację za pomocą THROW albo RAISERROR. Polecenie THROW może ponownie zgłosić przechwycony wyjątek, zachowując jego informacje, natomiast RAISERROR służy między innymi do generowania komunikatów o określonym numerze, poziomie ważności i stanie. Dodatkowe komunikaty użytkownika mogą być rejestrowane w katalogu komunikatów za pomocą procedury systemowej sp_addmessage. W efekcie ten sam mechanizm wyszukiwania w sys.messages może obejmować zarówno komunikaty systemowe, jak i komunikaty zdefiniowane przez administratora.

W przypadku problemu widocznego na laptopie lub komputerze PC kod SQL Server jest zwykle tylko jednym z elementów łańcucha diagnostycznego. Aplikacja może błędnie interpretować numer, ukrywać tekst komunikatu albo traktować każdy błąd jako awarię połączenia. Rzetelna ocena wymaga porównania logu aplikacji z pełną odpowiedzią SQL Server, dziennikiem zdarzeń aplikacji oraz stanem operacji, która została przerwana.