Katalog błędów SQL Server w widoku sys.messages zawiera pełną listę kodów błędów wraz z ich opisami.
Rola widoku sys.messages w SQL Server
sys.messages jest katalogowym widokiem SQL Server zawierającym definicje komunikatów błędów i ostrzeżeń rozpoznawanych przez silnik. Widok znajduje się w bazie systemowej master, dlatego pełne odwołanie ma postać master.sys.messages. Katalog obejmuje komunikaty systemowe dostarczane wraz z SQL Server oraz komunikaty dodane przez administratora za pomocą procedury sp_addmessage. Sam widok opisuje treść i właściwości komunikatu; nie jest tabelą rejestrującą wszystkie wystąpienia błędów w konkretnej bazie ani historią awarii.
Wynik zapytania może zawierać kilka wierszy dla tego samego numeru błędu, ponieważ SQL Server przechowuje osobny wpis dla każdego języka. Podstawowa identyfikacja komunikatu wymaga więc uwzględnienia kolumn message_id oraz language_id. Przykładowe wyszukiwanie komunikatów o numerach od 50000 może wyglądać następująco: SELECT message_id, language_id, severity, is_event_logged, text FROM master.sys.messages WHERE message_id >= 50000 ORDER BY message_id, language_id;. Takie zapytanie pokazuje definicje komunikatów użytkownika, o ile zostały zapisane w katalogu bieżącej instancji.
Kolumny opisujące komunikat i język
Kolumna message_id przechowuje numer komunikatu, a language_id identyfikuje język jego treści. Kolumna severity określa poziom ważności przypisany do komunikatu. Wartość is_event_logged informuje, czy użycie danego komunikatu jest przeznaczone do rejestrowania w dzienniku aplikacji systemu Windows. Tekst komunikatu znajduje się w kolumnie text. Ponieważ tekst może zawierać parametry podstawiane podczas zgłaszania błędu, sama definicja w katalogu może zawierać znaczniki formatowania, a końcowy komunikat zależy od przekazanych argumentów.
Do filtrowania katalogu warto używać jednoznacznych warunków. Przykładowo WHERE message_id = 2627 AND language_id = 1033 pozwala odszukać angielską wersję komunikatu o naruszeniu ograniczenia unikatowości, natomiast WHERE text LIKE N'%deadlock%' wyszukuje wpisy, których treść zawiera określone słowo. Przy analizie komunikatu pochodzącego z logu należy sprawdzić zarówno numer błędu, jak i poziom ważności oraz język sesji. Ten sam numer może mieć różne tłumaczenie, ale numer i przypisana definicja nadal pochodzą z katalogu danej instancji SQL Server.
W praktyce nie należy zakładać, że każdy numer widoczny w logu musi mieć odpowiadający mu wpis w sys.messages. Niektóre komunikaty są tworzone dynamicznie przez aplikację albo zgłaszane z tekstem przekazanym bezpośrednio przez kod. Z tego powodu diagnostykę należy opierać na pełnym komunikacie, numerze błędu, stanie, procedurze, numerze wiersza i czasie wystąpienia, jeżeli te informacje są dostępne. Samo znalezienie podobnego tekstu w katalogu nie potwierdza jeszcze przyczyny problemu.
Komunikaty użytkownika, RAISERROR i ograniczenia interpretacji
Komunikaty własne można zarejestrować w katalogu za pomocą sp_addmessage. Dla komunikatów użytkownika stosuje się numery co najmniej 50001, ponieważ niższe numery są przeznaczone dla komunikatów systemowych. Przykładowa definicja może zostać dodana poleceniem EXEC sys.sp_addmessage @msgnum = 50001, @severity = 16, @msgtext = N'Nieprawidłowy identyfikator urządzenia: %s';. Jeżeli komunikat ma być dostępny w wielu językach, dla tego samego numeru dodaje się odrębne wersje językowe. SQL Server wymaga także odpowiednich uprawnień do zarządzania komunikatami w bazie master.
Procedura RAISERROR może odwołać się do komunikatu z katalogu przez jego numer, na przykład RAISERROR(50001, 16, 1, N'ABC-123'). Pierwszy argument wskazuje message_id, drugi jest poziomem ważności używanym w zgłoszeniu, trzeci oznacza stan aplikacyjny, a kolejny argument zastępuje parametr %s. Przy takiej analizie trzeba odróżnić poziom zapisany w sys.messages od parametrów konkretnego wywołania. Zmiana definicji komunikatu może wpłynąć na treść następnych błędów, ale nie zmienia historycznych wpisów w dziennikach.
THROW działa według innego modelu niż RAISERROR: może ponownie zgłaszać przechwycony wyjątek albo tworzyć nowy wyjątek z numerem błędu, stanem i tekstem podanym bezpośrednio w instrukcji. Dlatego kod używający THROW nie musi mieć własnego tekstu w sys.messages. Przy porównywaniu zachowania procedur składowanych należy sprawdzić, czy aplikacja korzysta z RAISERROR, THROW, błędu generowanego przez silnik, czy własnego mechanizmu logowania. Te źródła mogą różnić się obsługą transakcji, formatowaniem, poziomem ważności i informacjami zwracanymi klientowi.
Wykorzystanie katalogu podczas diagnostyki instancji
Podczas diagnostyki SQL Server widok sys.messages pomaga ustalić, czy numer błędu ma zdefiniowaną treść, jaki poziom ważności przypisano komunikatowi oraz czy dostępna jest wersja językowa używana przez daną sesję. Przydatne jest zestawienie katalogu z logiem SQL Server, wynikami Extended Events albo komunikatami zwróconymi przez sterownik aplikacyjny. Jeżeli log zawiera numer, którego nie ma w katalogu, należy zweryfikować instancję, z której pochodzi wpis, oraz sprawdzić, czy numer nie został wygenerowany przez aplikację lub bibliotekę kliencką.
Nie wolno traktować poziomu ważności jako samodzielnej diagnozy. Wysoki poziom może wskazywać na błąd wpływający na działanie procesu, lecz rzeczywista przyczyna zależy od kontekstu: instrukcji SQL, obiektu, transakcji, blokad, uprawnień, konfiguracji i danych wejściowych. Dla powtarzających się błędów warto zapisać numer komunikatu, język, tekst po podstawieniu parametrów, nazwę bazy, sesję oraz moment wystąpienia. Następnie można porównać wpisy między środowiskami, ponieważ komunikaty użytkownika mogą być dodane tylko na wybranej instancji.
Przy serwisowaniu komputera lub środowiska, na którym działa narzędzie administracyjne SQL Server, diagnostyka obejmuje również sprawdzenie lokalnych logów, sterowników, połączenia z właściwą instancją i zgodności używanego klienta z konfiguracją serwera. Katalog sys.messages pomaga wtedy poprawnie odczytać numer i opis błędu, ale nie zastępuje analizy planu wykonania, dziennika SQL Server ani konfiguracji samej bazy. Każdą zmianę komunikatów użytkownika należy dokumentować, ponieważ wpływa ona na treść błędów obserwowanych przez procedury, aplikacje i operatorów.
