Found a database (SQL Server 2008 R2) wait events suddenly Biao increase, drill analysis found that the database stored procedure is executed sp_MailItemResultSets from monitoring tools DPA, causing very serious wait (High Wait), and the main waiting for events to PREEMPTIVE_OS_WAITFORSINGLEOBJEC . As shown in the screenshot below:
SQL query is executed, discovery session is executing the following SQL (stored procedures sp_MailItemResultSets in a SQL statement), waiting for something to ASYNC_NETWORK_IO.
USE msdb;
go
SELECT
mi.mailitem_id,
mi.profile_id,
(SELECT name FROM msdb.dbo.sysmail_profile p WHERE p.profile_id = mi.profile_id) as 'profile_name',
mi.recipients,
mi.copy_recipients,
mi.blind_copy_recipients,
mi.subject,
mi.body,
mi.body_format,
mi.importance,
mi.sensitivity,
ISNULL(sr.send_attempts, 0) as retry_attempt,
ISNULL(mi.from_address, '') as from_address,
ISNULL(mi.reply_to, '') as reply_to
FROM sysmail_mailitems as mi
LEFT JOIN sysmail_send_retries as sr
ON sr.mailitem_id = mi.mailitem_id
WHERE mi.mailitem_id = @mailitem_id
About ASYNC_NETWORK_IO and PREEMPTIVE_OS_WAITFORSINGLEOBJEC relationship is as follows:
This event indicates that a thread is waiting for synchronizing data in one object to the external client process, so there such a wait. And usually wait and ASYNC_NETWORK_IO events occur simultaneously. According to my observation, SQL queries being executed, waiting for the event to " ASYNC_NETWORK_IO " rather than " PREEMPTIVE_OS_WAITFORSINGLEOBJEC "
Waiting for more details on this event, see the specific link " PREEMPTIVE_OS_WAITFORSINGLEOBJECT " , the current version of the database is SQL Server 2008R2
Description:
This wait type is when a thread is calling the Windows WaitForSingleObject function for synchronization with an external client process that is communicating using that object.
Other information:
This wait type is commonly seen in conjunction（同时出现） with ASYNC_NETWORK_IO, depending on the network transport used to communicate with the client, so to troubleshoot, follow the same steps as for ASYNC_NETWORK_IO.
Note that when a thread calls out to Windows, the thread changes from non-preemptive (SQL Server controls the thread) to preemptive (Windows controls the thread) mode. The thread’s state will be listed as RUNNING, as SQL Server doesn’t know what Windows is doing with the thread.
确实是一个非常奇怪的现象，然后我又去检查系统的应用日志，结果发现大量的错误：
错误信息比较奇怪，让人摸不着头脑，也没有看到有相关资料介绍，主要有下面两种错误：
1：Database Engine Instance=xxxxx;Mail PID=7248;Error Message:The connection is not open.
2: Database Engine Instance=xxxxx;Mail PID=7248;Error Message:Exception of type 'System.OutOfMemoryException' was thrown.
验证SQL语句性能， 发现SQL语句的确非常慢，从执行计划来看，没有什么异常情况，而且这个也是系统数据库，不应该存在一些索引问题。
但是检查dbo.sysmail_mailitems表，发现此表记录数为2722，但是表的大小接近8G了。非常不正常。对比了其它几个数据库服务器，发现这个表非常小。检查邮件记录里面是否有大量附件。也没有发现有大量附件。
处理问题的时候，没去定位是那条或那些记录占用了大量空间。急着解决问题，放弃分析这些情况了。可惜了！
官方也没有相关资料，只能猜测是因为dbo.sysmail_mailitems的大小引起了性能问题，然后我尝试用下面SQL清理这个表的记录
/******************************************************************************************************
Script Function ： 以下示例删除数据库邮件日志中所有失败的电子邮件
*******************************************************************************************************/
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp
@sent_status = 'failed' ;
GO
/******************************************************************************************************
Script Function: The following example deletes all e-mail messages database system
*******************************************************************************************************/
DECLARE @GETDATE datetime
SET @GETDATE = GETDATE();
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @GETDATE;
GO
Finally, after the clean-up verification we found that the stored procedure is indeed very fast, database wait events that directly disappeared. System Application log on Mail PID error disappeared. Follow-up observations, this table has become very small, and there is no so big before.
