# Sql Profiler 每日自動側錄滿足特定過濾條件SQL

背景說明如下，資料庫有效能問題，無法長時間遠端開著 Sql Profiler 進行追蹤，處理方式改用 Sql 排程與 sp_trace_create 追蹤每日 08:00~18:30 間系統 duration > 1000ms 的 SQL 查詢，

大略操作如下:

* 新增 SQL 排程於每日 08:00 執行.
* 執行內內容如大略如附件 SQL，附件SQL 可以用 Sql Profiler 設定好錄製的條件然後匯出在手動做一些修正.

* `SQL追蹤.sql` 摘要說明:

declare @rc int;
declare @TraceID int;

/*設定 trc 上限 100MB */
declare @maxfilesize bigint = 100;

/*
動態使用日期產生要 存放的路徑檔名 這樣就可以達到一天一個 trc 檔，方便識別也避免單一檔案太大
我這邊用的路徑是 /var/MsSqlBackUp/ 是因為這是一臺跑在 Linux 上的  MSSQL ,
如果 Windwos 可能是 C:\... 或 S:\ 看實際主機環境而定.
*/
declare @tracefile nvarchar(256) = '/var/MsSqlBackUp/' + CONVERT(VARCHAR(8), GETDATE(), 112) + '_' +  Replace(CONVERT(VARCHAR(5), GETDATE(), 114),':','');

/* 動態設定追蹤停止於 18:30 停止
   當時間到 18:30 或者 trc 達到 100MB 這個追蹤就會停止
*/
declare @stoptime  datetime = convert(nvarchar(10),getdate(),121) + ' 18:30';

.................... 略

這邊會有很多類似下面的指令，基本要不就查文件要不就透過 Sql Profiler  設定好匯出，不然光看那些數字應該很難猜是哪一個追蹤項目
exec sp_trace_setevent @TraceID, 10, 11, @on

.................... 略

-- Set the Filters
declare @bigintfilter bigint

/*
設定 duration > 1000ms 的 SQL 查詢才記錄下來，畢竟般追效能先不管 Disk I/O ,或者 CPU 消耗高的，基本上都會讓回應時間變長，所以一般會先從 duration 作基本的過濾，
不然 trc 的太多一方面加 Disk I/O 的負擔，也增加未來的分析跟閱讀 trc 的負擔.
至於要 > 3000ms > 2000ms > 1000ms 多少才合理沒有絕對標準，也許一開始很慘的時候先從 3000 跳...
先把大條的處理完再逐步往下追蹤下去.
*/
set @bigintfilter = 1000*1000 /* 10,000 是 10ms*/
exec sp_trace_setfilter @TraceID, 13, 0, 4, @bigintfilter

.................... 略.