いつインデックスを削除して再作成する必要がありますか？

最初は1 TBで、毎月約20ギガバイト成長するデータウェアハウスを構築しています。

特定のテーブルについては、毎日ETLプロセスを行っており、他のテーブルについては毎週/毎月行っています。

テーブルへのデータインポートがある場合、インデックスを削除して再作成する必要がありますか？

インデックスを削除して再作成するポイントはありますか、それとも自動的に更新されますか？

統計は自動的に更新されるように設定されています。

あなたの助けと指導を本当にありがとう。

私はこの天才的なスクリプトを得ました：

SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' +
       CASE WHEN ps.avg_fragmentation_in_percent > 40 THEN 'REBUILD' ELSE 'REORGANIZE' END +
       CASE WHEN pc.partition_count > 1 THEN ' PARTITION = ' + cast(ps.partition_number as nvarchar(max)) ELSE '' END
FROM   sys.indexes AS ix INNER JOIN sys.tables t
           ON t.object_id = ix.object_id
       INNER JOIN sys.schemas s
           ON t.schema_id = s.schema_id
       INNER JOIN (SELECT object_id, index_id, avg_fragmentation_in_percent, partition_number
                   FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL)) ps
           ON t.object_id = ps.object_id AND ix.index_id = ps.index_id
       INNER JOIN (SELECT object_id, index_id, COUNT(DISTINCT partition_number) AS partition_count
                   FROM sys.partitions
                   GROUP BY object_id, index_id) pc
           ON t.object_id = pc.object_id AND ix.index_id = pc.index_id
WHERE  ps.avg_fragmentation_in_percent > 10 AND
       ix.name IS NOT NULL

ここから：

http://weblogs.asp.net/okloeten/archive/2009/01/05/6819737.aspx

このスクリプトを毎日実行し、その結果に基づいて生成されたコードを実行することをお勧めしますか？

これが循環ETLであり、開発中（つまり、ライブではない）のデータ環境にいる場合は、ロードサイクルの一部としてインデックスを確実に管理する必要があります。

私はこれを毎月いくつかのデータセットに対して行っていますが、そのうち最大のものは毎月約100 GBを5 TBのデータセットに追加します。

私は広範なテストを行ってきましたが、私自身の経験から、インデックスに関してロードする最も効率的な方法は次のとおりです。

1. DISABLE 非クラスター化インデックス、クラスター化インデックスはそのまま
2. 生のデータテーブルへのロードを実行する
3. REBUILD NCインデックス

管理対象ETLの一部として定期的に行を追加するだけの場合、これが適切な方法です。これにより、すべての統計が最新の状態になります。

統計の場合、1 TBのデータベースに20 GBを追加しても統計の自動更新の転換点には到達しないため、統計を更新せずに1か月分のデータを追加できることに注意することが重要です。

NCインデックスを再構築することは、これを回避する良い方法です。（テーブル構造とクラスター化キーに応じて）断片化が高くなる場合は、クラスター化インデックスの再構築を定期的に実行することもできます。

1 TB以上のデータベースの場合、インデックスを毎日削除して作成するのはやりすぎです（たとえ一部のみを再作成しても）。

インデックスの更新によって追加されるオーバーヘッドが原因でテーブルの挿入/更新速度が心配な場合は、次の2つのことをお勧めします。

1. 代理PKを使用して、クラスター化インデックスの挿入でオーバーヘッドが最小限になるようにします。
2. DWHのプロファイルを作成し、絶対に必要な場合は非クラスター化インデックスを作成します。

挿入/更新操作中は、非クラスター化インデックスの更新に対応する必要があります。

インデックスの断片化が心配な場合は、インデックスを再構築するための毎日のジョブ（SQLエージェントジョブ）を作成することをお勧めします。再構築期間は実際には何でも可能で、断片化レベルに依存します。実際にこれに気づき、それに応じてジョブスケジュールを設定する必要があります。

断片化レベルに応じて、再構築スクリプトにロジックを追加できます。あなたがここで見つけることができるいくつかの良いガイドライン。

結論として、どのような状況でも、そのサイズのデータ​​ベースで完全なインデックスの再構築を行うべきではありません。

断片化について読む

断片化が「高すぎる」場合にインデックスを再構築したい（ドロップ/再作成ではない）

私が持っているこのパッケージでIndexOptimize procを毎晩実行するようにスケジュールを。