Résolution des problèmes de Database Mail

Cet article fournit des méthodes pour résoudre les problèmes de messagerie de base de données. Si le dépannage initial n’a pas résolu votre problème, utilisez la résolution avancée des problèmes.

Résolution des problèmes de messagerie de base de données initiale

Voici les étapes de dépannage de base :

1. Passez en revue le journal de messagerie de base de données et les vues sysmail (sysmail_event_log) pour les messages qui ont déjà été envoyés ou tentés d’envoyer à l’aide de DatabaseMail.exe.
2. Envoyez un message de test. Si le message de test est correctement envoyé, concentrez-vous sur les détails des messages qui ne sont pas envoyés. Si le message de test n’est pas envoyé, concentrez-vous sur la résolution des problèmes liés à la messagerie de test et ignorez les messages envoyés sans succès avant.
3. Si vous pensez que les paramètres du serveur SMTP sont incorrects ou qu’il existe un problème avec le compte utilisé pour envoyer le courrier électronique, utilisez PowerShell pour envoyer un message de test.
4. Si vous ne parvenez pas à envoyer le courrier à l’aide de PowerShell, il est probable qu’il s’agit d’un problème de configuration SMTP et qu’un administrateur SMTP est nécessaire.

Vous pouvez utiliser les étapes suivantes pour la résolution des problèmes de messagerie de base de données initiale.

Vues système Sysmail Msdb

Avant de consulter les étapes détaillées, voici un résumé rapide des vues système de messagerie de base de données pertinentes.

1. La journalisation la plus pertinente se produit dans la vue système sysmail msdb . Vous pouvez interroger ces vues directement dans votre environnement.

   Nom	Type	Description
   sysmail_allitems	Affichage	Répertorie tous les messages envoyés à la messagerie de base de données.
   sysmail_event_log	Affichage	Répertorie les messages relatifs au comportement du programme externe de messagerie de base de données.
   sysmail_faileditems	Affichage	Informations sur les messages que la messagerie de base de données n’a pas pu envoyer.
   sysmail_mailattachments	Affichage	Informations sur les pièces jointes aux messages de la messagerie de base de données.
   sysmail_sentitems	Affichage	Informations sur les messages envoyés à l’aide de la messagerie de base de données.
   sysmail_sentitems	Affichage	Informations sur les messages que la messagerie de base de données tente actuellement d’envoyer.

2. Certaines erreurs sont consignées dans le journal des événements de l’application Windows.

Étape 1 : Vérifier la vue sysmail_event_log

Cette vue système est le point de départ pour résoudre tous les problèmes de messagerie de base de données.

Lors de la résolution des problèmes liés à la messagerie de base de données, recherchez l’affichage sysmail_event_log des événements liés aux échecs de messagerie. Certains messages (tels que l’échec du programme externe de messagerie de base de données) ne sont pas associés à des e-mails spécifiques.

Sysmail_event_log contient une ligne pour chaque message Windows ou SQL Server retourné par le système de messagerie de base de données. Dans SQL Server Management Studio (SSMS), sélectionnez Gestion, cliquez avec le bouton droit sur Messagerie de base de données, puis affichez le journal de messagerie de base de données pour vérifier le journal de messagerie de base de données comme suit :

Exécutez la requête suivante pour 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

La event_type colonne peut avoir les valeurs suivantes :

• Erreurs
• Avertissements
• Information
• Opération réussie

Pour afficher uniquement les types d’événements requis, utilisez la WHERE clause pour filtrer.

Vérifier l’élément de courrier ayant échoué spécifique

Pour rechercher des erreurs liées à des e-mails spécifiques, recherchez l’e-mail mailitem_id ayant échoué dans la sysmail_faileditems vue, puis recherchez les messages liés à mailitem_id .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

