使用過濾器減少SQL跟蹤的開銷

Question

我們有一個SQL 2000服務器，它具有在一天中的不同時間或甚至一個月中的不同日期運行的各種各樣的作業。通常情況下，我們只使用SQL事件探查器在很短的時間內運行蹤跡以進行性能故障排除，但在這種情況下，實際上並不能讓我很好地瞭解在數據庫上運行的查詢類型一天或一週或一個月的過程。

如何最小化長時間運行的SQL跟蹤的性能開銷？我已經知道：

• 執行跟蹤服務器端（sp_create_trace），而不是使用SQL Profiler UI。
• 跟蹤到文件，而不是數據庫表（這會給DB服務器增加額外的開銷）。

我的問題真的是關於過濾器。如果我添加一個過濾器來只記錄運行超過一定時間或讀取的查詢，它仍然需要檢查服務器上的所有活動以決定是否需要記錄它，對吧？因此，即使使用該過濾器，對於已經處於不可接受性能邊緣的服務器而言，跟蹤是否會造成不可接受的開銷水平？

Answer 1

我發現，其實衡量一個SQL事件探查器會話的性能影響VS服務器端跟蹤的文章：

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

這真的是我的根本問題，如何確保在跟蹤過程中不會讓我的生產服務器停滯不前。看起來如果你做得對，那麼開銷很小。

Answer 2

添加過濾器的確最大限度地減少了事件收集的開銷，並且還可以防止服務器記錄您不需要的事務條目。

至於跟蹤是否會造成不可接受的開銷水平，你只需要測試一下，如果有額外的投訴就停下來。但是，使用該生產跟蹤文件提取DB Tuning Advisor的提示可以提高每個人的性能。

Answer 3

實際上，您不應該讓服務器處理跟蹤，因爲這可能會導致問題：「當服務器處理跟蹤時，不會丟棄任何事件 - 即使這意味着犧牲服務器性能來捕獲所有事件。處理跟蹤，如果服務器太忙，它將跳過事件。「 （從SQL 70-431考試書籍的最佳實踐）

Answer 4

實際上，您可以收集比您從Profiler收集到的更詳細的測量數據 - 並且在整個實例中全天使用它 - 而不會產生任何開銷。這就避免了提前搞清楚你需要過濾的必要性......這可能會很棘手。

完全披露：我爲提供此類工具的供應商之一工作......但無論您使用我們的還是其他人的......這可能會讓您在這裏遇到核心問題。在這裏http://bit.ly/aZKerz