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

SQL処理（インデックス）にかかわる確認

　前回「ロックをつぶせ！最初に疑うべき原因」では、SQLにかかわる問題の解決方法としてロックの確認方法を説明しました。データ更新には必ずオブジェクトの処理が行われていることを理解できたと思います。

　SQL文をきっかけに更新されるOracleサーバ内のオブジェクトとして、今回はインデックスを取り上げます。SQL文発行時、直接データとのかかわりを意識しづらいオブジェクトなので、データの更新頻度やインデックスの作り方によっては、Oracleサーバの問題の原因になっていても気付かないこともあります。そこでまず、インデックスの特徴を確認してみましょう。本稿で取り上げるのは少々基本的な内容になりますが、インデックスの問題を正しく理解するためには重要です。

インデックスの問題を切り分ける

　データ検索には欠かせないインデックスですが、Oracleサーバがデータ検索を行う方法は理解できているでしょうか。インデックスの特徴を理解する前にデータベースサーバの動きを確認して、インデックスの種類の確認をしていきます。

　フルスキャンで検索が行われると当然すべてのデータを検証するため、大量のデータがテーブルに格納されていると検索に時間がかかります。この検索パフォーマンスを向上させるために、インデックススキャンを使用します。しかし、インデックススキャンでは、実際のデータを取得するためにテーブルオブジェクトとは異なる領域（インデックス領域）にアクセスし、そのデータを読み出すため、実際のテーブル検索とは別に処理時間やI/Oが発生することを理解すべきです。

　インデックスの種類を確認していきましょう。

インデックスの種類

　Oracleデータベースサーバで使用できるインデックスは以下になります。

　データの構成は使用用途によって有効なインデックスが用意されていますが、一般的に作成されているBツリーインデックスは木構造（ツリー）にキー値となるデータを格納していきます。ビットマップインデックスはキー値となるデータをビットによって表現し、メモリを効率的に使用することが可能です。そのほかにもOracleには複数のインデックスの種類がありますが、今回はインデックスとして最も一般的に使われているBツリーインデックスについて考えていきましょう。

Bツリーインデックスの構造

　Bツリーインデックスは図1のような「ルートノード」「ブランチノード」「リーフノード」に分かれた構造をしています。インデックスというその名前から分かるように、キー値データを昇順にリーフノードに格納していきます。さらにリーフノードの上層にリーフノード内のデータ位置を示すデータブロックアドレス（DBA）で、リーフノードデータ値の範囲を格納しています。さらに上層のルートノードには各リーフノード内のデータブロックを格納しデータ位置を示しています。

　インデックスを作成したテーブルにデータを挿入したイメージを確認してください。テーブルデータの行自体を識別するROWIDにより、その行を特定できます。従って、インデックスにはこのROWIDを格納し、このROWIDを基に実際のテーブル行を特定してデータを取得することになります。

図1　Bツリーインデックスの構造
※DBAの値として記載している「DBA1、…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1、…」はアドレスを示す例である

　この図1のツリー構造をデータディクショナリビューにて確認してみましょう。

INDEX_STATS

SQL> DESC INDEX_STATS

INDEX_STATSデータディクショナリビューの取得コマンド
（内容の抜粋は下記の表3参照）

情報取得SQL文

SQL> SELECT NAME AS インデックス名, BLOCKS AS ブロック数,
      LF_ROWS AS リーフ行数,  LF_BLKS AS リーフブロック数, 
     BR_BLKS AS ブランチのブロック数
      FROM INDEX_STATS;

　このSQL文では作成されたインデックスの現在割り当てられている全ブロック数とリーフ内に保持されているデータ行数、各リーフのブロック数、ブランチのブロック数が確認できます。これを使って、現在のインデックスがどのくらいのブロックを占有し、リーフとブロックでどのくらいブロックを使用しているか確認します。（次ページへ続く）