Lorsqu’une erreur est retournée sp_send_dbmail, l’e-mail n’est pas envoyé au système de messagerie de base de données et l’erreur n’est pas affichée dans l’affichage sysmail_event_log . Vous devez collecter la trace du profileur au niveau de l’instruction et résoudre l’erreur que vous rencontrez.

Lorsque des tentatives de remise de compte individuelles échouent, la messagerie de base de données conserve les messages d’erreur pendant les tentatives de nouvelle tentative jusqu’à ce que la remise de l’élément de courrier réussisse ou échoue. Si la remise réussit à la fin, toutes les erreurs accumulées sont enregistrées en tant qu’avertissements distincts, y compris account_id. Cela peut provoquer un avertissement même si l’e-mail a été envoyé. Si la remise échoue à la fin, tous les avertissements précédents sont enregistrés en tant que message d’erreur sans qu’aucun account_id compte n’ait échoué.

Problèmes pouvant être connectés sysmail_event_log

Les problèmes suivants peuvent être connectés sysmail_event_log:

• Échec de DatabaseMail.exe de connexion à SQL Server.

  Si le programme externe ne peut pas se connecter aux tables msdb , le programme journalisera les erreurs dans le journal des événements de l’application Windows.

• Échecs associés au serveur SMTP.

  • Échec du contact avec le serveur SMTP.
  • Échec de l’authentification auprès du serveur SMTP.
  • Le serveur SMTP refuse le message électronique.

• Exceptions dans DatabaseMail.exe.

S’il n’y a aucun problème avec l’exécutable externe de la messagerie de base de données, accédez aux vues système sysmail. Pour rechercher des erreurs liées à des e-mails spécifiques, recherchez l’e-mail mailitem_id ayant échoué dans la sysmail_faileditems vue, puis recherchez les messages liés à mailitem_id .sysmail_event_log Lorsqu’une erreur est retournée sp_send_dbmail, l’e-mail n’est pas envoyé au système de messagerie de base de données et l’erreur n’est pas affichée dans l’affichage sysmail_event_log .

Étape 2 : Vérifier les vues sysmail_unsentitems, sysmail_sentitems et sysmail_faileditems

Vous pouvez vérifier ces vues pour connaître les problèmes liés à des e-mails spécifiques pour voir si les messages de base de données sont envoyés, sont bloqués dans la file d’attente ou ne peuvent pas être envoyés.

Les tables internes de la base de données msdb contiennent les messages électroniques et les pièces jointes envoyés à partir de la messagerie de base de données, ainsi que leur état actuel. La messagerie de base de données met à jour ces tables lorsque les messages sont traités.

Sysmail_mailitems table est la table de base pour les autres vues sysmail. La sysmail_allitems vue est basée sur la table et est un super-ensemble de ces vues.

Sysmail_unsentitems

Cette vue contient une ligne pour chaque message de messagerie de base de données dont l’état n’est pas envoyé ou réessaye.

Utilisez cette vue lorsque vous voulez voir combien de messages se trouvent dans la file d'attente des messages et depuis combien de temps ils s'y trouvent. En règle générale, le nombre de messages non envoyés est petit. Vous pouvez évaluer pendant les opérations normales pour déterminer un nombre raisonnable de messages dans la file d’attente des messages pour les opérations normales.

Vous pouvez également consulter les messages s’il sysmail_unsentitems existe des problèmes avec les objets Service Broker dans msdb. Si la file d’attente ou InternalMailQueue la ExternalMailQueue file d’attente est désactivée ou qu’il y a des problèmes avec l’itinéraire, le courrier peut rester dans sysmail_unsentitmes.

Les messages non envoyés ou retentants sont toujours dans la file d’attente de messagerie et peuvent être envoyés à tout moment. Les messages peuvent avoir l’état non spécifié pour les raisons suivantes :

• Le message est nouveau. Bien que le message ait été placé dans la file d’attente de courrier, la messagerie de base de données travaille sur d’autres messages et n’a pas encore atteint ce message.
• Le programme externe de messagerie de base de données n’est pas en cours d’exécution et aucun message n’est envoyé.

