Dela via


Felsöka problem med Database Mail

Den här artikeln innehåller metoder för att felsöka problem med Database Mail. Om den inledande felsökningen inte har löst problemet använder du avancerad felsökning.

Inledande felsökning av Database Mail

Här följer grundläggande felsökningssteg:

  1. Granska databasmeddelandeloggen och sysmail-vyerna (sysmail_event_log) för e-postmeddelanden som redan har skickats eller försökt skickas med hjälp av DatabaseMail.exe.
  2. Skicka ett testmeddelande. Om testmeddelandet har skickats fokuserar du på informationen om de meddelanden som inte skickas. Om testmeddelandet inte skickas fokuserar du på att felsöka testmeddelandet och ignorera de e-postmeddelanden som inte har skickats tidigare.
  3. Om du misstänker att SMTP-serverinställningarna är felaktiga eller om det finns ett problem med kontot som används för att skicka e-postmeddelandet använder du PowerShell för att skicka ett testmeddelande.
  4. Om du inte skickar e-postmeddelandet med hjälp av PowerShell är det troligtvis ett SMTP-konfigurationsproblem och en SMTP-administratör behövs.

Du kan använda följande steg för inledande felsökning av Database Mail.

Systemvyer för Msdb sysmail

Innan du tittar på de detaljerade stegen, här är en snabb sammanfattning av relevanta Database Mail-systemvyer.

  1. Mest relevant loggning sker i systemvyn msdb sysmail. Du kan köra frågor mot dessa vyer direkt i din miljö.

    Namn Type Beskrivning
    sysmail_allitems Visa Visar en lista över alla meddelanden som skickas till Database Mail.
    sysmail_event_log Visa Visar meddelanden om beteendet för det externa programmet Database Mail.
    sysmail_faileditems Visa Information om meddelanden som Database Mail inte kunde skicka.
    sysmail_mailattachments Visa Information om bifogade filer till Database Mail-meddelanden.
    sysmail_sentitems Visa Information om meddelanden som har skickats med hjälp av Database Mail.
    sysmail_unsentitems Visa Information om meddelanden som Database Mail försöker skicka för närvarande.
  2. Vissa fel loggas i händelseloggen för Windows-programmet.

Steg 1: Kontrollera sysmail_event_log vy

Den här systemvyn är startpunkten för att felsöka alla problem med Database Mail.

När du felsöker Database Mail söker du i sysmail_event_log vyn efter händelser som är relaterade till e-postfel. Vissa meddelanden (till exempel felet i det externa programmet Database Mail) är inte kopplade till specifika e-postmeddelanden.

Sysmail_event_log innehåller en rad för varje Windows- eller SQL Server-meddelande som returneras av Database Mail-systemet. I SQL Server Management Studio (SSMS) väljer du Hantering, högerklickar på Database Mail och väljer Visa databaspostlogg för att kontrollera databasens e-postlogg på följande sätt:

Skärmbild av loggobjektet Visa databaspost i menyn Databaspost.

Kör följande fråga till sysmail_event_log:

SELECT er.log_id AS [LogID],
  er.event_type AS [EventType],
  er.log_date AS [LogDate],
  er.description AS [Description],
  er.process_id AS [ProcessID],
  er.mailitem_id AS [MailItemID],
  er.account_id AS [AccountID],
  er.last_mod_date AS [LastModifiedDate],
  er.last_mod_user AS [LastModifiedUser]
FROM msdb.dbo.sysmail_event_log er
ORDER BY [LogDate] DESC

Kolumnen event_type kan ha följande värden:

  • Fel
  • Varningar
  • Information
  • Klart

Om du bara vill visa de nödvändiga händelsetyperna WHERE använder du -satsen för att filtrera.

Kontrollera det specifika misslyckade e-postobjektet

Om du vill söka efter fel som är relaterade till specifika e-postmeddelanden letar du upp mailitem_id det misslyckade e-postmeddelandet i sysmail_faileditems vyn och söker sedan efter meddelanden som är relaterade till mailitem_id i sysmail_event_log.

