web-dev-qa-db-ja.com

SQL ServerのtempDBでソートを使用してインデックスを再構築すると、DBサイズが増加するのはなぜですか？

次のコマンドを使用して、 Ola Hallengren's SQLメンテナンススクリプトを実行しています。

EXECUTE [dbo].[IndexOptimize]
@Databases = 'MyDatabase'
, @FragmentationLow = NULL
, @FragmentationMedium = 'INDEX_REBUILD_OFFLINE'
, @FragmentationHigh = 'INDEX_REBUILD_OFFLINE'
, @FragmentationLevel1 = 10
, @FragmentationLevel2 = 30
, @UpdateStatistics = 'ALL'
, @OnlyModifiedStatistics = 'Y'
, @LogToTable = N'Y'
, @TimeLimit = 23400
, @MinNumberOfPages = 1000
, @Indexes = 'ALL_INDEXES'
, @MaxDOP = 7
, @SortInTempdb = 'Y'

最近まで、スペースの制約のためにいくつかのインデックスを再構築できなかったため、tempDBを独自のドライブに移動し、8つの異なるファイルを使用するようにtempDBを構成し、tempDBでのソートを開始しました（各tempDBファイルは約10GBで、拡張は500MBに設定されています）各）。以前は再構築が困難だった一部のインデックスは比較的速く完了することができましたが、MyDatabaseで1時間以上実行しているインデックスが1つあり、データベースのサイズが急速に増加しています。現在、他に何も実行されておらず、TempDBのサイズはまったく増加していません。

MyDatabaseが急速に増加している理由を誰かが理解するのを手伝ってくれませんか？誰がそれがこれを引き起こしているのかについて何か提案はありますか？

それが役立つ場合は、SQL Server 2012を実行します。ありがとう

sql-serversql-server-2012indexola-hallengren
3
Woody

異なる記事から3つのセクションを引用し、下部にリンクを示しました。結論としては、ビルドを取得するための新しいインデックス用のスペースと、ロールバック用のトランザクションログスペースが必要です。必要なスペースに対応できない場合は、 INDEX_REORGANIZE を検討してください。

新しいインデックス構造が作成されると、適切なファイルとファイルグループに、古い（ソース）構造と新しい（ターゲット）構造の両方のディスク領域が必要になります。古い構造は、インデックス作成トランザクションがコミットするまで割り当て解除されません。

インデックスの再構築（オンラインでもオフラインでも、少なくとも7.0まで）は、古いコピーを削除する前にインデックスの新しいコピーを作成します。これを行うために必要なページとエクステントは、SQL Serverの他の操作と同様に、常に必要に応じて割り当てられます。

オフラインまたはオンラインで実行される大規模なインデックス操作は、トランザクションログがすぐにいっぱいになる可能性のある大きなデータロードを生成する可能性があります。インデックス操作を確実にロールバックできるようにするため、インデックス操作が完了するまでトランザクションログを切り捨てることはできません。ただし、インデックス操作中にログをバックアップできます。したがって、トランザクション操作ログには、インデックス操作のトランザクションの間、インデックス操作のトランザクションと同時ユーザートランザクションの両方を格納するのに十分なスペースが必要です。詳細については、「インデックス操作のトランザクションログディスク領域」を参照してください。

参照：

  1. インデックスの再構築に関する誤解（割り当て、BULK_LOGGEDモード、ロック） by Paul Randal
  2. 追加のディスク容量を必要とするインデックス操作
  3. インデックス操作のトランザクションログディスク領域
1
SqlWorldWide