文章出處

SQLSERVER2012里的擴展事件初嘗試（下）

SQLSERVER2012里的擴展事件初嘗試（上）

我們繼續文章擴展事件在Denali CTP3里的新UI（二）里的這個實驗

腳本文件下載：http://files.cnblogs.com/lyhabc/instnwnd.rar

我們打開上篇創建的blogtest擴展事件會話的屬性

檢查一下sql_statement_starting事件和sql_statement_completed事件的謂詞是不是database_name=’Northwind’

運行workload

大家可以看到instnwnd.sql這個文件是比較大的，執行的時候會產生一些workload

我們啟動blogtest會話

然后執行instnwnd.sql腳本

如果你的機器運行這個腳本很長時間，你可以點擊工具欄的“停止數據反饋”，SSMS會停止繼續顯示實時數據

實時數據窗口可能只有兩個列name和timestamp，這是僅有的2個所有擴展事件共有的列

你可以選擇工具欄上的選擇列按鈕，添加/刪除需要顯示的列

我增加了3個列database_name，duration和statement

我們要找到Northwind數據庫里平均執行時間最長的query，首先我們可以過濾不必要的事件

上篇曾提到過謂詞可以在SQL Server端避免不需要的事件被產生，我們同時也支持客戶端的過濾器，這可以幫助你做各種分析

點擊工具欄上的篩選器按鈕，這將打開篩選器對話框

這里我們設置兩個條件name=sql_statement_completed And database_name=Northwind

為了避免輸入錯誤，你可以從事件列表里拷貝粘帖，你還可以右鍵點擊某個單元格，然后選擇Filter by this Value，

這將自動為你添加一個子句并And到原有條件上

設置完畢之后點擊確定

過濾掉不必要的事件后我們按照statement來做分組，點擊工具欄上的分組按鈕

把statement移動到右邊，點擊確定

分組的目的是為了計算每個分組上duration的平均值，下面可以點擊工具欄上的聚合按鈕

我們在duration上聚合類型選擇AVG

然后選擇在duration(AVG)上按降序排序

這樣duration平均值最大的分組將被顯示在第一行

我執行instnwnd.sql的workload里duration最大的分組是“exec master.dbo.sp_MSdbuserpriv N'serv'”

它的duration是13610微秒，這樣我們就找到了平均開銷最大的query

我們用單位換算器換算一下

你可以通過打開-》合并擴展事件文件-》來打開生成的xel文件

總結

大家一定會好奇，為什麼在創建事件會話的時候會有篩選器，在SSMS工具欄又有篩選器

其實擴展事件是屬于SQLSERVER端的，把SQLSERVER profiler的功能搬到SQLSERVER端，當然不是簡單的搬到SQLSERVER端

而SSMS的工具欄只是提供一些分析xel文件的工具，這些跟SQLSERVER profiler是差不多的

比如人家給你一個xel文件，你需要SSMS的擴展事件工具欄的工具去分析

而以前SQLSERVER profiler是屬于客戶端的（是一個客戶端工具），profiler獲取SQLSERVER端的各種事件，然后傳送回客戶端，

在SQLSERVER profiler界面上顯示給大家

所以大家可以理解為擴展事件就是把SQLSERVER profiler的功能集成到SQLSERVER端，反正我是這樣理解的，不過這個集成不是簡單的集成

擴展事件讀取的三種方法對比

這一章節介紹三種審計日志分析方法的對比，我們將會從以下幾個角度來衡量這三種方法：

DMF
sys.fn_xe_file_target_read_file是SQL Server本身內置的對象，所以使用這種方法分析審計日志信息，無需過多的編程處理，門檻較低，甚至可以直接使用SSMS都可以分析審計日志文件。這些是使用DMF分析審計日志的優點。當然，這個方法的缺點也很明顯：使用DMF方式讀取審計日志，需要連接到SQL Server服務，所以要求SQL Server服務本身是啟動的，因為這個是使用SQL Server內置的動態管理函數來實現的；而且這種分析方法需要使用SQL Server對XML操作技術來解析event_data，解析XML是一個CPU密集型操作，非常消耗系統CPU資源。在我之前的測試案例中，使用DMF方法分析審計日志詳情導致了50%多的額外CPU開銷。如下截圖所示：

XEReader API
使用SQL Server XEReader提供的API讀取審計日志文件的方法，完全是基于審計日志文件的操作方式，可以獨立于SQL Server的服務。換句話說，不管SQL Server是處于關閉還是啟動狀態，對我們審計日志的分析不會受到任何影響。這些是使用XEReader API分析審計日志的優點。而這個方法也有它的缺點：當我們分析當前（正在被Extend Event Session對象寫入的日志文件）審計日志文件時，我們不知道（或者很難知道）哪些記錄是我們分析過的，哪些是還未分析的？如果這個問題解決不了的話，很可能就會導致審計日志記錄的重復或者丟失。當然，我們也可以采用XE循環寫入審計日志文件的方法，每次讀取Archive出來的審計日志文件，跳過當前文件的讀取，等待當前文件寫滿固定大小，Archive出來以后，再來讀取分析。這個改進方法會引入另外一個問題是，可能會導致審計日志的分析延遲，而且延遲的時間還不確定。比如：用戶查詢在10分鐘后才寫滿當前審計日志文件，那么延遲是10分鐘；如果用戶查詢在1個小時之內才寫滿當前審計日志文件，那么延遲將是1個小時。

事件流讀取
基于用戶查詢事件流式分析審計日志的方法，優點也特別明顯：延遲非常小，可以控制在秒級內，實時性表現良好，它解決了XEReader API查詢事件延遲的問題。然而缺點是：也需要依賴SQL Service的啟動狀態，否則會報告異常；在大量查詢瞬間（短時間內）執行的時候（比如用戶不小心寫了一個死循環查詢），重啟SQL Service或者Extend Event Session狀態時，根據我測試的情況來看，這種場景會導致審計日志記錄丟失，可靠性得不到保證。
最后總結

基于以上三種審計日志分析方法的優缺點總結來看，我們綜合打分匯總如下：
DMF：對SQL Service有依賴，得分0；延遲取決于Offset的移動效率，得分80；穩定性有保證，得分100；對SQL Server CPU影響較大，得分為0；
XEReader API：對SQL Service無依賴，得分100；延遲取決于查詢產生的速度，得分50；穩定性有保證，得分100；對SQL Server 影響很小，得分為0；
XEReader Stream：對SQL Service有依賴，得分0；延遲非常低，得分100；有不穩定的場景存在，得分50；對SQL Server 影響較小，得分為100；

阿里云內核月報：http://mysql.taobao.org/monthly/2017/08/08/