SELECT er.log_id AS [LogID], 
    er.event_type AS [EventType], 
    er.log_date AS [LogDate], 
    er.description AS [Description], 
    er.process_id AS [ProcessID], 
    er.mailitem_id AS [MailItemID], 
    er.account_id AS [AccountID], 
    er.last_mod_date AS [LastModifiedDate], 
    er.last_mod_user AS [LastModifiedUser],
    fi.send_request_user,
    fi.send_request_date,
    fi.recipients, fi.subject, fi.body
FROM msdb.dbo.sysmail_event_log er 
    LEFT JOIN msdb.dbo.sysmail_faileditems fi
ON er.mailitem_id = fi.mailitem_id
ORDER BY [LogDate] DESC

När ett fel returneras från sp_send_dbmailskickas inte e-postmeddelandet till Database Mail-systemet och felet visas inte i sysmail_event_log vyn. Du bör samla in profilerspårning på instruktionsnivå och felsöka det fel som du stöter på.

När enskilda kontoleveransförsök misslyckas kommer Database Mail att lagra felmeddelandena under återförsök tills leveransen av e-postobjektet lyckas eller misslyckas. Om leveransen lyckas loggas alla ackumulerade fel som separata varningar, inklusive account_id. Det kan orsaka en varning även om e-postmeddelandet skickades. Om leveransen misslyckas i slutet loggas alla tidigare varningar som ett felmeddelande utan ett account_id eftersom alla konton har misslyckats.

Problem som kan loggas in sysmail_event_log

Följande problem kan loggas in sysmail_event_log:

  • Det gick inte att DatabaseMail.exe att ansluta till SQL Server.

    Om det externa programmet inte kan logga till msdb-tabellerna loggar programmet fel i händelseloggen för Windows-programmet.

  • Fel som är associerade med SMTP-servern.

    • Det gick inte att kontakta SMTP-servern.
    • Det gick inte att autentisera med SMTP-servern.
    • SMTP-servern nekar e-postmeddelandet.
  • Undantag i DatabaseMail.exe.

Om det inte finns några problem med den externa körbara filen Database Mail går du till systemvyerna för sysmail. Om du vill söka efter fel som är relaterade till specifika e-postmeddelanden letar du upp mailitem_id det misslyckade e-postmeddelandet i sysmail_faileditems vyn och söker sedan efter meddelanden som är relaterade till mailitem_id i sysmail_event_log. När ett fel returneras från sp_send_dbmailskickas inte e-postmeddelandet till Database Mail-systemet och felet visas inte i sysmail_event_log vyn.

Steg 2: Kontrollera vyerna sysmail_unsentitems, sysmail_sentitems och sysmail_faileditems

Du kan kontrollera dessa vyer för problem med specifika e-postmeddelanden för att se om databasmeddelanden skickas, fastnar i kön eller inte skickas.

Interna tabeller i msdb-databasen innehåller de e-postmeddelanden och bifogade filer som skickas från Database Mail, tillsammans med deras aktuella status. Database Mail uppdaterar dessa tabeller när meddelandena bearbetas.

Sysmail_mailitems tabellen är bastabellen för de andra sysmail-vyerna. Vyn sysmail_allitems är byggd på tabellen och är en superuppsättning av dessa vyer.

Kommentar

Om du säkerhetskopierar msdb-produktionsdatabasen och återställer till ett annat testsystem som en användardatabas kan du återskapa sysmail-systemvyerna i den återställde säkerhetskopian. Vydefinitionerna i den återställde säkerhetskopian refererar till msdb-databasen i systemet där du återställde säkerhetskopian. Se skriptet för att återskapa sysmail-vyer i kundens msdb i avsnittet Msdb-säkerhetskopiering .

Sysmail_unsentitems

Den här vyn innehåller en rad för varje Database Mail-meddelande vars status inte har angetts eller försöker igen.

Använd den här vyn när du vill se hur många meddelanden som väntar på att skickas och hur länge de har varit i e-postkön. I allmänhet är antalet meddelanden som inte har angetts litet. Du kan jämföra under normala åtgärder för att fastställa ett rimligt antal meddelanden i meddelandekön för normal drift.

Du kan också kontrollera e-postmeddelanden i sysmail_unsentitems om det finns problem med Service Broker-objekten i msdb. ExternalMailQueue Om kön eller InternalMailQueue är inaktiverad, eller om det finns problem med vägen, kan e-postmeddelandet stanna kvar i sysmail_unsentitmes.

