從監控工具DPA中發現一個資料庫（SQL Server 2008 R2）的等待事件突然彪增，下鑽分析發現資料庫執行存儲過程sp_MailItemResultSets時，引起了非常嚴重的等待(High Wait)，而主要的等待事件為PREEMPTIVE_OS_WAITFORSINGLEOBJEC。 如... ...
從監控工具DPA中發現一個資料庫（SQL Server 2008 R2）的等待事件突然彪增，下鑽分析發現資料庫執行存儲過程sp_MailItemResultSets時，引起了非常嚴重的等待(High Wait)，而主要的等待事件為PREEMPTIVE_OS_WAITFORSINGLEOBJEC。 如下截圖所示:
查詢正在執行的SQL，發現會話正在執行下麵SQL(存儲過程sp_MailItemResultSets中的一個SQL語句)，等待事件為ASYNC_NETWORK_IO。
USE msdb;goSELECT 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
關於ASYNC_NETWORK_IO與PREEMPTIVE_OS_WAITFORSINGLEOBJEC的關係如下：
這個等待事件表示一個線程正在向外部客戶端進程同步某個對象的數據，因此出現此種等待。而且通常和ASYNC_NETWORK_IO等待事件同時出現。根據我的觀察，查詢正在執行的SQL，等待事件為”ASYNC_NETWORK_IO“而並非”PREEMPTIVE_OS_WAITFORSINGLEOBJEC“
關於這個等待事件的更多詳細信息，具體見鏈接“PREEMPTIVE_OS_WAITFORSINGLEOBJECT”，當前資料庫版本為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 ： 以下示例刪除資料庫郵件系統中的所有電子郵件*******************************************************************************************************/DECLARE @GETDATE datetime SET @GETDATE = GETDATE(); EXECUTE msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @GETDATE; GO
最後清理過後驗證發現，這個存儲過程的確非常快了，資料庫中該等待事件直接消失了。系統應用日誌中關於Mail PID的錯誤也消失了。後續觀察發現，這個表也變得特別小了，完全沒有之前那麼大了。
