[FIX] CREATE UNIQUE CLUSTERED INDEX ... WITH DROP_EXISTING クエリで非クラスタ化インデックスを再構築する

この記事は、以前は次の ID で公開されていました: JP304519
この資料は、アーカイブされました。これは "現状のまま" で提供され、更新されることはありません。
現象
一意なクラスタ化インデックスに対して次の構文のいずれかを使用します。
 CREATE UNIQUE CLUSTERED INDEX ... WITH DROP_EXISTING
または
DBCC DBREINDEX(table_name, clustered_index_name)
その結果、クラスタ化インデックスと非クラスタ化インデックスが両方とも再構築されます。

SQL Server 7.0 では、クラスタ化インデックスのみが再構築されます。SQL Server 2000 では、両方の種類のインデックスが再構築されるので、SQL Server 2000 での操作は SQL Server 7.0 での操作より時間がかかります。
解決方法
この問題を解決するために、SQL Server 2000 の最新の Service Pack の適用をお願いいたします。
最新の SQL Server サービスパックのダウンロードおよびインストールについて詳しくは以下をご覧下さい。
回避策
この問題を回避するには、SQL Server 2000 で導入された新しい DBCC INDEXDEFRAG コマンドの使用を検討します。DBCC INDEXDEFRAG はシステムがオンライン中も使用できます。ただし、DBCC INDEXDEFRAG はリーフ レベルのインデックスを連続的に並び替える処理に関しては、クラスタ化インデックスの再作成するときほど効果的ではない場合があります。
状況
弊社では、これを Microsoft SQL Server version 2000 の問題として確認しています。
この問題は、Microsoft SQL Server version 2000 Service Pack 2 で修正されています。
詳細
クラスタ化インデックスを含むテーブルでは、非クラスタ化インデックスのキーには行ロケータとしてクラスタ化キー、またはブックマークが含まれています。一意なクラスタ化インデックスでは、クラスタ化インデックスの再構築によってインデックス キーが変更されないため、非クラスタ化インデックスのキーは変更されません。結果として、非クラスタ化インデックスのエントリについては、クラスタ化インデックスを使った再構築は不要になります。

最初にクラスタ化インデックスが一意なインデックスとして作成されなかった場合、SQL Server は、内部で各インデックス キーの最後に一意な 4 バイトの値を追加します。各非クラスタ化インデックスの行に一意なクラスタ化インデックスのキーが含まれるように、一意な 4 バイトの値が要求されます。一意でないクラスタ化インデックスでは、インデックスの再構築中に、インデックス キーの最後のこの 4 バイトの値が変更されることがあります。このため、すべての非クラスタ化インデックスのキーも再構築する必要があります。ユーザーがクラスタ化インデックスが一意であると指定していない場合の本来の動作は、インデックスの再作成中にすべてのインデックスを再構築することです。
関連情報
この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 304519 (最終更新日 2001-12-10) をもとに作成したものです。

プロパティ

文書番号:304519 - 最終更新日: 01/16/2015 23:11:17 - リビジョン: 2.1

  • Microsoft SQL Server 2000 Standard Edition
  • kbnosurvey kbarchive kbbug kbfix kbsqlserv2000presp2fix KB304519
フィードバック