什麼是 Query Store 2017 中的“日誌記憶體”
在 SQL 2017 中有一個新的執行指標“日誌記憶體”,除了它是在 2017 年添加的,我沒有找到任何關於它的資訊。
執行指標:(SQL 2017)
CPU 時間、持續時間、執行計數、邏輯讀取、邏輯寫入、記憶體消耗、物理讀取、CLR 時間、並行度 (DOP)、行數、日誌記憶體、TempDB 記憶體和等待時間
我相信我了解所有其他指標是什麼以及我為什麼會關心。
我在幾個特定時期執行了前 5 個資源消耗最多的查詢的所有指標。我記錄了,現在我正在檢查結果。我知道“日誌記憶體”的(非常大)值以 KB 為單位。
指標“日誌記憶體”到底是什麼?
編輯,收到兩個我檢查的答案
LowlyDBA的回答表明它是來自 5 個相關領域的組合
sys.query_store_runtime_stats
使用jadarnel27 在他們的回答中提供的程式碼進行驗證
我創建了數據庫“231682”並針對 5 個欄位執行了測試查詢,得到的結果非常相似
我總結(在 Excel 中**使用
=SUM()
)我的值並得到 1,383,040(字節)我查看了查詢儲存,對於使用的日誌記憶體(KB),它顯示的值為 354,058,240(KB),這個數字要大幾個數量級,與字節相比也是 KB,以字節為單位,它將是 354,058,240,000(字節)
我將所有欄位的總數相加,僅得到 1,655,236(字節)
SELECT * FROM sys.query_store_runtime_stats qsrs WHERE qsrs.avg_log_bytes_used > 0;
我懷疑我的問題的答案是 SQL 2017 中的“日誌記憶體”指標沒有任何實際價值。這個小實驗中顯示的值是 354GB,高得不切實際。
LowlyDBA 的回答涵蓋了這些指標的實際含義。 這個答案只是為了解釋為什麼查詢儲存使用者界面中的數字並不完全有意義。
獲取一些日誌數據
首先,讓我們在筆記型電腦上的 SQL Server 2017 Developer Edition 上獲取這些列中的數據。
創建數據庫:
USE [master]; GO CREATE DATABASE [231682]; GO
使用非常不切實際的設置啟用查詢儲存:
ALTER DATABASE [231682] SET QUERY_STORE = ON (INTERVAL_LENGTH_MINUTES = 1);
做一些會產生一些事務日誌使用的事情:
USE [231682]; CREATE TABLE dbo.Junk ( Id INT NOT NULL, MoreJunk NVARCHAR(MAX) NOT NULL ); INSERT INTO dbo.Junk (Id, MoreJunk) SELECT TOP 1000 m.message_id, m.[text] FROM sys.messages m;
強制刷新到磁碟以防它尚未發生:
EXEC sp_query_store_flush_db;
所以:
SELECT qsrs.avg_log_bytes_used, qsrs.last_log_bytes_used, qsrs.min_log_bytes_used, qsrs.max_log_bytes_used, qsrs.stdev_log_bytes_used FROM sys.query_store_runtime_stats qsrs WHERE qsrs.avg_log_bytes_used > 0;
計算問題
從查詢儲存使用者界面的角度來看,正在執行的計算如下所示:
SELECT TOP (@results_row_count) -- other columns ROUND(CONVERT(float, SUM(rs.avg_log_bytes_used*rs.count_executions))*1024,2) total_log_bytes_used, -- other columns FROM sys.query_store_runtime_stats rs JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id JOIN sys.query_store_query q ON q.query_id = p.query_id JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time) GROUP BY p.query_id, qt.query_sql_text, q.object_id HAVING COUNT(distinct p.plan_id) >= 1 ORDER BY total_log_bytes_used DESC
計算中有一個錯誤,它應該除以 1,024 才能從字節變為千字節。就目前而言,它將字節乘以 1,024,然後將它們報告為千字節 - 這使得它們似乎偏離了約 1,000,000 倍。
例如,我的 repro 在執行 1 次查詢時產生了 346,796 字節的日誌。查詢儲存使用者界面不是顯示 338 KB,而是顯示 355,119,104 KB。
我已將此問題報告給 Microsoft:查詢儲存“使用的日誌記憶體”指標計算錯誤