Meddelanden som inte har skickats eller försöker igen finns fortfarande i e-postkön och kan skickas när som helst. Meddelanden kan ha statusen oförstörd av följande skäl:

  • Meddelandet är nytt. Även om meddelandet har placerats i e-postkön arbetar Database Mail med andra meddelanden och har ännu inte nått det här meddelandet.
  • Det externa programmet Database Mail körs inte och ingen e-post skickas.

Meddelanden kan ha återförsöksstatus av följande skäl:

  • Database Mail försökte skicka e-postmeddelandet, men kunde inte kontakta SMTP-e-postservern. Database Mail fortsätter att försöka skicka meddelandet med hjälp av andra Database Mail-konton som har tilldelats till profilen som skickade meddelandet. Om inget konto kan skicka e-postmeddelandet väntar Database Mail under den tid som har konfigurerats för parametern Account Retry Delay och försöker sedan skicka meddelandet igen. Database Mail använder parametern för att avgöra hur många gånger meddelandet ska skickas. När Database Mail försöker skicka meddelandet förblir meddelandet återförsöksstatus.
  • Database Mail ansluter till SMTP-servern, men det uppstår ett fel. SMTP-felkoden som returneras av SMTP-servern och eventuella tillhörande felmeddelanden kan användas för ytterligare felsökning.

Sysmail_faileditems

Om du vet att e-postmeddelandet inte kunde skickas kan du fråga sysmail_faileditems direkt. Mer information om hur du sysmail_faileditems frågar efter och filtrerar efter specifika meddelanden efter mottagare finns i Kontrollera status för e-postmeddelanden som skickas med databasmeddelande.

Kör följande skript för att kontrollera statusen för e-postmeddelanden som skickas med hjälp av Database Mail:

-- Show the subject, the time that the mail item row was last  
-- modified, and the log information.  
-- Join sysmail_faileditems to sysmail_event_log   
-- on the mailitem_id column.  
-- In the WHERE clause list items where danw was in the recipients,  
-- copy_recipients, or blind_copy_recipients.  
-- These are the items that would have been sent to Jane@contoso.com
 
SELECT items.subject, items.last_mod_date, l.description 
FROM dbo.sysmail_faileditems AS items  
INNER JOIN dbo.sysmail_event_log AS l ON items.mailitem_id = l.mailitem_id  
WHERE items.recipients LIKE '%Jane%'    
    OR items.copy_recipients LIKE '%Jane%'   
    OR items.blind_copy_recipients LIKE '%Jane%'  
GO  

Sysmail_sentitems

Om du vill hitta den tid då det senaste e-postmeddelandet skickades kan du fråga sysmail_sentitems efter och beställa sent_date enligt följande:

SELECT ssi.sent_date, * 
FROM msdb.dbo.sysmail_sentitems ssi
ORDER BY ssi.sent_date DESC

Om vissa typer av e-postmeddelanden har skickats men andra inte är det, kan den här vyn hjälpa dig att ta reda på skillnaderna.

Steg 3: Kontrollera sysmail_mailattachments vy

Den här vyn innehåller en rad för varje bifogad fil som skickas till Database Mail. Använd den här vyn när du behöver information om bifogade filer i Database Mail.

Om du har problem med att skicka e-postmeddelanden med bifogade filer, men vissa e-postmeddelanden med bifogade filer har skickats, kan den här vyn hjälpa dig att ta reda på skillnaderna.

Steg 4: Kontrollera konfigurationen av Database Mail för SMTP-server

Ett annat steg för att lösa problem med Database Mail är att kontrollera Databasens e-postkonfiguration för SMTP-servern och det konto som används för att skicka Database Mail.

Mer information om hur du konfigurerar Database Mail finns i Konfigurera Database Mail.

Konfigurera Database Mail

Följ stegen för att konfigurera Database Mail:

  1. Öppna SSMS, välj Hantering, högerklicka på Database Mail och välj Konfigurera databasmeddelande.

    Skärmbild av det konfigurerade databaspostloggobjektet på menyn Databaspost.

  2. Välj Hantera databas-e-postkonton och profiler>Nästa.

  3. Om du har ett konto väljer du Visa, ändrar eller tar bort ett befintligt konto och väljer Nästa, annars väljer du Skapa nytt konto. Följande skärmbild visar kontoinställningarna som används för att ansluta till SMTP-servern och skicka Database Mail.

    Skärmbild av guiden Hantera befintligt konto i konfigurationsguiden för databasmeddelanden.

