使用探查器跟踪中的 EventSequence

我們有一個sp_foo包含動態 sql 的儲存過程，並在動態 sql 結束時sp_foo使用EXECUTE (@query)

在分析跟踪配置文件時，我注意到事件序列 (ES)、開始和結束時間與我的預期不符。

Row   EC   ES     Start_Time    End_Time    D_ms  SQL
C     45   1293   44.240        45.603      1363  Select ...
D     45   1294   43.737        45.603      1866  execute (@query)
E     12   1296   43.730        45.600      1871  execute sp_foo @id=34

問題

• 為什麼E有最高的EventSequence( ES=1296)，先開始，先結束？
• 為什麼C的start_time最晚，EventSequence( ES=1293)最低

我使用了這個查詢

Select EventClass as EC, EventSequence as ES
   , Duration/1000 as duration_ms
   , convert(time, StartTime) as [Start_Time]
   , convert(time, EndTime) as [End_Time]       
   ....
From TraceImport
WHERE EventClass in (10, 12, 45)

更新以評論第一個答案

Gareth 指出我的事件序列可能從高到低執行。我相信現在還不是這樣

• 我的 Eventsequence 值是遞增的（後來 start_time == 更高的 ES 值）
• 我的 ES 編號在 2.73E7 範圍內；根據SQL Server Planet Bigint Max Value ，SQL Server 中 Bigint的最大值為 8 個字節，從：-9223372036854775808到：9223372036854775807如果我沒記錯的話，這意味著我的 ES 值必須在9.2E17或9.2E18

因此，我認為尚未達到 bigint。我們使用的是2008R2 版本 10.50.4339.0

根據跟踪事件序列列的重要性和 SQL Server 2005 SP2 更改

SQL Server 2005 附帶一個儲存在 LONG 中的事件序列。

$$ The MSFT $$支持人員已經看到一些痕跡，其中超出了有符號長整數的邊界並且事件序列變為負數。

SQL Server 2005 中的事件序列從 0 計數到最大值大整數長，然後從那裡再次下降到 0。

"Step 1:  Count up from 0 to 0x7FFFFFFFF
Step 2:  Count down from 0x7FFFFFFF to 0

Start at step 1 again."

SQL Server 2005 SP2 將列擴展為 LONGLONG（有符號 64 位整數）

所以我猜你目前處於第 2 步。

由於這三個操作彼此在 3 毫秒內結束，在我看來，前兩個操作只是能夠比第三個快一點點結束並報告它們的完成。（請注意，End_Time 是操作的結束時間，而不是記錄操作的時間，會稍晚一些。）

注意 E 行是唯一的儲存過程呼叫。結束這樣的電話可能會有更多的成本。

引用自：https://dba.stackexchange.com/questions/164690