sys.messages zawiera pełny katalog komunikatów błędów i informacyjnych generowanych przez SQL Server.
Rola widoku sys.messages w SQL Server
sys.messages jest katalogowym widokiem systemowym aparatu Microsoft SQL Server. Zawiera definicje komunikatów używanych przez silnik podczas zgłaszania błędów, ostrzeżeń i informacji diagnostycznych. Każdy wpis opisuje tekst komunikatu przypisany do identyfikatora message_id oraz wersji językowej wskazanej przez language_id. Widok pozwala sprawdzić, jaki tekst SQL Server wiąże z konkretnym numerem komunikatu, jaki ma on poziom ważności i czy został oznaczony do zapisu w dzienniku zdarzeń systemu Windows.
Nie jest to tabela bieżących błędów ani historia wykonanych zapytań. Odczyt z sys.messages pokazuje katalog zarejestrowanych definicji, natomiast informacje o konkretnym wystąpieniu błędu trzeba ustalać na podstawie komunikatu zwróconego przez sesję, dzienników SQL Server, Extended Events lub innych mechanizmów diagnostycznych. W praktyce widok jest przydatny przy interpretowaniu numerów błędów, sprawdzaniu dostępnych tłumaczeń oraz weryfikowaniu komunikatów wykorzystywanych przez procedury administracyjne.
Kolumny opisujące komunikaty
Najważniejszym polem jest message_id, czyli numer komunikatu. Wartość language_id określa język tekstu, a kolumna text przechowuje właściwą treść. Dla jednego identyfikatora może istnieć kilka wierszy, jeżeli SQL Server ma zarejestrowany tekst w wielu językach. Dlatego zapytanie filtrujące wyłącznie po message_id może zwrócić więcej niż jeden rekord. Do rozróżnienia wpisów należy uwzględniać również identyfikator języka albo nazwę języka zwróconą przez odpowiednią funkcję systemową.
Pole severity zawiera poziom ważności przypisany komunikatowi. Nie należy utożsamiać go bezpośrednio z klasyfikacją awarii aplikacji, ponieważ znaczenie konkretnego poziomu zależy od kontekstu wykonania i rodzaju komunikatu. Kolumna is_event_logged wskazuje, czy komunikat jest przeznaczony do rejestrowania w dzienniku aplikacji systemu Windows. W katalogu występuje także informacja o źródle komunikatu, między innymi w polu text oraz metadanych związanych z językiem i identyfikatorem. Widok może zawierać zarówno komunikaty dostarczone przez Microsoft, jak i komunikaty użytkownika dodane mechanizmem SQL Server.
Zapytania diagnostyczne i własne komunikaty
Podstawową diagnostykę można rozpocząć od zapytania filtrującego katalog po numerze komunikatu, na przykład: SELECT message_id, language_id, severity, is_event_logged, text FROM sys.messages WHERE message_id = 1205;. Numer 1205 jest używany przez SQL Server w komunikacie o zakleszczeniu transakcji. Takie zapytanie pokazuje definicję tekstową komunikatu, ale nie wskaże, które sesje uczestniczyły w konkretnym zakleszczeniu ani jakie instrukcje je wywołały. Do tego potrzebne są dane z diagnostyki wykonania, w szczególności zdarzenia deadlock graph.
SQL Server umożliwia dodawanie komunikatów użytkownika za pomocą procedury systemowej sp_addmessage, a następnie ich zgłaszanie między innymi przez RAISERROR. Identyfikatory komunikatów użytkownika muszą spełniać wymagania tej procedury, a treść może mieć odpowiedniki językowe. Definicja komunikatu nie zastępuje mechanizmu obsługi wyjątków: kod aplikacji nadal powinien prawidłowo reagować na błąd, wycofywać transakcję, jeżeli jest to konieczne, oraz zapisywać kontekst operacji. Przy analizie własnych wpisów warto sprawdzić, czy komunikat został dodany w odpowiedniej bazie i czy użytkownik wykonujący zapytanie ma uprawnienia do odczytu metadanych.
Znaczenie widoku podczas diagnostyki SQL Server
Przydatną praktyką jest porównanie numeru błędu zwróconego przez SQL Server z wpisem w sys.messages, a następnie sprawdzenie wersji językowej, poziomu ważności i tekstu komunikatu. Sam tekst nie zawsze wystarcza do ustalenia przyczyny. Ten sam rodzaj problemu może wynikać z blokady, braku uprawnień, niezgodności schematu, ograniczenia integralności albo błędnych parametrów procedury. sys.messages dostarcza definicji komunikatu, lecz nie przechowuje parametrów zapytania, planu wykonania, nazw użytkowników ani historii zmian stanu serwera.
Podczas przeglądu instancji SQL Server należy uważać na różnicę między komunikatem systemowym a komunikatem zapisanym przez aplikację. Wpis w sys.messages może potwierdzić, że dany numer i tekst są obsługiwane przez silnik, ale nie dowodzi, że błąd wystąpił w konkretnym momencie. Rzetelna diagnoza wymaga zestawienia katalogu komunikatów z logiem błędów SQL Server, wynikami zapytań diagnostycznych i konfiguracją instancji. Dzięki temu można odróżnić rzeczywisty problem silnika od niepoprawnej interpretacji komunikatu przez aplikację lub skrypt administracyjny.
