Ola HallengrenのIndexOptimize
スクリプトを使用して、SharePoint 2013オンプレミスの最適化タイマージョブを置き換える予定です。
この目的のためにそれを使用している人はいますか?どのパラメーターをどのように使用しますか? OOOTBタイマージョブが通常処理するデータベースを対象にするために私がまとめたものを次に示します。
EXEC sp_msforeachdb
'if exists(select 1 from [?].sys.objects where name=''proc_DefragmentIndices'')
EXECUTE dbo.IndexOptimize
@Databases = ''?'',
@FragmentationLow = NULL,
@FragmentationMedium = ''INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE'',
@FragmentationHigh = ''INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE'',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30
'
統計を更新するだけです。
Jeff Modenはかつて「インデックスの再構築は統計を更新するための非常にコストのかかる方法である」と言っていたと思います。
また、UPDATE STATISTICSを実行すると、インデックスと列の両方の統計情報が更新されます。インデックスの再構築はインデックス自体のみを実行するため、「20%データの変更+ 500レコード」の基準に達して自動更新をトリガーしない限り、列の統計は古くなります。大きなテーブルでは、しばらく時間がかかり、十分な頻度ではない場合があります。
SQL2014以前-デフォルトのサンプルサイズは並列化せず、FULLSCANのみが並列化します
SQL2016-デフォルトのサンプルサイズも並列化できます( Parallel Statistics Update )
私が通常使用する構文(この場合、FULLSCAN [StatisticsSample = 100]を実行します):
EXECUTE [dbo].[IndexOptimize]
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = 'ALL',
@StatisticsSample=100
このようにして、I/Oスラッシングや物理インデックス構造のメンテナンスのログを記録せずに、更新された統計(オプティマイザに感謝します)のすべての利点を得ることができます。
TF2371の追加の読み取りにより、大きなテーブルでの統計更新を低いパーセンテージでトリガーできます。 SQL 2016を使用している場合、これはデフォルトで有効になっています。