Var särskilt uppmärksam på:

  • Servernamn och portnummer. Servernamnet måste vara ett fullständigt domännamn och portnumret måste vara korrekt. I allmänhet är SMTP-standardporten 25, men du måste kontrollera den aktuella SMTP-konfigurationen.

  • SSL. Kontrollera om SMTP-servern kräver SSL (Secure Sockets Layer) eller TLS (Transport Layer Security).

  • SMTP-autentisering. Använder du Windows-autentisering av tjänsten Database Engine, grundläggande autentisering med ett angivet domänkonto eller anonym autentisering? Du måste kontrollera vad SMTP-servern tillåter i din egen miljö. Om ett domänkonto har angetts (antingen tjänstkonto eller grundläggande autentisering) måste det ha behörigheterna på SMTP-servern.

Du kan använda konfigurationen för att skicka ett testmeddelande med PowerShell. Mer information finns i Skicka ett testmeddelande med PowerShell.

Kontrollera systemparametrar för Database Mail

Följ stegen för att kontrollera systemparametrarna:

  1. Öppna SSMS, välj Hantering, högerklicka på Database Mail och välj Konfigurera databasmeddelande.

  2. Välj Visa eller ändra systemparametrar.

Följande skärmbild visar standardvärdena för systemparametrarna. Observera eventuella unika systemparametrar och ta reda på om de är relaterade till problemet som du felsöker.

Skärmbild av konfigurationen av systemparametrar i konfigurationsguiden för databasmeddelanden.

Steg 5: Skicka ett testmeddelande

Det här avsnittet hjälper dig att skicka ett Test Database Mail med hjälp av SSMS och PowerShell.

Skicka ett testmeddelande med Database Mail

Genom att skicka ett testmeddelande kan du försöka återskapa problemet som du upplever och kontrollera om någon Database Mail kan skickas.

Om du vill skicka ett testdatabasmeddelande väljer du Hantering, högerklickar på Databaspost och väljer Skicka test-e-post....

Skärmbild av alternativet skicka testmeddelande som visas när du har högerklickat på Database Mail.

När du har skickat testmeddelandet kontrollerar du databasens e-postlogg och sysmail-vyer.

  • Om testmeddelandet inte har skickats använder du det här dokumentet för att felsöka varför det inte skickas.
  • Om testmeddelandet har skickats, men det fortfarande finns problem med andra e-postmeddelanden som inte skickas, fokuserar du på informationen om de e-postmeddelanden som inte skickas. Granska det faktiska sp_send_dbmail kommandot som körs. Om du inte har Transact-SQL-kommandot samlar du in en XEvent-spårning med hjälp sql_batch_completed av kommandon och sql_batch_started tittar på batch_text kolumnen.

Skicka ett testmeddelande med PowerShell

Med hjälp av en extern process kan du undanta Database Mail från felsökningen och testa kontokonfigurationen. Använd till exempel PowerShell för att skicka ett testmeddelande. Om du inte kan skicka ett testmeddelande med hjälp av PowerShell betyder det att det inte är ett problem med Database Mail.

Om e-postmeddelandet som skickas från PowerShell misslyckas med samma SMTP-serverinställningar och autentiseringsuppgifter kan det tyda på att problemet finns på SMTP-servern.

  • Ändra följande parametrar enligt din miljö och kör sedan följande skript:

    $EmailFrom = "dbmail@contoso.com"
    $EmailPass = "Y0reP@ssw0rd"
    $EmailTo = "email_alias@contoso.com"
    $Port = 587
    $Subject = "Test From PowerShell"
    $Body = "Did this work?"
    $SMTPServer = "smtp.contoso.com"
    
    $SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, $Port)
    $SMTPClient.EnableSsl = $true
    $SMTPClient.Credentials = New-Object System.Net.NetworkCredential($EmailFrom, $EmailPass);
    $SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body) 
    
  • Om SMTP-servern tillåter anonym autentisering använder du standardport 25 och kräver inte SSL. Kör följande skript:

    $EmailFrom = "dbmail@contoso.com"
    $EmailTo = "email_alias@contoso.com"
    $Port = 25
    $Subject = "Test From PowerShell (Anonymous Auth, no SSL)"
    $Body = "Did this work?"
    $SMTPServer = "smtp.contoso.com"
    
    $SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, $Port)
    $SMTPClient.EnableSsl = $true
    $SMTPClient.Credentials = New-Object System.Net.NetworkCredential($EmailFrom, $EmailPass);
    $SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body) 
    

