Bツリーインデックスに最高のパフォーマンスを：Oracleパフォーマンス障害の克服（3）（3/4 ページ）

Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。（編集局）

[高橋潤，＠IT]

3. テーブルデータを追加した場合

図3-1　データテーブルにデータを追加したときのBツリーインデックス
※DBAの値として記載している「DBA1、…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1、…」はアドレスを示す例である

　図3-1を確認してください。テーブルに追加したデータがブランチノードに追加され、リーフノードには同じリーフ行を持っているリーフが追加されます。これを「リーフ分割」と呼びます。つまり、リーフは必ず同じリーフ行を持ったリーフを確保することになります。

SQL結果画面（クリックで拡大します）

SQL結果画面

SQL結果画面（クリックで拡大します）

　各リーフ内の行数が変わらず、リーフブロック数が増加していることが重要です。データを追加した場合、各リーフ内の行数を確保できないと新規にリーフブロックを追加していることが分かります。図3-2を見ると分かりますが、1つのリーフの範囲内で追加した場合でも各リーフ内のリーフ行を保持しようとしますので、新しくリーフブロックが追加されることになります。

図3-2　データテーブルにデータを追加したときのBツリーインデックス
※DBAの値として記載している「DBA1、…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1、…」はアドレスを示す例である

4. テーブルデータを更新した場合

図4　データテーブルのデータを更新したときのBツリーインデックス
※DBAの値として記載している「DBA1、…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1、…」はアドレスを示す例である

　図4を確認してください。更新する元のデータがリーフより削除され、更新後のデータを格納する先にリーフ行の空きがない場合は、リーフ分割して格納されます。

SQL結果画面（クリックで拡大します）

SQL結果画面

　更新される元となるデータがインデックス内で削除されること以外は、3.のテーブルデータを追加した場合と同じ挙動となることを確認してください。

　データ削除、追加、更新時のインデックスの動きは理解できたでしょうか。前置きがかなり長くなりましたが、インデックスの動きがどのようにOracleデータベースサーバに影響を与えるかを正しく理解するためには必要なことです。また、削除されたリーフ行の割合がどんどん大きくなっていくことに着目しましょう。（次ページに続く）