如何通過統計更新最好地管理索引建構?
這是我讀到的後續內容是否有任何理由在維護視窗期間停止事務日誌備份?在 sp_BlitzErik 提出的答案中。
我使用 Ola Hallengren 的索引腳本,並按以下方式指定設置。我每週通過代理工作執行一次。
@Databases nvarchar(max), @FragmentationLow nvarchar(max) = NULL, @FragmentationMedium nvarchar(max) = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh nvarchar(max) = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 int = 5, @FragmentationLevel2 int = 30, @PageCountLevel int = 500,
我知道作為索引重建的一部分,更新統計資訊是自動完成的,但是我針對我的所有數據庫設置了以下數據庫屬性,我認為這些屬性應該負責更新統計資訊:
Auto Create Statistics = True Auto Update Statistics = True Auto Update Statistics Asynchronously = True
但是,這些設置和定期更新統計數據的最佳實踐是什麼?你應該每晚更新一次統計數據嗎?我不確定如何衡量是否應該更新統計資訊,這就是我設置這些數據庫屬性的原因。
我在 sp_BlitzErik 的回答中看到他提到“儘管如此,您仍然希望定期更新統計資訊,您可以使用以下命令來做到這一點:”
使用以下命令,但定期更新統計資訊非常籠統。
EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @StatisticsSample = NULL, @LogToTable = 'Y';
我使用 Ola Hallengren 的索引腳本,並按以下方式指定設置。我每週通過代理工作執行一次。
讓我們分解您正在執行的命令:
@FragmentationLevel1 int = 5, @FragmentationLevel2 int = 30, @PageCountLevel int = 500,
即使每週一次,這也是荒謬的侵略性。我知道 5/30% 來自古老的 Microsoft 建議,但僅此而已——古老的。是時候繼續前進了。
您正在花時間對 500 個 8KB 頁面的索引進行碎片整理。那是一個 4MB 的表。如果您的硬體在將 4MB 讀入記憶體或在記憶體中保留 4MB 表時遇到問題,則答案不是索引維護。這就是為什麼我將它提高到至少 5000 的原因。
現代硬體,如 SAN、SSD 和非 32 位伺服器,可以容納大於 4GB 的 RAM,根本不存在與 2000 年代初的旋轉盤驅動器相同的數據訪問問題。
我們正在談論電唱機與 CD。
索引重建應該很少發生,並且只是為了糾正索引問題或更改設置。事情是這樣的:30% 的碎片並不是真正的問題。這只是 DBA 所做的事情,因為他們被告知要這樣做,而且這是他們可以衡量的事情。
所以這是我要問你的問題:你的伺服器在索引維護上花費了多少時間和資源,這減少了查詢消耗的時間和資源多少?
如果您可以衡量這一點,您就可以隨心所欲地重建和重組。
…但是我針對我的所有數據庫設置了以下數據庫屬性,我認為這些屬性應該負責更新統計資訊…
有點像。當 20% 的表數據 + 500 行(假設表 > 500 行)發生更改時,會發生自動更新統計資訊(甚至是非同步的)。如果您有一個包含一百萬行的表,那就是 200k 行。您可以使用跟踪標誌 2371 動態降低該門檻值,但自動更新統計資訊使用預設採樣算法,這對於數據嚴重傾斜的表可能不夠用。
但定期更新統計數據非常籠統。
嗯,是的,我正在回答有關我從未看過的伺服器的問題。我更喜歡每晚更新統計數據,但我見過比這更頻繁地需要它們的伺服器。
那你該怎麼辦?
- 首先將索引維護回撥到我在您引用的問題中發布的命令
如果遇到問題,請降低碎片門檻值,直到它們停止。如果沒有人說什麼,請減少執行索引維護的頻率,直到可能,只是可能,您根本不會執行它。 2. 每晚更新統計數據
從預設門檻值開始。如果您發現重建時需要更新完整的統計資訊,請使用該
CommandLog
表來查找定期重建的表和索引,並開始關注這些。它們通常是具有數千萬行的“大”表的索引。這是關於我從未見過的伺服器的具體情況。你將不得不從這裡開始實驗。
另請參閱我的文章為什麼你們中的大多數人應該保留自動更新統計資訊