如何對乾擾其他應用程序的 orm 查詢進行故障排除
好吧，這是假設的場景，但我想了解的是從事後日誌（例如 SQL Server Profiler 跟踪）到辨識 ORM 情況下的程式碼的路徑。為了使它不太模糊，請考慮這樣的場景：
- SQL Server 2008
- 作為 ORM 的實體框架
那麼，在這種情況下，DBA（也是 VB.Net 開發人員）從日誌中診斷出哪些程式碼（在這種情況下是 Linq 查詢）造成問題的常用路徑是什麼？在這種情況下，應用程序正常，但會影響使用相同數據庫/伺服器的其他應用程序響應時間。
這與 Java+Hiberate 程序有什麼不同？
編輯：我想了解從跟踪到罪魁禍首元查詢的路徑。如果應用程序中有 SQL，這意味著“在文件中查找”會話（在極端情況下可能使用一些正則表達式）可以將檢查任務的目標減少到幾十個嫌疑人，而不是十分之一甚至數百個源文件。使用 ORM，如何使用 ORM（在本例中為：EF）進入該階段？
我強烈建議在連接中使用元數據，以便追溯到應用程序。在連接字元串中，有一個應用程序名稱。還有會話數據可以以CONTEXT_INFO的形式使用
當然，所有這些都需要更改應用程序，但一般來說它對跟踪和審計很有用，所以從一開始就將其放入非常有用。
通常，當一個查詢“干擾”另一個查詢時，它要麼是阻塞的，要麼是死鎖的。這些中的任何一個都不會通過預設的 SQL Profiler 跟踪可見。
如果遇到死鎖，您需要在 SQL Server 中打開跟踪標誌 1204 和 1222，以便將死鎖輸出發送到錯誤日誌。您還可以重新執行跟踪並添加死鎖事件。
可以輪詢阻塞問題。您可以滾動自己的阻塞日誌程式碼，也可以使用 SQL Spotlight 之類的工具來檢測這些事件。可以通過查看 master.sys.sysprocesses 阻塞列中的值 <> 0 來檢查阻塞。如果您決定自己滾動，可以使用像這樣的腳本作為起點來獲取執行會話資訊，該資訊可以記錄到表中，或者您可以設置作業以從sp_whoisactive中提取資訊。
我還將檢查您的 Profiler 跟踪（或獲取一個新跟踪）並將其與基本伺服器性能計數器（CPU、磁碟隊列、網路吞吐量）相關聯，以查看在特定查詢執行期間是否有任何特定資源出現瓶頸。通常，通過 Profiler 跟踪可以明顯看出查詢是否存在問題，因為語句或批處理完成事件的讀取量或 CPU 量將非常高。在進行 Profiler 跟踪的同時創建的計數器日誌可以在 SQL Profiler 中打開，並直接與保存的 Profiler 跟踪輸出相關聯。
設置SQL Server 管理數據倉庫以隨時間收集伺服器和查詢性能統計資訊也是一個好主意。它有一些很好的深入報告，可以幫助您在特定時間視窗內辨識問題。它並不總是像分析器跟踪那樣精確，但它可以為您提供有用的資訊，例如您遇到的等待類型和其他資源瓶頸模式，這些模式可以通過查詢統計報告輕鬆與其他查詢相關聯。