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 to katalog komunikatów dostępny w aparacie katalogowym Microsoft SQL Server. Zawiera definicje komunikatów generowanych przez silnik podczas wykonywania instrukcji, obsługi obiektów bazy danych, operacji administracyjnych oraz reagowania na błędy. Wpis opisuje między innymi identyfikator komunikatu, język, poziom ważności oraz treść tekstu zwracanego użytkownikowi lub aplikacji. Dzięki temu komunikaty nie są przechowywane wyłącznie w kodzie konkretnego programu, lecz mogą być odczytywane bezpośrednio z instancji SQL Server.
Widok należy odróżnić od tabel użytkownika i od plików dziennika. Jest to systemowy obiekt katalogowy, którego zawartość zależy od zainstalowanego silnika, wersji SQL Server oraz dostępnych pakietów językowych. Wiersze dotyczą zarówno komunikatów systemowych, jak i komunikatów utworzonych przez administratora za pomocą procedury sp_addmessage. Ten sam numer komunikatu może występować w wielu wierszach, jeżeli zdefiniowano jego tłumaczenia na różne języki.
Najważniejsze kolumny i odczytywanie danych
W praktyce najczęściej analizuje się kolumnę message_id, która identyfikuje komunikat, language_id określającą język, severity przechowującą poziom ważności oraz text zawierającą treść. Kolumna is_event_logged wskazuje, czy wystąpienie komunikatu jest przeznaczone do rejestrowania w dzienniku aplikacji systemu Windows. Wpisy mogą zawierać znaczniki parametrów, takie jak %d, %s lub %I64d, które są zastępowane wartościami w chwili generowania komunikatu.
Podstawowe wyszukiwanie można wykonać instrukcją SELECT message_id, language_id, severity, is_event_logged, text FROM sys.messages WHERE message_id = 2627;. Numer 2627 jest używany przez SQL Server dla naruszenia unikatowego ograniczenia lub unikatowego indeksu. Aby znaleźć komunikaty według fragmentu treści, można zastosować warunek text LIKE N'%constraint%'. W środowisku wielojęzycznym warto filtrować także po language_id, ponieważ dla jednego numeru komunikatu mogą być zwrócone wersje językowe o tej samej funkcji, ale różnej treści.
Dostęp do katalogu podlega zwykłym zasadom widoczności metadanych SQL Server. Użytkownik może zobaczyć tylko te obiekty i informacje katalogowe, do których ma odpowiednie uprawnienia wynikające z kontekstu zabezpieczeń instancji oraz bazy danych. Przy diagnozowaniu problemu należy więc sprawdzić, czy zapytanie jest wykonywane na właściwej instancji i czy użytkownik nie korzysta z innego języka albo innej bazy niż zakładano.
Komunikaty systemowe i własne komunikaty aplikacji
sys.messages jest również wykorzystywany jako źródło własnych komunikatów przeznaczonych dla procedur składowanych, wyzwalaczy i zadań administracyjnych. Administrator może dodać komunikat przez sp_addmessage, podając numer większy niż 50000, treść, język oraz poziom ważności. Następnie taki komunikat może zostać wywołany przez RAISERROR z użyciem numeru komunikatu albo przez inne mechanizmy obsługi błędów obsługujące zarejestrowane definicje.
Przykładowy komunikat może zawierać parametr tekstowy lub liczbowy, ale liczba i typy parametrów przekazywanych podczas zgłaszania muszą odpowiadać formatowi zapisanym w definicji. W przeciwnym razie SQL Server może zgłosić kolejny błąd dotyczący niezgodnej liczby argumentów lub nieprawidłowego formatowania. Usunięcie własnego wpisu wykonuje się procedurą sp_dropmessage, przy czym należy wskazać numer oraz język komunikatu. Zmiana treści wymaga zachowania spójności wszystkich wersji językowych używanych przez aplikację.
Sam wpis w sys.messages nie oznacza, że komunikat aktualnie wystąpił. Katalog przechowuje opis i format, natomiast informację o konkretnym zdarzeniu trzeba ustalać na podstawie komunikatu zwróconego przez klienta, historii zadania SQL Server Agent, dziennika błędów SQL Server, rozszerzonych zdarzeń albo logów aplikacji. Przy analizie warto zestawić numer, poziom ważności, procedurę lub instrukcję wywołującą oraz czas zdarzenia.
Znaczenie diagnostyczne podczas obsługi SQL Server
Odczyt sys.messages pomaga ustalić, czy numer błędu jest rozpoznawany przez konkretną instancję i jak brzmi jego lokalna definicja. Jest to przydatne przy analizie problemów z ograniczeniami integralności, uprawnieniami, blokadami, transakcjami, plikami baz danych i zadaniami wykonywanymi przez SQL Server Agent. Poziom severity dostarcza informacji o klasyfikacji komunikatu, ale nie powinien być jedynym kryterium oceny awarii. Znaczenie zdarzenia zależy również od instrukcji, która je wywołała, stanu transakcji oraz reakcji aplikacji na błąd.
Podczas serwisowej diagnostyki SQL Server należy zachować oryginalny numer komunikatu i pełną treść wraz z parametrami, a następnie sprawdzić kontekst wykonania. Ten sam komunikat może pojawić się w różnych scenariuszach, a tekst może różnić się między językami. Zmiana ustawień językowych sesji nie zmienia numeru komunikatu, lecz może zmienić zwróconą treść. W przypadku komunikatów własnych trzeba dodatkowo zweryfikować, czy zostały zarejestrowane na tej instancji i w tej wersji silnika, z której korzysta problematyczna aplikacja.
Przed modyfikacją własnych komunikatów warto wykonać kopię ich definicji i sprawdzić zależności w procedurach oraz skryptach wdrożeniowych. Wpisy systemowe nie powinny być traktowane jako miejsce do ręcznej edycji. Jeżeli zapytanie zwraca niespodziewane wyniki, pierwszym krokiem jest potwierdzenie nazwy instancji, wersji SQL Server, bazy kontekstu, języka sesji i uprawnień konta. Dopiero po takiej weryfikacji można wiarygodnie ocenić, czy problem dotyczy samego komunikatu, mechanizmu jego rejestrowania, czy kodu wykonującego operację.
