web-dev-qa-db-ja.com

オンラインインデックスの再構築中に2つのアロケーションユニットが異なるファイルグループに再構築されるのはなぜですか？

大きなテーブルのクラスター化されたインデックスを別のファイルグループに再構築しているところです。 _sys.system_internals_allocation_units_を使用して再構築プロセスを監視しています。私は3時間ですが、まだ完了していません。

不思議なことに、テーブルにはアロケーションユニットが多すぎるようです。

  1. 古いファイルグループ、IN_ROW_DATA（通常）
  2. 古いファイルグループ、ROW_OVERFLOW_DATA（通常）
  3. 新しいファイルグループ、IN_ROW_DATA（通常）
  4. 新しいファイルグループ、ROW_OVERFLOW_DATA（通常）
  5. 新しいファイルグループ、IN_ROW_DATA（再び！）

したがって、宛先ファイルグループに2つの_IN_ROW_DATA_があります！それらの1つにはNONEとしてのデータ圧縮があり、そのうちの1つにはPAGEがあります。インデックスの再構築を行っていますWITH (DATA_COMPRESSION = PAGE, ONLINE = ON)。テーブルはパーティション化されていません。

あなたはあなた自身のために見ることができます：

_SELECT idx.name
, au.allocation_unit_id, au.type_desc, au.container_id, au.filegroup_id, au.used_pages, au.root_page
, par.index_id, par.rows, par.data_compression_desc
FROM sys.system_internals_allocation_units au
LEFT JOIN sys.partitions par ON (au.container_id = par.hobt_id AND au.type IN (1, 3)) OR (au.container_id = par.partition_id AND au.type IN (2))
LEFT JOIN sys.indexes idx ON par.object_id = idx.object_id AND par.index_id = idx.index_id
LEFT JOIN sys.objects obj ON par.object_id = obj.object_id
WHERE obj.name = 'X'
ORDER BY obj.name, idx.name, par.partition_number, au.filegroup_id, au.type_desc
_

enter image description here

ファイルグループ2が宛先です。両方の_IN_ROW_DATA_アロケーションユニットには多くのページが含まれているため、どちらかが何らかのダミーであるとは限りません。また、テーブルはこの時点で必要なスペースの2倍以上を占めています。明らかに、_DATA_COMPRESSION_設定は必要ありませんでした！

質問：同じパーティションに2つのアロケーションユニットがあるのはなぜですか？ _DATA_COMPRESSION_設定でデータが圧縮されないのはなぜですか？

編集：1行目と4行目は同じデータに対応しているようです。それらは両方とも宛先にあり、同じ行数を持っています。すべての行が2回書き込まれているようです。1回は圧縮され、もう1回は非圧縮です。スペースが使用されている（または少なくとも書き込まれ、割り当て済みとしてマークされている）ことを確認できます。

編集2：再構築中のテーブルのINSERT DMLプランは、 HOBTへの挿入を示しています。オンラインインデックスの再構築中に予想される2つだけではありません。非クラスター化インデックスは定義されていません。計画は次のとおりです。

enter image description here

編集3：再構築が完了しました。圧縮されていない（巨大な）パーティションはなくなりました。残っているのは圧縮されたものだけです。残念ながら、両方の割り当てられたエクステントは、書き込み中に混合されています。私が書いたビジュアライザーツールを使用すると、次のようになります。

enter image description here

（これは、割り当てビットマップ全体の1％未満のトリミングです）。黒=割り当て済み、白=空き（以前は一時パーティション）。

これは、シーケンシャルIOのひどい結果です。そこで、テーブルを空のコピーに切り替えて、新しいファイルグループへの_ONLINE = OFF_再構築を実行できるようにしました（これは挿入専用のテーブルなので、いつでも切り替えることができます）。その修正事項：テーブルは隣接しており、一時的なパーティションは見られませんでした。

それでも、疑問が残ります。_ONLINE = ON_ CIの再構築がこれらすべての厄介な影響を引き起こすのはなぜですか？それを修正する方法は？

sql-serverindexsql-server-2012filegroupscompression
2
usr

オンラインインデックス操作のしくみ ：

一時的なマッピングインデックス

クラスター化インデックスを作成、削除、または再構築するオンラインインデックス操作にも、一時的なマッピングインデックスが必要です。この一時インデックスは、基になるテーブルの行が更新または削除されたときに作成される新しいインデックスで削除するレコードを決定するために、同時トランザクションによって使用されます。この非クラスター化インデックスは、新しいクラスター化インデックス（またはヒープ）と同じステップで作成され、個別のソート操作は必要ありません。並行トランザクションは、すべての挿入、更新、および削除操作で一時マッピングインデックスも維持します。

インデックスDDL操作のディスク容量要件

クラスター化されたインデックスがオンラインで作成、再構築、またはドロップされると、一時的な非クラスター化インデックスが作成され、古いブックマークが新しいブックマークにマップされます。 SORT_IN_TEMPDBオプションがONに設定されている場合、この一時インデックスはtempdbに作成されます。 SORT_IN_TEMPDBがOFFに設定されている場合、ターゲットインデックスと同じファイルグループまたはパーティションスキームが使用されます。 （私のメモ：デフォルトはオフです）

インデックスID254は確かにマッピングインデックスです。 SQL Server 2005のオンラインインデックス操作 ホワイトペーパーに詳細があります。

3
Remus Rusanu