SQL Server 2008 R2執行存儲過程sp_MailItemResultSets引發大量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;

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

 

 

 

關於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的錯誤也消失了。後續觀察發現，這個表也變得特別小了，徹底沒有以前那麼大了。