我應該使用帶有 NOLOCK 的 SQL Server DMV
我正在嘗試監視無法使用 PerformanceMonitor 跟踪的實時性能數據和使用情況。在生產實時 OLTP 數據庫中讀取 DMV 的後果是什麼？：例如：sys.dm_tran_locks、sys.dm_os_waiting_tasks、sys.dm_os_performance_counters、sys.dm_exec_connections、sys.dm_io_virtual_file_stats、sys.dm_exec_sql_text等
查詢 Dmvs 時我應該只使用 WITH (NOLOCK) 嗎？這會解決許多資源問題嗎？DMV 中是否有諸如臟讀回滾之類的東西。我知道它可以存在於應用程序表中，例如有人送出訂單然後取消等。此外，使用 NOLOCK，是否有更高的機會查詢將在大容量環境中永遠繼續，因為我沒有鎖定行、頁面，並且事情將繼續添加到 DMV 表視圖中？
謝謝，
在生產實時 OLTP 數據庫中讀取 DMV 的後果是什麼？
就我的經驗而言，微不足道。顧名思義，DMV 基本上是從各種記憶體和系統表中獲取資訊的視圖或函式（如 sys.dm_db_index_physical_stats ）。DMV 非常輕巧，可以從記憶體中讀取數據。它們不會導致阻塞，並且取決於您需要非常快速地獲取它們的數據量。這裡的重點始終是僅從您實際需要的記憶體中查詢數據。
您可以在 DMV 查詢中使用 NOLOCK 提示，您會看到有人使用它，但坦率地說，我認為沒有太多需要將它與 DMV 一起使用。它的功能雖然仍然保持不變。因此，當您使用 NOLOCK 提示時，您對 SQL Server 說，無論數據的狀態如何，都會給我我要詢問的數據。它可能已更改但尚未送出，因此您會得到“臟”數據。NOLOCK 提示避免選擇查詢在讀取數據時使用共享鎖。缺點很多
此外，使用 NOLOCK，由於我沒有鎖定行、頁面和內容將繼續添加到 DMV TableView 中，因此是否有更高的機會在大容量環境中永遠持續下去？
查詢只會持續一段時間，直到它完成任務，除非你執行一個永無止境的循環。NOLOCK 僅確保查詢被最小程度地阻塞，並且還請注意，在使用 NOLOCK 時，如果需要其他鎖，例如架構穩定性