Les messages peuvent avoir l’état de nouvelle tentative pour les raisons suivantes :

• La messagerie de base de données a essayé d’envoyer le courrier, mais n’a pas pu contacter le serveur de messagerie SMTP. La messagerie de base de données continue d’essayer d’envoyer le message à l’aide d’autres comptes de messagerie de base de données affectés au profil qui a envoyé le message. Si aucun compte ne peut envoyer le courrier, la messagerie de base de données attend la durée configurée pour le Account Retry Delay paramètre, puis réessaye d’envoyer le message. La messagerie de base de données utilise le paramètre pour déterminer le nombre de tentatives d’envoi du message. Lorsque la messagerie de base de données tente d’envoyer le message, le message reste l’état de nouvelle tentative.
• La messagerie de base de données se connecte au serveur SMTP, mais elle rencontre une erreur. Le code d’erreur SMTP retourné par le serveur SMTP et tout message d’erreur associé peut être utilisé pour une résolution plus approfondie des problèmes.

Sysmail_faileditems

Si vous savez que l’e-mail n’a pas pu être envoyé, vous pouvez interroger sysmail_faileditems directement. Pour plus d’informations sur l’interrogation sysmail_faileditems et le filtrage des messages spécifiques par destinataire, consultez Vérifier l’état des messages électroniques envoyés avec la messagerie de base de données.

Pour vérifier l’état des messages électroniques envoyés à l’aide de la messagerie de base de données, exécutez les scripts suivants :

-- 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

Si vous souhaitez trouver l’heure à laquelle le dernier e-mail a été envoyé avec succès, vous pouvez interroger sysmail_sentitems et commander en sent_date suivant :

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

Si certains types de courriers sont correctement envoyés, mais que d’autres ne le sont pas, cette vue peut vous aider à découvrir les différences.

Étape 3 : Vérifier la vue sysmail_mailattachments

Cette vue contient une ligne pour chaque pièce jointe soumise à la messagerie de base de données. Utilisez cette vue lorsque vous avez besoin d’informations sur les pièces jointes de la messagerie de base de données.

Si vous ne parvenez pas à envoyer des courriers électroniques avec des pièces jointes, mais certains messages contenant des pièces jointes sont envoyés avec succès, cette vue peut vous aider à découvrir les différences.

Étape 4 : Vérifier la configuration de la messagerie de base de données pour le serveur SMTP

Une autre étape pour résoudre les problèmes de messagerie de base de données consiste à vérifier la configuration de la messagerie de base de données pour le serveur SMTP et le compte utilisé pour envoyer la messagerie de base de données.

Pour plus d’informations sur la configuration de la messagerie de base de données, consultez Configurer la messagerie de base de données.

Configurer Database Mail

Pour configurer la messagerie de base de données, procédez comme suit :

1. Ouvrez SSMS, sélectionnez Gestion, cliquez avec le bouton droit sur Messagerie de base de données, puis sélectionnez Configurer la messagerie de base de données.

   

2. Sélectionnez Gérer les comptes et profils>de messagerie de base de données Suivant.

3. Si vous disposez d’un compte, sélectionnez Afficher, modifier ou supprimer un compte existant, puis sélectionnez Suivant, sinon, sélectionnez Créer un compte. La capture d’écran suivante montre les paramètres de compte utilisés pour se connecter au serveur SMTP et envoyer la messagerie de base de données.

   

Faites attention aux points suivants :

• Nom du serveur et numéro de port. Le nom du serveur doit être un nom de domaine complet et le numéro de port doit être exact. En règle générale, le port SMTP par défaut est 25, mais vous devez vérifier la configuration SMTP actuelle.

• SSL : Vérifiez si le serveur SMTP nécessite SSL (Secure Sockets Layer) ou TLS (Transport Layer Security).

