データベースを発見した（SQL Server 2008 R2の）待機イベントが突然彪の増加は、ドリル分析では、データベースのストアドプロシージャは非常に深刻な待機（High待ち）、及びPREEMPTIVE_OS_WAITFORSINGLEOBJECへのイベントのための主要な待機を引き起こし、監視ツールDPAからsp_MailItemResultSetsを実行していることがわかりました。下のスクリーンショットに示すように：
SQLクエリは発見セッションがASYNC_NETWORK_IOに何かを待って、次のSQL（SQL文のストアドプロシージャのsp_MailItemResultSets）を実行され、実行されます。
USE MSDB。
行きます
選択する
mi.mailitem_id、
mi.profile_id、
（SELECT名FROM msdb.dbo.sysmail_profile P WHERE p.profile_id = mi.profile_id）として '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）として retry_attempt、
ISNULL（mi.from_address、'' ）として FROM_ADDRESS、
ISNULL（mi.reply_to、'' ） として REPLY_TO
FROM sysmail_mailitems として MI
LEFTは 、JOIN sysmail_send_retries として SRを
ON sr.mailitem_id = mi.mailitem_id
WHERE mi.mailitem_id = @mailitem_id
ASYNC_NETWORK_IOとPREEMPTIVE_OS_WAITFORSINGLEOBJEC、次のような関係は以下のとおりです。
このイベントは、スレッドがそうそこに、外部のクライアントプロセスにあるオブジェクト内のデータを同期させるため、このような待ち時間を待っていることを示しています。そして、通常は待機してASYNC_NETWORK_IOイベントが同時に発生します。私の観察によると、SQLはにイベントを待って、実行されたクエリ「ASYNC_NETWORK_IO 」ではなく「PREEMPTIVE_OS_WAITFORSINGLEOBJEC 」
このイベントの詳細を待って、特定のリンクを参照「PREEMPTIVE_OS_WAITFORSINGLEOBJECTを」、データベースの現在のバージョンは、SQL Serverの2008R2です
説明：
スレッドは、Windows呼び出しているとき、この待機の種類はあるのWaitForSingleObjectそのオブジェクトを使用して通信している外部のクライアントプロセスと同期する機能を。
その他の情報：
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
/******************************************************************************************************
スクリプト関数：次の例では、すべての電子メールメッセージのデータベースシステムを削除します
************************************************** ************************************************** *** /
DECLAREの @GETDATE日時
SET @GETDATE = GETDATE（）;
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @GETDATEを。
GO
最後に、クリーンアップ我々検証した後、ストアドプロシージャは、非常に高速な確かに直接姿を消したデータベース待機イベントであることがわかりました。上のシステムアプリケーションログメールPIDのエラーは消えました。フォローアップの観察は、このテーブルは非常に小さくなっていない、と何の前それほど大きくありました。
