error_reported to zdarzenie rozszerzone SQL Server rejestrujące szczegóły każdego błędu zgłoszonego przez silnik bazodanowy.
Rola zdarzenia error_reported w SQL Server
error_reported jest zdarzeniem rozszerzonym dostępnym w Microsoft SQL Server. Silnik generuje je wtedy, gdy zgłasza błąd, ostrzeżenie lub komunikat związany z wykonywaną operacją. Zdarzenie może dotyczyć między innymi niepoprawnego zapytania, braku obiektu, naruszenia ograniczenia, problemu z uprawnieniami, błędu konwersji danych albo nieprawidłowego użycia funkcji języka Transact-SQL. Rejestracja tego zdarzenia nie oznacza, że samo rozszerzone zdarzenie naprawia problem. Jego zadaniem jest dostarczenie informacji diagnostycznej o komunikacie wygenerowanym przez silnik.
W przeciwieństwie do zwykłego odczytu komunikatu wyświetlonego w aplikacji, sesja Extended Events może zapisać zdarzenie razem z kontekstem wykonania. Pozwala to powiązać błąd z instrukcją, połączeniem, bazą danych, sesją lub innymi akcjami dołączonymi do konfiguracji sesji. Znaczenie konkretnego wpisu zależy od jego pól, poziomu ważności, numeru błędu, treści komunikatu oraz momentu wystąpienia. Sam fakt obecności wpisu error_reported nie jest jeszcze dowodem awarii całego serwera SQL Server.
Pola opisujące komunikat i jego źródło
W zdarzeniu error_reported SQL Server udostępnia między innymi numer błędu, poziom ważności, stan komunikatu, tekst błędu oraz identyfikator bazy danych. Numer błędu pozwala odróżnić przyczyny, które mogą mieć podobny opis w interfejsie aplikacji. Poziom ważności, określany jako severity, wskazuje wagę komunikatu z perspektywy silnika. Niski poziom może oznaczać ostrzeżenie lub problem dotyczący pojedynczego polecenia, natomiast wyższy poziom wymaga analizy wpływu na sesję, transakcję albo proces serwera.
Wartość stanu błędu, czyli state, jest dodatkowym numerem używanym przez SQL Server do rozróżniania wariantów tego samego numeru błędu. Treść komunikatu może zawierać nazwy obiektów, wartości parametrów lub fragment informacji o wykonanej operacji, dlatego powinna być analizowana razem z numerem błędu, a nie zamiast niego. Do sesji można również dołączyć akcje, takie jak tekst wykonywanego polecenia, identyfikator sesji, nazwa aplikacji, nazwa hosta, użytkownik lub adres planu wykonania. Akcje zwiększają wartość diagnostyczną wpisu, ale mogą też zwiększyć rozmiar pliku śledzenia i narzut rejestrowania.
Filtrowanie i interpretacja zapisów Extended Events
Sesję zawierającą error_reported można ograniczyć predykatami, aby zapisywać tylko wybrane numery błędów, poziomy ważności, bazy danych albo inne dostępne właściwości zdarzenia. Filtrowanie jest istotne, ponieważ SQL Server może generować wiele komunikatów, które nie wskazują na awarię usługi. W praktyce analizuje się przede wszystkim powtarzalność błędu, jego kolejność względem innych zdarzeń, czas wystąpienia oraz to, czy dotyczy jednej sesji, jednej aplikacji czy wielu połączeń.
Przykładowo wielokrotnie powtarzający się błąd składni może wskazywać na wadliwie budowane zapytanie po stronie programu, a błąd dotyczący obiektu może wynikać z użycia niewłaściwej bazy lub schematu. Komunikat o naruszeniu ograniczenia integralności może być skutkiem danych wejściowych, a nie uszkodzenia silnika. Z kolei wpis o wysokim poziomie ważności wymaga sprawdzenia, czy towarzyszyły mu przerwane połączenia, wycofanie transakcji, błędy systemowe albo inne zdarzenia wskazujące na problem infrastrukturalny. Pojedynczego wpisu nie należy automatycznie utożsamiać z awarią sprzętu.
Znaczenie error_reported przy analizie problemów z SQL Server
Podczas diagnostyki należy zestawić dane z error_reported z logiem SQL Server, dziennikiem aplikacji oraz informacjami o czasie wykonywania konkretnej operacji. Pomocne jest ustalenie, czy błąd występuje przed zmianą danych, w jej trakcie, czy po zakończeniu transakcji. Należy również sprawdzić, czy aplikacja prawidłowo obsługuje kod błędu i czy nie ukrywa pierwotnego komunikatu pod ogólnym błędem połączenia. Wnioski powinny wynikać z pełnego przebiegu zdarzeń, a nie wyłącznie z nazwy eventu.
Analiza wpisów error_reported może pomóc oddzielić problem sprzętowy, taki jak niestabilna pamięć masowa lub uszkodzenie systemu plików, od błędu konfiguracji albo samego zapytania. Prawidłowa ocena wymaga zachowania oryginalnych komunikatów, ustalenia warunków ich wystąpienia i sprawdzenia, czy problem powtarza się po odtworzeniu tej samej operacji.