• Authentification SMTP. Utilisez-vous les Authentification Windows du service Moteur de base de données, l’authentification de base avec un compte de domaine spécifié ou l’authentification anonyme ? Vous devez vérifier ce que le serveur SMTP autorise dans votre propre environnement. Si un compte de domaine est spécifié (compte de service ou authentification de base), il doit disposer des autorisations sur le serveur SMTP.

Vous pouvez utiliser la configuration pour envoyer un message de test avec PowerShell, consultez Envoyer un e-mail de test avec PowerShell.

Vérifier les paramètres du système de messagerie de base de données

Pour vérifier les paramètres système, procédez comme suit :

1. Ouvrez SSMS, sélectionnez Gestion, cliquez avec le bouton droit sur Messagerie de base de données, puis sélectionnez Configurer la messagerie de base de données.

2. Sélectionnez Afficher ou modifier les paramètres système.

La capture d’écran suivante montre les valeurs par défaut des paramètres système. Notez les paramètres système uniques et déterminez s’ils sont liés au problème que vous résolvez.

Étape 5 : Envoyer un message de test

Cette section vous aide à envoyer un message de base de données de test à l’aide de SSMS et de PowerShell.

Envoyer un e-mail de test avec la messagerie de base de données

L’envoi d’un e-mail de test vous permet de reproduire le problème que vous rencontrez et de vérifier si une messagerie de base de données peut être envoyée.

Pour envoyer un message de base de données de test, sélectionnez Gestion, cliquez avec le bouton droit sur Messagerie de base de données, puis sélectionnez Envoyer un e-mail de test....

Après avoir envoyé le message de test, vérifiez le journal de messagerie de base de données et les vues sysmail.

• Si le message de test n’est pas envoyé avec succès, utilisez ce document pour résoudre les problèmes de non-envoi.
• Si le message de test est envoyé avec succès, mais qu’il existe toujours des problèmes avec d’autres messages qui ne sont pas envoyés, concentrez-vous sur les détails des messages électroniques qui ne sont pas envoyés. Passez en revue la commande réelle sp_send_dbmail en cours d’exécution. Si vous n’avez pas la commande Transact-SQL, rassemblez une trace XEvent à l’aide sql_batch_completed de commandes et sql_batch_started examinez la batch_text colonne.

Envoyer un e-mail de test avec PowerShell

L’utilisation d’un processus externe vous permet d’exclure la messagerie de base de données de la résolution des problèmes et de tester la configuration du compte. Par exemple, utilisez PowerShell pour envoyer un message de test. Si vous ne parvenez pas à envoyer un message de test à l’aide de PowerShell, cela indique qu’il ne s’agit pas d’un problème de messagerie de base de données.

Si le courrier envoyé à partir de PowerShell échoue avec les mêmes paramètres et informations d’identification du serveur SMTP, il peut indiquer que le problème se trouve sur le serveur SMTP.

• Modifiez les paramètres suivants en fonction de votre environnement, puis exécutez le script suivant :

  $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) 
  

• Si votre serveur SMTP autorise l’authentification anonyme, utilisez le port standard 25 et ne nécessite pas SSL. Exécutez le script suivant :

  $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) 
  

Étape 6 : Vérifier les objets sysmail Service Broker

Les problèmes liés aux objets Service Broker dans msdb peuvent entraîner une opération infructueuse de la messagerie de base de données. Un problème courant est que l’une des files d’attente Service Broker (ExternalMailQueue et InternalMailQueue) est désactivée. Ce problème peut être dû à un message incohérent qui ne peut pas être envoyé correctement dans Service Broker. Par exemple, xml mal formé. Si un message ne peut pas être envoyé après cinq tentatives, il est considéré comme « poison » et la file d’attente est désactivée jusqu’à ce que le message incohérent soit supprimé. La réactivation de la file d’attente ne résout pas le problème, car le message incohérent se trouve toujours dans la file d’attente et la séquence d’échecs se répète. Pour plus d’informations sur le message incohérent, consultez Gestion des messages incohérents.

