検索
連載

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

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

Share
Tweet
LINE
Hatena
前のページへ |       

Bツリーインデックスの問題

 更新が頻繁に起きるとどのようにインデックスが変化していくか、図5で見ていきましょう。

図5 更新が頻繁に起こるときのBツリーインデックスの変化
図5 更新が頻繁に起こるときのBツリーインデックスの変化
※DBAの値として記載している「DBA1…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1…」はアドレスを示す例である

 新規データである「18」は、空きリーフ行が存在していて既存データ「20」が入っているリーフではなく、リーフ分割し新規リーフ内に挿入されます。更新前データ「50」が存在していたリーフは完全に空きリーフとなってしまいます。このような更新が繰り返されると、リーフが散在することになります。前項で削除されたリーフ行の割合を見たとおり、削除されたリーフ行が大量に発生していくことになります。

Bツリーインデックスの問題解決

 削除されたリーフ行が大量にあるインデックスを使って、SQLによる検索を行うとどのようになるでしょうか。イコール検索を行った場合は直接リーフを参照することが可能ですので、レスポンス低下などシステムの問題の原因とはなりません。しかし、範囲検索を行った場合、空になったリーフを参照するI/Oが発生しますので、明らかにシステム遅延の原因となります。図6で確認してください。

図6 イコール検索と範囲検索のI/Oコスト
図6 イコール検索と範囲検索のI/Oコスト
※DBAの値として記載している「DBA1…」はアドレスを示す例である
※ROWIDの値として記載している「ROWID1…」はアドレスを示す例である

 インデックスがこのようになってしまうと、インデックスの再構築が必要です。最後に、インデックスの再構築の方法と実行時の考慮点をまとめましょう。

インデックスの再構築

 インデックスの再構築は、単純にインデックスの削除、作成でも可能ですが、データ量が大量になると再度インデックスを作成するために時間がかかり、作成中はそのインデックスを使用することができません。このためにインデックス再構築を効率的に行う方法とその注意点を確認しておきましょう。

インデックス再構築方法

SQL> ALTER INDEX インデックス名 REBUILD ONLINE;
  • 新しいインデックスは既存のインデックスを基に作成されるため時間は比較的短くできる
  • 既存のインデックスは新規インデックスの作成完了を待って削除されるため、両方のインデックスを格納できる領域が必要
  • 新規インデックスには削除エントリが含まれない

 先述の「4. テーブルデータを更新した場合」を再構築すると以下のようになります。

SQL結果画面
SQL結果画面(クリックで拡大します)

 上記のような注意点をしっかり理解しておきましょう。特に領域は2つのインデックス分が必要となりますので、テーブルスペースに余裕がない場合は、新しい索引を別のテーブルスペースに作成する必要があります。

インデックス再構築方法(別のテーブルスペースに作成)

SQL> ALTER INDEX インデックス名 REBUILD TABLESPACE テーブルスペース名;

 以上インデックスの詳細説明から問題解決まで確認しました。次回は同じインデックスですが、状況の確認に使用したANALYZEコマンドに関連して、監視や分析の方法を解説していきます。(次回に続く)


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る