Sql-Server
IndexOptimize 後查詢和更新極慢
數據庫 SQL Server 2017 企業版 CU16 14.0.3076.1
我們最近嘗試從預設的 Index Rebuild 維護作業切換到 Ola Hallengren
IndexOptimize
。預設索引重建作業已經執行了幾個月沒有任何問題,並且查詢和更新在可接受的執行時間內工作。在數據庫上執行後IndexOptimize
:EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y'
性能嚴重下降。之前花費100 毫秒的更新語句在之後
IndexOptimize
花費了 78.000 毫秒(使用相同的計劃),並且查詢的執行也差了幾個數量級。由於這仍然是一個測試數據庫(我們正在從 Oracle 遷移生產系統),我們恢復到備份並禁用
IndexOptimize
,一切都恢復正常。但是,我們想了解可能導致這種極端性能下降
IndexOptimize
的“正常”的不同之處,Index Rebuild
以確保我們在投入生產後避免這種情況。任何關於尋找什麼的建議將不勝感激。更新語句慢時的執行計劃。即
我一直無法發現差異。
我懷疑您在兩種維護方法之間定義了不同的採樣率。我相信 Ola 的腳本使用預設採樣,除非您指定
@StatisticsSample
參數,它看起來不像您目前正在執行的操作。在這一點上,這是推測,但您可以通過在數據庫中執行以下查詢來檢查統計資訊目前使用的採樣率:
SELECT OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) AS TableName , col.name AS ColumnName , st.name AS StatsName , sp.last_updated , sp.rows_sampled , sp.rows , (1.0*sp.rows_sampled)/(1.0*sp.rows) AS sample_pct FROM sys.stats st INNER JOIN sys.stats_columns st_col ON st.object_id = st_col.object_id AND st.stats_id = st_col.stats_id INNER JOIN sys.columns col ON st_col.object_id = col.object_id AND st_col.column_id = col.column_id CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) sp ORDER BY 1, 2
如果您看到這是通過 1s(例如 100%)實現的,那麼這就是您的問題。也許再次嘗試 Ola 的腳本,包括
@StatisticsSample
該查詢返回的百分比參數,看看是否能解決您的問題?作為該理論的額外支持證據,執行計劃 XML 顯示慢查詢的採樣率大不相同 (2.18233 %):
<StatisticsInfo LastUpdate="2019-09-01T01:07:46.04" ModificationCount="0" SamplingPercent="2.18233" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" Schema="[SVALA]" Database="[ulek-sva]" />
與快速查詢 (100 %) 相比:
<StatisticsInfo LastUpdate="2019-08-25T23:01:05.52" ModificationCount="555" SamplingPercent="100" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" Schema="[SVALA]" Database="[ulek-sva]" />