L’un des autres objets Service Broker (tels que Message Type, Contract, Serviceet Route) peut également être désactivé ou manquant. Les files d’attente Service Broker ont une procédure d’activation associée à la file d’attente. Il s’agit donc d’un point de défaillance possible. Vous pouvez vérifier la activation_procedure colonne dans msdb.sys.service_queues, puis l’utiliser sp_helptext pour vérifier s’il existe des problèmes.

Exécutez la requête suivante, puis vérifiez le contenu de la deuxième colonne des résultats de la requête.

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

Pour déterminer s’il existe des problèmes avec les objets Service Broker, il est préférable de comparer les objets à une configuration de messagerie de base de données fonctionnelle. Voici les objets que vous devez comparer à :

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

Résolution des problèmes avancés de messagerie de base de données

La résolution avancée des problèmes s’applique aux scénarios suivants :

• Lorsque vous examinez le journal de messagerie de base de données, la messagerie de base de données se bloque et la cause n’est pas entièrement expliquée. Vous voyez que le processus DatabaseMail est démarré est suivi immédiatement par un message d’exception, puis que le processus DatabaseMail s’arrête s’affiche.
• La messagerie de base de données ne démarre pas correctement. Le processus DatabaseMail n’est pas démarré dans la sysmail_event_log vue.
• La résolution initiale des problèmes ne vous aide pas à résoudre le problème.

Vous pouvez utiliser les méthodes suivantes pour la résolution avancée des problèmes de messagerie de base de données.

Regroupements pour la résolution des problèmes avancés

Pour résoudre les problèmes, vous aurez peut-être besoin d’une ou plusieurs de ces collections.

• Sauvegarde de msdb
• Journal des événements
• Trace XEvent ou SQL Server
• Moniteur de processus (Procmon)
• ProcDump
• Débogage de voyage dans le temps

Méthode 1 : Sauvegarder la base de données msdb

Il peut être utile d’interroger les vues sysmail dans un environnement distinct de la production. Dans certains cas, vous pouvez sauvegarder la base de données msdb , puis restaurer sur une autre instance. Les vues sysmail sont toutes définies avec référence à msdb. Par conséquent, même lors de l’interrogation dans la sauvegarde msdb restaurée, les vues référencent la base de données système msdb dans votre instance. Pour recréer des vues sysmail à partir de la base de données msdb de production, recréez les vues sysmail dans la base de données utilisateur à l’aide du script suivant.

