Database Mail Log to dziennik rejestrujący historię wysłanych i nieudanych prób wysyłki wiadomości przez ten mechanizm.
Rola dziennika Database Mail Log w SQL Server
Database Mail Log jest częścią mechanizmu Database Mail dostępnego w Microsoft SQL Server. Rejestruje zdarzenia związane z obsługą poczty wychodzącej, w tym informacje o rozpoczęciu przetwarzania, ostrzeżenia oraz błędy występujące podczas przygotowania lub wysyłania wiadomości. Dziennik służy przede wszystkim do ustalenia, na którym etapie obsługi wiadomości pojawił się problem. Nie jest to treść skrzynki pocztowej ani pełny zapis komunikacji prowadzonej przez serwer SMTP.
Informacje dotyczące logu są przechowywane w bazie systemowej msdb. W widoku graficznym SQL Server Management Studio można otworzyć dziennik Database Mail z poziomu konfiguracji Database Mail i filtrować wpisy według daty, typu zdarzenia lub innych dostępnych kryteriów. Przy analizie warto rozdzielić sam wpis w logu od danych o wiadomości. Database Mail Log opisuje zdarzenie, natomiast informacje o adresatach, temacie, statusie i czasie obsługi wiadomości znajdują się w widokach systemowych Database Mail.
Jak SQL Server zapisuje zdarzenia wysyłki
Najważniejszym widokiem dziennika jest msdb.dbo.sysmail_event_log. Zawiera on między innymi identyfikator wpisu log_id, datę zdarzenia log_date, typ zdarzenia event_type oraz opis w kolumnie description. Wpis może także zawierać identyfikator procesu obsługującego wysyłkę, identyfikator elementu pocztowego mailitem_id oraz identyfikator konta Database Mail account_id. Te powiązania pozwalają przejść od ogólnego komunikatu do konkretnej próby wysyłki lub do konta użytego przez profil.
Wartość event_type wskazuje charakter zdarzenia. W praktyce spotyka się wpisy typu error, warning i information. Błąd może oznaczać na przykład odrzucenie połączenia z serwerem SMTP, nieudaną próbę uwierzytelnienia, problem z rozpoznaniem nazwy hosta albo brak możliwości przekazania wiadomości do kolejnego etapu. Ostrzeżenie nie zawsze oznacza nieudaną wysyłkę, dlatego nie powinno być automatycznie traktowane jako dowód, że wiadomość nie dotarła. Ostateczny status konkretnego elementu należy sprawdzić razem z wpisami dotyczącymi tego samego mailitem_id.
Przykładowe zapytanie diagnostyczne może odczytać ostatnie wpisy bez modyfikowania danych:
SELECT TOP (100) log_id, log_date, event_type, description, mailitem_id, account_id FROM msdb.dbo.sysmail_event_log ORDER BY log_date DESC;
Powiązanie logu z kolejką i statusem wiadomości
Sam Database Mail Log nie pokazuje całego obrazu przetwarzania wiadomości. Do kontroli kolejki służy widok msdb.dbo.sysmail_allitems, który zawiera wszystkie elementy pocztowe zapisane przez Database Mail. Z jego pomocą można sprawdzić między innymi mailitem_id, send_request_date, sent_date, sent_status, adresatów oraz temat wiadomości. Widoki sysmail_sentitems, sysmail_faileditems i sysmail_unsentitems ograniczają wyniki odpowiednio do wiadomości wysłanych, zakończonych niepowodzeniem oraz pozostających niewysłanych.
Poprawna analiza polega na połączeniu tych danych za pomocą identyfikatora mailitem_id. Jeżeli w sysmail_faileditems znajduje się wiadomość o określonym identyfikatorze, w sysmail_event_log można wyszukać wpisy odnoszące się do tego samego elementu. Opis błędu może wtedy wskazać techniczną przyczynę, ale nie zawsze potwierdza, czy wiadomość została ostatecznie odrzucona przez serwer odbiorcy. Database Mail przekazuje pocztę do skonfigurowanego serwera SMTP, a dalsze decyzje mogą być rejestrowane dopiero po stronie tego serwera lub systemu odbiorcy.
Ważne jest również rozróżnienie błędu konfiguracji od błędu konkretnej wiadomości. Nieprawidłowe dane uwierzytelniające konta, zablokowany port, niedostępny host SMTP lub problem z profilem mogą powodować wiele podobnych wpisów w krótkim czasie. Z kolei błędny adres odbiorcy, ograniczenie rozmiaru wiadomości albo problem z załącznikiem może dotyczyć tylko wybranych elementów. Porównanie czasu wpisu w logu z send_request_date i sent_date pomaga ustalić kolejność zdarzeń.
Porządkowanie wpisów i praktyczna diagnostyka
Database Mail udostępnia procedurę msdb.dbo.sysmail_delete_log_sp do usuwania wpisów z dziennika według określonych kryteriów. Nie należy usuwać logu przed zakończeniem analizy, ponieważ wpisy mogą być potrzebne do powiązania zdarzeń z elementami pocztowymi. Przed porządkowaniem warto zachować identyfikatory, daty, typy zdarzeń i pełne opisy komunikatów. Dane o wiadomościach są obsługiwane osobno; do usuwania elementów pocztowych służy procedura sysmail_delete_mailitems_sp, dlatego usunięcie logu i usunięcie historii wiadomości nie jest tym samym działaniem.
Diagnostykę najlepiej rozpocząć od ustalenia czasu wystąpienia problemu, następnie wyszukać odpowiednie wpisy w sysmail_event_log i odszukać powiązane mailitem_id w widoku sysmail_allitems. Kolejnym krokiem jest sprawdzenie profilu Database Mail, konta przypisanego do profilu oraz parametrów połączenia z serwerem SMTP. Jeżeli log wskazuje na odrzucenie po stronie SMTP, potrzebny może być także log tego serwera. Database Mail Log pokazuje zdarzenia obserwowane przez SQL Server, ale nie zastępuje logów sieciowych, serwera pocztowego ani systemu odbiorcy.
Przy pracy diagnostycznej na komputerze należy uważać, aby nie mylić Database Mail Log z lokalnym dziennikiem aplikacji pocztowej. Jest to mechanizm serwerowy SQL Server, a jego dane znajdują się w msdb. Na typowym laptopie lub komputerze PC nie da się wiarygodnie ocenić jego zawartości bez dostępu do odpowiedniej instancji SQL Server i uprawnień pozwalających odczytać bazę systemową. Interpretacja tego dziennika wymaga dostępu do środowiska SQL Server, w którym został utworzony.
