http://www.sqlservercentral.com/articles/Stairway+Series/134869/sql
SQL server 2008 中引入了Extended Events 用以替換SQL Trace。 然而在第一個版本中並無爲用戶提供UI,所以使用Extended Events並非很方便。SQL Server 2012及時修正了這一點,將UI管理工具集成在SSMS中, 這就意味着咱們不須要再爲了查詢Event XML而學習使用XQuery了。所以跟多的DBA和開發由SQL trace 和Profiler轉向了Extended Events.數據庫
這個系列教程中,咱們將詳細的介紹如何使用Extended Events做爲診斷數據收集工具,用來跟蹤SQL Server的性能問題。第一節中咱們將從一個DBA都鎖熟悉的問題開始: 使用SQL trace 跟蹤調查 long-rannning 查詢。 從基礎開始,我會介紹如何使用Extended Events 完成一樣的任務。服務器
Extended Events不只僅是一個用於替換SQL trace 和Profiler的工具。經過完整這個系列教程, 你會發現那些使用SQL trace 每每會消耗太高代價的診斷,在Extended Event 變的切實可行, 而且以前困難的,甚至不可能的跟蹤任務不但變的可行,並且更加簡單。session
SQL Trace 和Profiler 將再也不引入新功能。雖然他們爲咱們熟知,Profiler伴隨SQL Server7.0在1998 發行, 如今是時候擁抱Extended Event理解他的功能。架構
Extended Event 是一個事件收集基礎設施,最先在 SQL Server 2008 中引入。咱們可使用Extended Event 收集分析SQL server 實例和數據庫產生的不一樣種類型的診斷數據。Extended Event是SQLOS的一部分, 它由不少模塊組成,並在SQL Server啓動時被加載。它提供了大量的事件集用以替換,提高和擴展SQL Trace中的事件。app
當微軟決定使用Extened Events 替換SQL Trace時,他們從草圖開始設計了一整套event收集架構。他的目標之一就是高度的可擴展性,能夠根據需求添加新的event。與此同時微軟爲SQL Server引入一系列的Feature, 如Avaliability Groups, In-Memory OLTP和Columnstore indexes, 所以也同時爲這些Feature添加了相應的Event,用以當使用這些Feature時收集診斷數據。對於SQL Server 2012及以上版本,採用Extended Event 相當重要,由於新Featrue加入的event只能在Extened Events中找到。ide
表一中羅列的各主要SQL Server 版本中可用的Extended Event事件數量。這些是所有的事件, 包括debug 事件, 一樣這些版本中, SQL Trace 只有180個事件。 在SQL Server 2012中,SQL Trace的全部事件都有一個兼容的Extended Events事件,雖然他們並無一一對應。
SQL Server Version Number of Events Notes
工具
另外一個Extended Events設計的重要目標是儘可能減少收集數據的影響,在調查問題時減少系統額外的開銷。Extended event 使用了多種方式來達到這一目標, 咱們接下來進一步討論:sqlserver
Event最小默認負載——默認狀況下每一個事件僅收集最少的事件數據列。若是咱們但願進一步收集列,咱們必須顯示的添加「Actions」到事件中。SQL Trace的設計中默認會收集大量的負載數據,可是咱們僅僅忽略了那些不須要的數據。
強大的過濾謂詞——ExtendedEvents提供了很是細膩的過濾 經過謂詞,咱們能夠只收集那些符合特定條件的事件。咱們可使用謂詞來收集特定的事件,如每發生5次, 或者只收集某些特定的條件下的事件,如當一個的數據的值(如Duration)比之前的值大。Extended Event在事件觸發的早期一旦默認負載數據收集完成就會被過濾,這樣能夠避免任何沒必要要的數據收集過程。
Advanced Tagets—— 與SQL Trance 類似,同時支持In-Memory(Ring_bufer)和文件系統(event_file)做爲目標。 Extended events 提供了根據特定條件聚合數據選擇目標。性能
這就意味着,即便咱們設計了相對較發雜的事件會話,數據來自數據不一樣的事件,咱們只要當心的設計謂詞並選擇那些咱們須要收集的目標數據,咱們能夠很小的代價來觀察服務器。
總之,大量的事件,結合高效的過濾以及多種選項,使得Extended Event成爲一個遠遠超越Trace的事件收集器。
從個人經驗講,學習新事物最容易的方式就是從咱們已知的知識開始。下面對於 SQL Trace 和Profiler等這些你已熟知的知識介紹,將做爲咱們理解Extended Event工做方式的基礎,且並理解它與SQL Trace 和Profiler的不一樣。
對於數據庫專家,排查SQL查詢性能問題是咱們常常遇到的問題之一。之前,咱們一般會建立一個Trace用於捕捉與咱們存儲過程或SQL執行相關的事件。咱們一般會設置一些過濾條件,如超過必定數量的Reads,特定的執行時間或是消耗的CPU等。
一般打開Profiler來定義trace是一個方便快捷的方式。當咱們新建一個trace,也多是使用一些已有的模板,鏈接到SQL 實例,並選擇須要的時間。在截圖1中,咱們僅選擇了兩個事件「RPC:Completed" 和"SQL:StmtCompleted」,並捕捉了相同的數據列。
Figure 1: Selecting events and data columns for a trace
當使用Profiler或SQL Trace時,添加過濾過濾條件老是被推薦的。可是與Extended Event比,使用SQL Trace的問題之一就是晚期過濾。及時咱們定義了過濾條件,SQL Trace or Profiler 任然會收集事件實例的所有數據,而後再過濾它。固然,過濾條件依然是很是重要的,它保證了咱們的發送到客戶端或者目標文件的事件是通過過濾的。
在這個例子中,咱們添加一個過濾條件:Reads 大於等於10000,如圖2
Figure 2: Defining a trace filter on number of reads
當咱們選擇好事件和列,設置過濾,以及保存的Trace 文件後,咱們就能夠啓動Trace了。經驗豐富的DBA和開發都知道直接運行Profiler會帶來嚴重的性能問題(http://support.microsoft.com/kb/929728 ).所以爲了最小化對生產環境的影響,最好的方法是點擊開始後當即中止Trace,而後經過"File | Export | Script Trace Definition | For SQL Server 2005 – 2014"菜單導出腳本。 這樣作以後Trace將在服務器端執行而不是在 Profiler的GUI上執行。 List 1 是導出的SQL腳本。
/****************************************************/ /* Created by: SQL Server 2014 Profiler */ /* Date: 11/30/2015 08:50:44 AM */ /****************************************************/ -- Create a Queue DECLARE @rc INT DECLARE @TraceID INT DECLARE @maxfilesize BIGINT SET @maxfilesize = 5 -- Please replace the text InsertFileNameHere, with an appropriate -- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension -- will be appended to the filename automatically. If you are writing from -- remote server to local drive, please use UNC path and make sure server has -- write access to your network share EXEC @rc = sp_trace_create @TraceID OUTPUT, 0, N'InsertFileNameHere', @maxfilesize, NULL IF ( @rc != 0 ) GOTO error -- Client side File and Table cannot be scripted -- Set the events DECLARE @on BIT SET @on = 1 EXEC sp_trace_setevent @TraceID, 10, 10, @on EXEC sp_trace_setevent @TraceID, 10, 3, @on EXEC sp_trace_setevent @TraceID, 10, 12, @on EXEC sp_trace_setevent @TraceID, 10, 13, @on EXEC sp_trace_setevent @TraceID, 10, 14, @on EXEC sp_trace_setevent @TraceID, 10, 15, @on EXEC sp_trace_setevent @TraceID, 10, 16, @on EXEC sp_trace_setevent @TraceID, 10, 18, @on EXEC sp_trace_setevent @TraceID, 10, 26, @on EXEC sp_trace_setevent @TraceID, 41, 3, @on EXEC sp_trace_setevent @TraceID, 41, 10, @on EXEC sp_trace_setevent @TraceID, 41, 12, @on EXEC sp_trace_setevent @TraceID, 41, 13, @on EXEC sp_trace_setevent @TraceID, 41, 14, @on EXEC sp_trace_setevent @TraceID, 41, 15, @on EXEC sp_trace_setevent @TraceID, 41, 16, @on EXEC sp_trace_setevent @TraceID, 41, 18, @on EXEC sp_trace_setevent @TraceID, 41, 26, @on EXEC sp_trace_setevent @TraceID, 41, 61, @on -- Set the Filters DECLARE @intfilter INT DECLARE @bigintfilter BIGINT EXEC sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - f45d52c9-c0eb-45da-8bae-dc6f1a945251' SET @bigintfilter = 10000 EXEC sp_trace_setfilter @TraceID, 16, 0, 4, @bigintfilter -- Set the trace status to start EXEC sp_trace_setstatus @TraceID, 1 -- display trace id for future references SELECT TraceID = @TraceID GOTO finish error: SELECT ErrorCode = @rc finish: go
Listing 1: A server-side trace to capture poorly-performing queries
有些人之前逐句的閱讀過以上SQL Trace 腳本,也可能只是對以上腳本的功能由必定了解。 可是爲了確保咱們在同一塊兒跑線上,咱們會快速的解釋一下這段腳本。
開始的一段定義了一些用於建立Trace的存儲過程sp_trace_create 所須要的變量。做爲一個用戶,咱們首先定義了最大文件大小(這個例子中@maxfilesize設置的爲5MB)。咱們也能夠指定是否。更多關於sp_trace_create細節請查看 http://msdn.microsoft.com/en-us/library/ms190362.aspx。
輸出文件路徑也是sp_trace_create的一部分。在運行這個Trace錢,請使用一個合適的文件路徑替換InsertFileNameHere,如「C:\temp\ReadsFilter_Trace"。根據腳本的註釋,咱們不須要指定.trc後綴名。
-- Create a Queue DECLARE @rc INT DECLARE @TraceID INT DECLARE @maxfilesize BIGINT SET @maxfilesize = 5 -- Please replace the text InsertFileNameHere, with an appropriate -- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension -- will be appended to the filename automatically. If you are writing from -- remote server to local drive, please use UNC path and make sure server has -- write access to your network share EXEC @rc = sp_trace_create @TraceID OUTPUT, 0, N'InsertFileNameHere', @maxfilesize, NULL IF ( @rc != 0 ) GOTO error
Listing 2: The sp_trace_create portion of the server-side trace
根據以上定義,這個Trace會一直執行,直到咱們手動中止它。或者,咱們能夠爲sp_trace_create提供一個@datetime參數,這樣咱們就能夠限定Trace的執行時間(例如咱們能夠設置執行一個小時set @DateTime = dateadd(hh, 1, getdate())。
Trace腳本的下一段設置了咱們所須要的事件。存儲過程sp_trace_setevent添加了咱們須要捕獲的事件和列。這些使用數據來標識的事件和列並不利於閱讀。咱們一般須要MSDN(http://msdn.microsoft.com/en-us/library/ms186265.aspx))來查找每一個值得定義。一下代碼中數字10,和41分別表明RPC:Completed 和SQL:StmtCompleted事件。接下來第二列定義了數據列。例如10表示ApplicationName,3表示DatabaseID等。爲了更清晰的查看,我在源代碼上添加了註釋。
-- Set the events declare @on bit set @on = 1 exec sp_trace_setevent @TraceID, 10, 10, @on --RPC:Completed, AppName exec sp_trace_setevent @TraceID, 10, 3, @on --RPC:Completed, DatabaseID exec sp_trace_setevent @TraceID, 10, 12, @on --RPC:Completed, SPID exec sp_trace_setevent @TraceID, 10, 13, @on --RPC:Completed, Duration exec sp_trace_setevent @TraceID, 10, 14, @on --RPC:Completed, StartTime exec sp_trace_setevent @TraceID, 10, 15, @on --RPC:Completed, EndTime exec sp_trace_setevent @TraceID, 10, 16, @on --RPC:Completed, Reads exec sp_trace_setevent @TraceID, 10, 18, @on --RPC:Completed, CPU exec sp_trace_setevent @TraceID, 10, 26, @on --RPC:Completed, ServerName exec sp_trace_setevent @TraceID, 41, 3, @on --SQL:StmtCompleted, DatabaseID exec sp_trace_setevent @TraceID, 41, 10, @on --SQL:StmtCompleted, AppName exec sp_trace_setevent @TraceID, 41, 12, @on --SQL:StmtCompleted, SPID exec sp_trace_setevent @TraceID, 41, 13, @on --SQL:StmtCompleted, Duration exec sp_trace_setevent @TraceID, 41, 14, @on --SQL:StmtCompleted, StartTime exec sp_trace_setevent @TraceID, 41, 15, @on --SQL:StmtCompleted, EndTime exec sp_trace_setevent @TraceID, 41, 16, @on --SQL:StmtCompleted, Reads
Listing 3: Setting the trace events
在數據庫引擎中,Trace控制器會檢查一個事件是否須要被捕獲。若是須要則將事件的信息發送到SQL跟蹤行集提供程序,或者若是你運行的Profiler,或者是文件。在Trace發送這些信息前,全部不須要的行會被移除。例如在咱們定義的兩個事件中,咱們沒有選擇DatabaseName。然而SQL server 任然會爲這兩個時間捕捉DatabaseName列,只是它並不會被髮送到GUI或者保存在文件中。
在最後一步中,咱們使用存儲過程sp_trace_setfilter爲Trace定義了過濾條件。一個過過濾條件「SQL Server Profiler - f45d52c9-c0eb-45da-8bae-dc6f1a945251」是由腳本默認生成的,它過濾了一些由Profiler UI生成的「admin」查詢(SELECT SERVERPROPERTY )。
在這個例子中,咱們設置了一個過濾條件,只將Reads大於等於10000 (@bigintfilter = 10000)的查詢語句或存儲過程發送到目標文件中。再次提醒,這是晚期過濾,全部的事件和信息都會被捕捉。而後在發送到文件或客戶端前根據篩選條件移除。
-- Set the Filters DECLARE @intfilter INT DECLARE @bigintfilter BIGINT EXEC sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - f45d52c9-c0eb-45da-8bae-dc6f1a945251' SET @bigintfilter = 10000 EXEC sp_trace_setfilter @TraceID, 16, 0, 4, @bigintfilter
Listing 4: Setting the trace filter
腳本的最後一段使用存儲過程sp_trace_setstatus 啓動Trace,並顯示TraceID。這個惟一的TraceID用於中止Trace,也能夠用於刪除Trace定義。
-- Set the trace status to start EXEC sp_trace_setstatus @TraceID, 1 -- display trace id for future references SELECT TraceID = @TraceID GOTO finish error: SELECT ErrorCode = @rc finish: go
Listing 5: Starting the trace
若是咱們執行了這個腳本,Trace將被啓動並將持續的運行和收集事件數據,直至咱們中止它。如今,咱們怎麼將這些所熟知的技能,使用Extended Event替代呢?
將已經存在的Trace文件定義轉換爲事件會話,我推薦的方式 使用一個存儲過程,他的做者是 Jonathan Kehayias。 你能夠從(https://www.sqlskills.com/blogs/jonathan/converting-sql-trace-to-extended-events-in-sql-server-2012/)下載這個腳本,名爲"sp_SQLskills_ConvertTraceToExtendedEvents"。 這個腳本只能在SQL Server 2012及之後版本運行,覺得SQL Server 2012之前的版本Extended Events並不支持全部的Trace事件。
手動轉換Trace到Extended Events會話
若是因爲某些緣由你不能使用以上存儲過程,微軟文檔介紹了一個手動轉換過程:Convert an Existing SQL Trace Script to an Extended Events Session (https://msdn.microsoft.com/en-us/library/ff878114.aspx)
在你的SQL實例中執行以上腳本用於建立這個存儲過程。執行這個存儲過程僅須要輸入如下參數,如Listing 6 所示。
EXECUTE sp_SQLskills_ConvertTraceToExtendedEvents @TraceID = 2, @SessionName = 'XE_ReadsFilter_Trace', @PrintOutput = 1, @Execute = 0;
Listing 6: Converting a server-side trace to use Extended Events
參數@TraceID 是你要轉換爲Extended event 的Trace ID。於是,這個Trace必須存在,不管正在執行與否。在這裏TraceID爲2(從Listing 5的執行結果中得到)。
執行這個存儲過程爲ReadsFilter_Trace.trc Trace生成Extended Event會話DLL腳本,如Listing7所示:
IF EXISTS ( SELECT 1 FROM sys.server_event_sessions WHERE name = 'XE_ReadsFilter_Trace' ) DROP EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER; GO CREATE EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER ADD EVENT sqlserver.rpc_completed ( ACTION ( sqlserver.client_app_name -- ApplicationName from SQLTrace , sqlserver.database_id -- DatabaseID from SQLTrace , sqlserver.server_instance_name -- ServerName from SQLTrace , sqlserver.session_id -- SPID from SQLTrace -- EndTime implemented by another Action in XE already -- StartTime implemented by another Action in XE already ) WHERE ( logical_reads >= 10000 ) ), ADD EVENT sqlserver.sql_statement_completed ( ACTION ( sqlserver.client_app_name -- ApplicationName from SQLTrace , sqlserver.database_id -- DatabaseID from SQLTrace , sqlserver.server_instance_name -- ServerName from SQLTrace , sqlserver.session_id -- SPID from SQLTrace -- EndTime implemented by another Action in XE already -- StartTime implemented by another Action in XE already ) WHERE ( logical_reads >= 10000 ) ) ADD TARGET package0.event_file ( SET filename = 'C:\temp\XE_ReadsFilter_Trace.xel' , max_file_size = 5 , max_rollover_files = 1 ) GO
Listing 7: The Extended Events event session
與咱們分析由Profiler生成的服務器端Trace腳本同樣,咱們會經過不一樣的段落逐步分析Extended Events事件會話是如何建立的。
腳本首先包含了一個IF段落聲明,用於檢查是否有同名事件會話存在,若是存在則刪除它。這樣能夠避免在建立事件會話時出現錯誤。
IF EXISTS ( SELECT 1 FROM sys.server_event_sessions WHERE name = 'XE_ReadsFilter_Trace' ) DROP EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER; GO
Listing 8: Checking for the existence of an event session with the same name
這段腳本接着使用CREATE EVENT SESSION 語法建立了一個事件會話(http://msdn.microsoft.com/en-us/library/bb677289.aspx)。這點與第一部分中使用sp_trace_create穿件Trace腳本類似,可是參數不徹底同樣。
/* Extended Events */ CREATE EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER |
-- Create a Queue DECLARE @rc INT DECLARE @TraceID INT DECLARE @maxfilesize BIGINT SET @maxfilesize = 5 -- Please replace the text --InsertFileNameHere…etc… EXEC @rc = sp_trace_create @TraceID OUTPUT, 0, N'InsertFileNameHere', @maxfilesize, NULL IF ( @rc != 0 ) GOTO ERROR
|
Listing 9: Create the event session
接下來,Extended Events腳本使用CREATE EVENT SESSION 的 ADD EVENT 子句指定了第一個事件,此處爲 rpc.completed事件,而且接下來指定了事件觸發時執行的一些額外動做,這個例子中爲收集額外的四個事件數據列。
/*Extended Events*/ ADD EVENT sqlserver.rpc_completed ( ACTION ( sqlserver.client_app_name , sqlserver.database_id , sqlserver.server_instance_name , sqlserver.session_id )
|
/* Trace */ -- Set the events declare @on bit set @on = 1 exec sp_trace_setevent @TraceID, 10, 10, @on exec sp_trace_setevent @TraceID, 10, 3, @on exec sp_trace_setevent @TraceID, 10, 12, @on exec sp_trace_setevent @TraceID, 10, 13, @on exec sp_trace_setevent @TraceID, 10, 14, @on exec sp_trace_setevent @TraceID, 10, 15, @on exec sp_trace_setevent @TraceID, 10, 16, @on exec sp_trace_setevent @TraceID, 10, 18, @on exec sp_trace_setevent @TraceID, 10, 26, @on
|
Listing 10: Adding actions
這裏有幾處Extended Events和Trace關鍵的不一樣點須要指出。第一,注意事件名和Actions中收集的數據列(如:client_app_name, database_id),他們是文本。咱們不須要再查詢哪些數字對應的事件或者數據列!與SQL Trace相比,書寫閱讀Extended Events腳本變的更加簡單。
其次,注意Extended Events腳本中並無指定所有的數據列。事實上,許多數據列被定義爲事件的默認負載被收集。咱們顯然不須要在腳本中指定這些默認列。可是咱們可使用UI來查看事件的默認負載由哪些列組成, 咱們會在下一階教程中講解。
這是Trace 和Extended Events一個重要的行爲不一樣。SQL Trace 默認行爲是收集全部可能有用的列。而後由用戶過濾任何不須要的信息。Extended Events 更加高效,每一個事件有一組由最少的數據列組成的默認負載,在事件出發時總會被默認收集。若是咱們須要收集任何再也不默認負載中的列,咱們須要以Actions方式添加他們。例如,在RPC:Completed事件中添加的Actions:client_app_name, database_id, server_instance_name 和session_id, 他們都不屬於事件的默認負載。收集這些Actions是可選的。
由於只有默認負載事件列會被包含在時間中,所以初始化事件收集的開銷相對較小。Actions數據收集是在謂詞過濾後才發生的,所以收集大量的Actions,或者高消耗的Actions(如內存Dump),都會增長Extended Events會話的消耗。於是,審慎的選擇額外的數據收集對捕獲事件尤其重要。咱們會在下一階中詳細討論這個主題。
在選擇過事件和額外的Actions後,接下的一段定義了過濾器。
/* Extended Events */ WHERE ( logical_reads >= 10000 ) |
/* Trace */ -- Set the Filters declare @intfilter int declare @bigintfilter bigint exec sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - f45d52c9-c0eb-45da-8bae-dc6f1a945251' set @bigintfilter = 10000 exec sp_trace_setfilter @TraceID, 16, 0, 4, @bigintfilter
|
Listing 11: Adding a filter
回憶下當咱們使用Profiler定義trace時,咱們使用了Sp_trace_setfilter設置了一個過濾,排除全部小於10000Reads的事件數據。在事件會話定義中,這個過濾,術語爲謂詞,是一個簡單的WHERE子句。
Extended Events執行早期過濾。換句話說,在事件基礎數據收集后里當即執行謂詞,只有符合過濾條件的事件實例纔會被觸發。這種工做機制與SQL Trace和Profiler的晚期過濾相比,在數據收集時的開銷更小。
此時rpc_completed 事件已經配置完成。添加其餘的事件僅需使用ADD EVENT子句再次添加,如Listing12所示的添加sql:statement_completed事件。
ADD EVENT sqlserver.sql_statement_completed( ACTION ( sqlserver.client_app_name -- ApplicationName from SQLTrace , sqlserver.database_id -- DatabaseID from SQLTrace , sqlserver.server_instance_name -- ServerName from SQLTrace , sqlserver.session_id -- SPID from SQLTrace -- EndTime implemented by another Action in XE already -- StartTime implemented by another Action in XE already ) WHERE ( logical_reads >= 10000 )
Listing 12: Adding a second event to the event session
再次,咱們能夠選擇額外的數據列。Extended Events的靈活性在於咱們能夠爲每一個事件設置相同或是不一樣的過濾條件。這點在Trace中沒法作到,過濾條件對於全部事件生效。另外在Extended Events中咱們能夠設置更多強大的過濾條件,如咱們可使用AND和OR條件,在此咱們不作過多討論。
在添加全部事件後,咱們使用ADD TARGET 來指定輸出目標,SQL Server將收集的數據以及相關的Actions寫入目標。在Trace中咱們能夠選擇輸出至文件,或者試試寫入Profiler,雖然不被推薦。在Extended Events咱們也有多個目標能夠選擇,包括最基本內存存儲(ring_buffer)和文件系統存儲(event_file),同時又一些高級的目標能夠提供數據聚合功能。
在這個例子中,咱們將使用event_file做爲目標,這點與Trace輸出至.trc文件相似,可是咱們須要在文件中指定文件擴展名。
/* Extended Events */ ADD TARGET package0.event_file ( SET filename = 'C:\temp\XE_ReadsFilter_Trace.xel', max_file_size = 5, max_rollover_files = 1 ) |
/* Trace */ -- Create a Queue declare @rc int declare @TraceID int declare @maxfilesize bigint set @maxfilesize = 5 exec @rc = sp_trace_create @TraceID output, 0, N'InsertFileNameHere', @maxfilesize, NULL if (@rc != 0) goto error Listing 13: Specifying the target for the event session |
Listing 13: Specifying the target for the event session
一樣咱們能夠設置文件大小,以及咱們能夠設置建立的滾動跟新文件數量
最後,在咱們的會話定義中,咱們還有許多可選的會話配置項,如最大內存大小以及調度延遲。由於咱們在腳本中沒有指定這些選項,所以會使用默認值。會話設置會在下一階中詳細討論。
若是咱們再花一分鐘回顧一下整個Extended Events會話定義,你會發現它很是直觀並且對於這個DDL每一部分的理解不會有任何困難。
與Trace同樣,Extended Event會話不會被默認啓動。爲了啓動一個會話,咱們須要使用Listing 14中所示的ALERT語句。
ALTER EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER STATE=START; GO
Listing 14: Starting the event session
執行啓動後,咱們能夠運行一段腳原本驗證Extended Events是否已經啓動。
/* Extended Events */ SELECT [es].[name] AS [EventSession], [xe].[create_time] AS [SessionCreateTime], [xe].[total_buffer_size] AS [TotalBufferSize], [xe].[dropped_event_count] AS [DroppedEventCount] FROM [sys].[server_event_sessions] [es] LEFT OUTER JOIN [sys].[dm_xe_sessions] [xe] ON [es].[name] = [xe].[name]; GO |
/* Trace */ SELECT [id] AS [TraceID], CASE WHEN [status] = 0 THEN 'Not running' WHEN [status] = 1 THEN 'Running' END AS [TraceStatus], [start_time] AS [TraceStartTime], [buffer_size] AS [BufferSize], [dropped_event_count] AS [DroppedEventCount] FROM [sys].[traces]; GO |
Listing 15: Check to see which event sessions and traces are running
在這個例子裏,咱們能夠看到Figure 3中的輸出,他們顯示了咱們所建立的用戶事件會話和Trace,一樣,事件會話和Trace已經被啓動了。
就像Trace由一個默認直至執行的Trace(TraceID =1), Extended Evetns也有system_health 事件會話,這個與默認Trace並不徹底同樣。咱們在下階中再看system_health 會話。若是你使用了Availability Groups (AG),也會有一個AlwaysOn_health 會話一直執行,來收集AG相關的信息以及故障檢測事件。
Figure 3: Which traces and event sessions are running?
在咱們啓動了Trace和Session後,咱們可使用ALTER SESSION來中止事件會話,使用sp_trace_setstatus中止Trace。
/* Extended Events */ ALTER EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER STATE=STOP; GO |
/* Trace */ DECLARE @TraceID INT = 2; EXEC sp_trace_setstatus @TraceID, 0; GO |
Listing 16: Stopping the extended events session and trace
此時,沒有數據被收集,可是咱們定義的Trace和事件會話都還在,咱們能夠根據需求再次啓動他們,或者將他們的定義徹底刪除。
/* Extended Events */ DROP EVENT SESSION [XE_ReadsFilter_Trace] ON SERVER; GO |
/* Trace */ DECLARE @TraceID INT = 2; EXEC sp_trace_setstatus @TraceID, 2; GO |
Listing 17: Removing the extended events session and trace definition
咱們並不推薦在事件會話完成後將它刪除。也許不少人有在使用Trace時有這個習慣,在Trace中當SQL實例被重啓後,除了默認Trace其餘Trace定義會所有丟失。這個也是Extended Events與Trace重要的不一樣點:會話定義會做爲元數據保存在服務器中,而且會被持久化。建立過事件會話後,你就能夠根據須要啓動或中止它了。
你如今已經知道如何將SQL Trace 的知識映射到Extended Events中了,咱們可使用T-SQL達到咱們的目標。咱們下一步將詳細的看一下DDL, 而且轉向Extended Events的UI。咱們在一下階中解決這些問題。