/* 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

Pour plus d’informations sur les vues sysmail, consultez la section vues système sysmail.

Méthode 2 : Vérifier le journal des événements de l’application Windows

Si le programme DatabaseMail.exe externe ne peut pas se connecter à la table msdb, le programme enregistre l’erreur dans le journal des événements de l’application Windows. En outre, si DatabaseMail.exe rencontre une exception, l’exception est également enregistrée. Bien que la pile d’exceptions soit généralement identique, vérifiez le journal des événements pour déterminer si d’autres informations de pile existent.

Parfois, lorsque vous résolvez un incident de DatabaseMail.exe , vous pouvez constater que la journalisation indique qu’un vidage du rapport d’erreurs Windows a été créé comme suit :

<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:"

Vous pouvez récupérer tous les fichiers qui affichent AppCrash_DatabaseMail.exe_* dans le fichier .. Chemin d’accès \WER\ReportQueue . Consultez la section Analyse ProcDump pour obtenir des suggestions d’analyse de vidage.

Méthode 3 : Collecter et analyser XEvent ou SQL Server Trace

Vous pouvez collecter une trace des commandes Transact-SQL en cours d’exécution sur le système pour voir si l’une d’elles échoue.

Configurer l’outil PSSDiag

Vous pouvez utiliser PSSDiag pour collecter la trace XEvent ou SQL Server sous le modèle De performances générales. Comme illustré dans la capture d’écran suivante, sélectionnez certains événements supplémentaires, en particulier tous les événements broker.

Analyser la trace Xevent ou SQL

Lorsqu’une messagerie de base de données est envoyée, vous voyez généralement cinq sessions différentes (SPID) dans une capture Xevent ou Profiler.

• sp_send_dbmail : après avoir exécuté l’instruction Transact-SQL, vous voyez les événements Service Broker utilisés pour placer les messages dans la ExternalMailQueue file d’attente.

• Activation de Service Broker pour l’envoi de messages au serveur SMTP via DatabaseMail.exe. Le nom de l’application est « Activation de Microsoft SQL Server Service Broker ».

• Programme externe de messagerie de base de données : il s’agit du programme de messagerie de base de données externe qui reçoit des messages de la ExternalMailQueue file d’attente et prépare les messages à envoyer au serveur SMTP. Le nom de l’application est « DatabaseMail - DatabaseMail - ID<PID> ».

• Programme externe de messagerie de base de données : il s’agit d’une autre connexion à partir de la messagerie de base de données. Une fois que la première connexion traite les messages existants dans la ExternalMailQueue file d’attente, la connexion est créée pour écouter les messages supplémentaires à placer dans la file d’attente. S’il n’existe aucun autre message dans la file d’attente, DatabaseMail.exe se termine et ferme cette connexion.

• Activation de Service Broker pour la réception de messages de réponse à partir du serveur SMTP via DatabaseMail.exe. Il met à jour les tables sysmail pour consigner les résultats des messages envoyés.

Vous ne pouvez connaître le comportement attendu qu’en consultant la plupart des traces. La meilleure façon de connaître les différences consiste à comparer votre trace avec l’un des messages de base de données envoyés avec succès. Si vous pouvez parfois envoyer une messagerie de base de données, comparez la trace à une trace réussie, consultez la différence et recherchez les erreurs signalées par les SPID. Si vous ne pouvez pas envoyer de messagerie de base de données, comparez la trace à celle qui est envoyée avec succès dans votre environnement de test.

Méthode 4 : Capturer et analyser les événements Process Monitor

Process Monitor (Procmon) fait partie de la suite Windows Sysinternals.

Process Monitor produit une capture bruyante. Pour ne rien manquer, il est préférable d’appliquer des filtres aux données une fois qu’elles sont capturées plutôt qu’au cours du processus de capture. En règle générale, vous pouvez cibler la capture autour d’une reproduction du problème de messagerie de base de données. Par conséquent, les données globales capturées ne seraient pas trop volumineuses.

Capturer des événements de fichier, de Registre, de réseau, de processus et de thread

Lorsque vous démarrez procmon.exe, il commence à capturer des données immédiatement. L’interface graphique utilisateur est simple. Vous devez arrêter la capture des événements jusqu’à ce que vous soyez prêt à reproduire le problème. Sélectionnez Événements>de capture de fichiers (Ctrl+E) pour décocher l’élément de menu et arrêter la collection d’événements. Sélectionnez l’icône de gomme ou appuyez sur Ctrl+X pour effacer les événements déjà capturés :

Lorsque vous êtes prêt à reproduire le problème de messagerie de base de données, procédez comme suit :

1. >Sélectionnez Événements de capture de fichiers (Ctrl+E) pour démarrer la capture d’événements.
2. Essayez d’envoyer la messagerie de base de données pour reproduire le problème.
3. Sélectionnez Événements>de capture de fichiers (Ctrl+E) pour arrêter la capture d’événements.
4. Enregistrez le fichier sous *. PML.

Analyser la trace du moniteur de processus

Après avoir obtenu le . Fichier PML, ouvrez-le à l’aide de Process Monitor à nouveau. Tout d’abord, filtrez le fichier dans les processus DatabaseMail.exe et sqlservr.exe . Ensuite, sélectionnez Filtre de filtre > ... ou cliquez sur l’icône de filtre pour ouvrir le menu filtre.

Pour le nom du processus, sélectionnez sqlservr.exe et DatabaseMail.exe, puis ajoutez ces entrées :

Tout comme le cas de sql XEvent ou de la capture trace, il n’est pas immédiatement évident ce qu’il faut rechercher. En règle générale, la meilleure façon de démarrer l’analyse consiste à comparer votre trace avec une capture Procmon pour un message de base de données envoyé avec succès. Dans l’idéal, comparez la trace à un e-mail envoyé avec succès à partir du même environnement où le problème se produit. Toutefois, si aucune messagerie de base de données n’est correctement envoyée dans l’environnement spécifique, comparez la trace à un e-mail envoyé avec succès dans un autre environnement.

Lorsque DatabaseMail.exe ne parvient pas à charger une DLL ou ne trouve pas le fichier DatabaseMail.exe.config , l’analyse est utile.

Méthode 5 : Collecter et analyser le vidage d’exception à l’aide de l’outil ProcDump

ProcDump fait également partie de la suite Windows Sysinternals.

ProcDump est utile lorsque vous essayez de capturer un vidage de mémoire du programme externe DatabaseMail.exe . En règle générale, vous utilisez ProcDump pour résoudre les problèmes lorsque DatabaseMail.exe rencontre une exception non gérée.

Configurer ProcDump

Pour configurer ProcDump pour capturer un vidage de DatabaseMail.exe lors de la rencontre d’une exception non gérée, ouvrez d’abord une invite de commandes avec des privilèges d’administrateur. Ensuite, activez ProcDump pour capturer le vidage du processus de DatabaseMail.exe à l’aide de la commande suivante :

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

La sortie suivante s’affiche dans la fenêtre de commande :

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...

Ensuite, reproduisez le problème. Le vidage est créé dans le même dossier que celui dans lequel vous avez exécuté ProcDump.exe.

Analyser le vidage d’exception

Recherchez l’enregistrement d’exception et examinez la pile des appels qui mène à l’exception.

1. Ouvrez le fichier de vidage dans WinDbg (Télécharger les outils de débogage pour Windows - WinDbg - Pilotes Windows).
2. Basculez vers l’enregistrement d’exception à l’aide de la ou !analyze -v de la .ecxr commande.

Lorsque vous disposez de la pile, commencez à rechercher des problèmes connus pour une pile d’appels correspondante. Si vous avez besoin d’aide supplémentaire, contactez l’équipe CSS.

Méthode 6 : Utiliser l’outil Débogage de voyage dans le temps

La capture de débogage de voyage dans le temps (TTD) est généralement la dernière solution pour des problèmes difficiles. Vous pouvez utiliser le débogueur de préversion WinDbg pour l’obtenir. Pour obtenir des instructions et des informations complètes sur TTD, consultez Le débogage de voyage dans le temps sur son fonctionnement et la façon d’effectuer une analyse. Si vous arrivez à ce stade, vous devez contacter l’équipe CSS. Toutefois, cette section fournit des instructions sur la façon de capturer le TTD si nécessaire.

Configurer TTD

Pour plusieurs raisons, la capture TTD de DatabaseMail.exe peut être un peu difficile. Tout d’abord, DatabaseMail.exe ne s’exécute pas indéfiniment en tant que service, mais il est appelé par le processus SQL Server (sqlservr.exe). Par conséquent, vous ne pouvez pas l’attacher, mais vous devez configurer TTD à l’aide du -onLaunch paramètre pour commencer à le capturer au démarrage de DatabaseMail.exe . Deuxièmement, étant donné que DatabaseMail.exe est appelé par un autre processus, vous devez utiliser les processus enfants de débogage.