Steg 6: Kontrollera sysmail Service Broker-objekten

Problem med Service Broker-objekten i msdb kan orsaka misslyckad åtgärd av Database Mail. Ett vanligt problem är att en av Service Broker-köerna (ExternalMailQueue och InternalMailQueue) är inaktiverad. Det här problemet kan orsakas av ett giftmeddelande som inte kan skickas i Service Broker. Till exempel felaktig XML. Om ett meddelande inte kan skickas efter fem försök betraktas det som "gift" och kön inaktiveras tills giftmeddelandet tas bort. Att återaktivera kön löser inte problemet eftersom giftmeddelandet fortfarande finns i kön och felsekvensen bara upprepas. Mer information om giftmeddelande finns i Hantering av giftmeddelanden.

Ett av de andra Service Broker-objekten (till exempel Message Type, Contract, Serviceoch Route) kan också inaktiveras eller saknas. Service Broker-köerna har en aktiveringsprocedur som är associerad med kön, så det är en möjlig felpunkt. Du kan kontrollera activation_procedure kolumnen i msdb.sys.service_queuesoch sedan använda sp_helptext för att kontrollera om det finns några problem.

Kör följande fråga och kontrollera sedan innehållet i den andra kolumnen i frågeresultatet.

SELECT CONVERT(VARCHAR(32),name) Name, 'exec sp_helptext ''' + activation_procedure + '''' ActivationProc_Code 
FROM msdb.sys.service_queues

För att avgöra om det finns några problem med Service Broker-objekten är det bättre att jämföra objekten med en fungerande Database Mail-konfiguration. Här är de objekt som du bör jämföra med:

  • Message Types
    • {//www.microsoft.com/databasemail/messages}Skicka e-post
    • {//www.microsoft.com/databasemail/messages}SendMailStatus
  • Contracts
    • www.microsoft.com/databasemail/contracts/SendMail/v1.0
  • Queues
    • dbo.ExternalMailQueue
    • dbo.InternalMailQueue
  • Services
    • ExternalMailService
    • InternalMailService
  • Routes

Felsökning av Advanced Database Mail

Avancerad felsökning gäller för följande scenarier:

  • När du tittar på Database Mail-loggen kraschar Database Mail och orsaken förklaras inte helt. Du ser att DatabaseMail-processen startas omedelbart av ett undantagsmeddelande och att DatabaseMail-processen stängs av visas.
  • Database Mail startar inte. Du ser inte att DatabaseMail-processen har startats i sysmail_event_log vyn.
  • Den första felsökningen hjälper dig inte att lösa problemet.

Du kan använda följande metoder för avancerad felsökning av Database Mail.

Samlingarna för avancerad felsökning

För att lösa problemen kan du behöva en eller flera av dessa samlingar.

Metod 1: Säkerhetskopiera msdb-databasen

Det kan vara bra att fråga sysmail-vyerna i en miljö som är separat från produktion. I vissa fall kan du säkerhetskopiera msdb-databasen och sedan återställa till en annan instans. Sysmail-vyerna definieras alla med referens till msdb, så även när du frågar i den återställde msdb-säkerhetskopieringen refererar vyerna till msdb-systemdatabasen i din instans. Om du vill återskapa sysmail-vyer från produktions-msdb skapar du sysmail-vyerna i användardatabasen igen med hjälp av följande skript.

/* sysmail_allitems */

USE [msdb_customer]
GO

PRINT 'Creating view sysmail_allitems in msdb backup from customer...'
GO
IF (EXISTS (SELECT *
            FROM [msdb_customer].dbo.sysobjects
            WHERE (NAME = N'sysmail_allitems')
              AND (TYPE = 'V')))
  DROP VIEW sysmail_allitems
GO

CREATE VIEW sysmail_allitems
AS
SELECT mailitem_id, profile_id, recipients, copy_recipients, blind_copy_recipients, subject, body, body_format, importance, sensitivity, file_attachments,
       attachment_encoding, query, execute_query_database, attach_query_result_as_file, query_result_header, query_result_width, query_result_separator,
       exclude_query_output, append_query_error, send_request_date, send_request_user, sent_account_id,
       CASE sent_status 
          WHEN 0 THEN 'unsent' 
          WHEN 1 THEN 'sent' 
          WHEN 3 THEN 'retrying' 
          ELSE 'failed' 
       END AS sent_status,
       sent_date, last_mod_date, last_mod_user       
FROM [msdb_customer].dbo.sysmail_mailitems 
WHERE (send_request_user = SUSER_SNAME()) OR (ISNULL(IS_SRVROLEMEMBER(N'sysadmin'), 0) = 1) 

GO

/* sysmail_sentitems */

USE [msdb_customer]
GO

PRINT 'Creating view sysmail_sentitems in msdb backup from customer...'
GO
IF (EXISTS (SELECT *
            FROM [msdb_customer].dbo.sysobjects
            WHERE (NAME = N'sysmail_sentitems')
              AND (TYPE = 'V')))
  DROP VIEW sysmail_sentitems
GO

CREATE VIEW sysmail_sentitems
AS
SELECT * FROM [msdb_customer].dbo.sysmail_allitems WHERE sent_status = 'sent'

GO

/* sysmail_unsentitems */

USE [msdb_customer]
GO

PRINT 'Creating view sysmail_unsentitems in msdb backup from customer...'
GO
IF (EXISTS (SELECT *
            FROM [msdb_customer].dbo.sysobjects
            WHERE (NAME = N'sysmail_unsentitems')
              AND (TYPE = 'V')))
  DROP VIEW sysmail_unsentitems
GO

CREATE VIEW sysmail_unsentitems
AS
SELECT * FROM [msdb_customer].dbo.sysmail_allitems WHERE (sent_status = 'unsent' OR sent_status = 'retrying')

GO

/* sysmail_faileditems */

USE [msdb_customer]
GO

PRINT 'Creating view sysmail_faileditems in msdb backup from customer...'
GO
IF (EXISTS (SELECT *
            FROM [msdb_customer].dbo.sysobjects
            WHERE (NAME = N'sysmail_faileditems')
              AND (TYPE = 'V')))
  DROP VIEW sysmail_faileditems
GO

CREATE VIEW sysmail_faileditems
AS
SELECT * FROM [msdb_customer].dbo.sysmail_allitems WHERE sent_status = 'failed'

GO

/* sysmail_event_log */
USE [msdb_customer]
GO
PRINT 'Creating view sysmail_event_log in msdb backup from customer...'
GO
IF (EXISTS (SELECT *
            FROM [msdb_customer].dbo.sysobjects
            WHERE (NAME = N'sysmail_event_log')
              AND (TYPE = 'V')))
  DROP VIEW sysmail_event_log
GO
CREATE VIEW sysmail_event_log
AS
SELECT log_id,
       CASE event_type 
          WHEN 0 THEN 'success' 
          WHEN 1 THEN 'information' 
          WHEN 2 THEN 'warning' 
          ELSE 'error' 
       END as event_type,
       log_date, description, process_id, sl.mailitem_id, account_id, sl.last_mod_date, sl.last_mod_user
FROM [msdb_customer].[dbo].[sysmail_log]  sl
WHERE (ISNULL(IS_SRVROLEMEMBER(N'sysadmin'), 0) = 1) OR 
      (EXISTS ( SELECT mailitem_id FROM [msdb_customer].[dbo].[sysmail_allitems] ai WHERE sl.mailitem_id = ai.mailitem_id ))

GO

Mer information om sysmail-vyer finns i avsnittet systemvyer för sysmail.

Metod 2: Kontrollera händelseloggen för Windows-programmet

Om det externa DatabaseMail.exe programmet inte kan logga till msdb-tabellen loggar programmet felet till händelseloggen för Windows-programmet. Om DatabaseMail.exe stöter på undantag loggas dessutom undantaget. Även om undantagsstacken vanligtvis är identisk kontrollerar du händelseloggen för att se om det finns någon annan stackinformation.

Ibland när du felsöker en DatabaseMail.exe krasch kan det hända att loggning indikerar att en Windows-felrapportdump skapades på följande sätt:

<datetime stamp>,Information,0,1001,Windows Error Reporting,Viewpoint.contoso.com,"Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: DatabaseMail.exe
P2: 11.0.2100.60
P3: 4f35e1a1
P4: KERNELBASE.dll
P5: 6.3.9600.18725
P6: 59380775
P7: c0000142
P8: 00000000000ece60
P9: 
P10: 
Attached files:
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_DatabaseMail.exe_deaadc12935831f6bbfe9bdcb0cbf864374426c1_807e7507_337982fd
Analysis symbol: 
Rechecking for solution: 0
Report Id: <Report Id>
Report Status: 4100
Hashed bucket:"

Du kan hämta alla filer som visar AppCrash_DatabaseMail.exe_* i .. \WER\ReportQueue-sökväg . Se avsnittet ProcDump Analysis (ProcDump-analys) för förslag på dumpanalys.

Metod 3: Samla in och analysera XEvent- eller SQL Server-spårning

Du kan samla in en spårning av Transact-SQL-kommandona som körs i systemet för att se om någon av dem misslyckas.

Konfigurera PSSDiag-verktyget

Du kan använda PSSDiag för att samla in XEvent- eller SQL Server-spårningen under mallen Allmän prestanda. Som du ser i följande skärmbild väljer du några ytterligare händelser, särskilt alla asynkrona händelser.

Skärmbild av pssdiag-verktyget där alla asynkrona händelser på fliken XEvent är aktiverade.

Analysera Xevent- eller SQL-spårningen

När ett databasmeddelande skickas visas vanligtvis fem olika sessioner (SPID) i en Xevent- eller Profiler-avbildning.

  • sp_send_dbmail: När du har kört Transact-SQL-instruktionen visas de Service Broker-händelser som används för att placera meddelandena i ExternalMailQueue kön.

  • Service Broker-aktivering för att skicka meddelanden till SMTP-servern via DatabaseMail.exe. Programnamnet är "Microsoft SQL Server Service Broker Activation".

  • Externt program för databasutskick: Det här är det externa Database Mail-programmet som tar emot meddelanden från ExternalMailQueue kön och förbereder meddelanden som ska skickas till SMTP-servern. Programnamnet är "DatabaseMail – DatabaseMail – Id<PID>".

  • Externt program för databaspost: Det här är en annan anslutning från Database Mail. När den första anslutningen bearbetar de befintliga meddelandena i ExternalMailQueue kön skapas anslutningen för att lyssna efter ytterligare meddelanden som ska placeras i kön. Om det inte finns några andra meddelanden i kön kommer DatabaseMail.exe att avsluta och stänga den här anslutningen.

  • Service Broker-aktivering för att ta emot svarsmeddelanden från SMTP-servern via DatabaseMail.exe. Den uppdaterar sysmail-tabellerna för att logga resultat av e-postmeddelanden som skickas.

Du kan bara känna till det förväntade beteendet genom att visa många av spårningarna. Det bästa sättet att känna till skillnaderna är att jämföra spårningen med en av de databasutskick som har skickats. Om du ibland kan skicka ett Database Mail kan du jämföra spårningen med en lyckad spårning, se skillnaden och söka efter eventuella fel som rapporteras av SPID:erna. Om du inte kan skicka något Database Mail jämför du spårningen med den som har skickats i testmiljön.

Metod 4: Samla in och analysera processövervakningshändelser

Process Monitor (Procmon) är en del av Windows Sysinternals-sviten.

Process Monitor genererar en bullrig avbildning. För att inte missa något är det bättre att tillämpa filter på data när de har registrerats i stället för under insamlingsprocessen. Vanligtvis kan du rikta in dig på avbildningen kring en repro av Database Mail-problemet, så att de övergripande data som samlas in inte blir för stora.

Samla in fil-, register-, nätverks-, process- och trådhändelser

När du börjar procmon.exe börjar den samla in data omedelbart. Användargränssnittet är enkelt. Du måste stoppa insamlingen av händelser tills du är redo att återskapa problemet. Välj Arkivinsamlingshändelser>(Ctrl+E) för att avmarkera menyalternativet och stoppa händelsesamlingen. Välj radergummiikonen eller tryck på Ctrl+X för att rensa de händelser som redan har avbildats:

Skärmbild av procmon-verktyget som visar att alla händelser har rensats.

När du är redo att återskapa problemet med Database Mail följer du stegen:

  1. Välj Filfångsthändelser>(Ctrl+E) för att börja samla in händelser.
  2. Försök att skicka Database Mail för att återskapa problemet.
  3. Välj Filfångsthändelser>(Ctrl+E) för att sluta samla in händelser.
  4. Spara filen som *. PML.

Analysera spårningen för processövervakaren

När du har fått . PML-fil, öppna den med processövervakaren igen. Filtrera först filen efter processerna DatabaseMail.exe och sqlservr.exe . Välj sedan Filterfilter > ... eller klicka på filterikonen för att öppna filtermenyn.

Som Processnamn väljer du sqlservr.exe och DatabaseMail.exe och lägger sedan till följande poster:

Skärmbild av procmon-verktyget som visar database.exe filtreras.

Precis som för SQL XEvent eller Spårningsinsamling är det inte direkt uppenbart vad du ska leta efter. Det bästa sättet att starta analysen är vanligtvis att jämföra spårningen med en Procmon-avbildning för ett databasmeddelande som skickats korrekt. Vi rekommenderar att du jämför spårningen med ett e-postmeddelande som skickats från samma miljö där problemet uppstår. Men om ingen databaspost har skickats i den specifika miljön jämför du spårningen med ett e-postmeddelande som skickats i en annan miljö.

När DatabaseMail.exe inte kan läsa in en DLL eller inte hittar filen DatabaseMail.exe.config är analysen användbar.

Metod 5: Samla in och analysera undantagsdumpen med hjälp av Verktyget ProcDump

ProcDump är också en del av Windows Sysinternals-sviten.

ProcDump är användbart när du försöker samla in en minnesdump av DatabaseMail.exe externa programmet. Vanligtvis använder du ProcDump för felsökning när DatabaseMail.exe stöter på ett ohanterat undantag.

Konfigurera ProcDump

Om du vill konfigurera ProcDump för att samla in en dump med DatabaseMail.exe när ett ohanterat undantag uppstår öppnar du först en kommandotolk med administratörsbehörighet. Aktivera sedan ProcDump för att avbilda dumpen för DatabaseMail.exe-processen med hjälp av följande kommando:

c:\Sysinternals> procdump -ma -t DatabaseMail.exe -w e2

Följande utdata visas i kommandofönstret:

ProcDump v9.0 - Sysinternals process dump utility
Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com
 
Waiting for process named DatabaseMail.exe...

Återskapa sedan problemet. Dumpen skapas i samma mapp där du har kört ProcDump.exe.

Analysera undantagsdumpen

Leta upp undantagsposten och granska anropsstacken som leder till undantaget.

  1. Öppna dumpfilen i WinDbg (Ladda ned felsökningsverktyg för Windows – WinDbg – Windows-drivrutiner).
  2. Växla till undantagsposten med hjälp .ecxr av kommandot eller !analyze -v .

När du har stacken börjar du söka efter kända problem för en matchande anropsstack. Kontakta CSS-teamet om du behöver ytterligare hjälp.

Metod 6: Använd felsökningsverktyget för tidsresor

TTD-avbildning (Time Travel Debugging) är vanligtvis den sista utvägen för svåra problem. Du kan använda felsökningsprogrammet för WinDbg-förhandsversionen för att hämta den. Omfattande instruktioner och information om TTD finns i Felsökning av tidsresor om hur det fungerar och hur du gör analyser. Om du kommer till den här punkten måste du kontakta CSS-teamet. Det här avsnittet innehåller dock instruktioner om hur du avbildar TTD vid behov.

Konfigurera TTD

Av flera skäl kan TTD-avbildning av DatabaseMail.exe vara lite utmanande. För det första körs DatabaseMail.exe inte som en tjänst på obestämd tid, men den anropas av SQL Server-processen (sqlservr.exe). Därför kan du inte ansluta till den, men du måste konfigurera TTD med hjälp av parametern -onLaunch för att börja samla in den när DatabaseMail.exe startar. För det andra, eftersom DatabaseMail.exe anropas av en annan process måste du använda de underordnade processerna för felsökning.