さらに踏み込んで、データの更新・削除に伴いリーフがどのような状況になるか確認してみます。確認する項目としてはリーフの数がどのようになっているか、削除されたリーフはあるのかという観点が重要です。なおデータ追加時のリーフやブランチの数やリーフ行の動きはデータ量やシステムの構成に依存しますので、下記のリーフやブランチになるとは限りません(下記に示す図ではリーフ行が2行しかありませんが、実際のインデックスが必ず2行ということではありません)。
情報取得SQL文
SQL> ANALYZE INDEX インデックス名 VALIDATE STRUCTURE; SQL> SELECT LF_ROWS AS "リーフ行の数", LF_BLKS AS リーフブロック数, DEL_LF_ROWS AS "削除リーフ行の数", TO_CHAR(DEL_LF_ROWS/LF_ROWS * 100,'999.9') || '%' AS "削除リーフ行の割合" FROM INDEX_STATS;
INDEX_STATSから情報を取得するには、ANALYZEコマンドを使用して状況を分析し、情報を取得する必要がありますのでINDEX_STATSのSELECT文の前に必ず実行します。
では、テーブルデータの更新時にインデックスがどのように変化していくか確認してみます。先ほどの図1を基に、まずはデータを削除した場合を確認してみましょう。テストデータの作成は以下のようなスクリプト、構成で行います。
テーブル: CREATE TABLE test_table(no number, data VARCHAR2(20)); データ: テストデータを1000件挿入 BEGIN FOR i IN 1..1000 LOOP INSERT INTO test_table(no,data) VALUES((i * 100), TO_CHAR('data_' || (i * 100))); END LOOP; END; / インデックス: CREATE INDEX idx_test_table ON test_table(no);
図2のように、実際のテーブルデータは削除され、リーフノードの対応するデータが削除されます。
リーフブロック数は変わらず、削除リーフ行が増加し、削除されたリーフの割合が高くなっていることが重要です。
図2を確認すると分かるように、実際のテーブルデータは削除され、リーフノードの対応するデータが削除されるのですが、1つのリーフそのものが空のリーフとして残ってしまいます。
リーフブロック数は変わらず、削除リーフ行が増加し、削除されたリーフの割合が高くなっていることが重要です。つまり、空のリーフブロックが残ってしまっています。(次ページに続く)
Copyright © ITmedia, Inc. All Rights Reserved.