更新が頻繁に起きるとどのようにインデックスが変化していくか、図5で見ていきましょう。
新規データである「18」は、空きリーフ行が存在していて既存データ「20」が入っているリーフではなく、リーフ分割し新規リーフ内に挿入されます。更新前データ「50」が存在していたリーフは完全に空きリーフとなってしまいます。このような更新が繰り返されると、リーフが散在することになります。前項で削除されたリーフ行の割合を見たとおり、削除されたリーフ行が大量に発生していくことになります。
削除されたリーフ行が大量にあるインデックスを使って、SQLによる検索を行うとどのようになるでしょうか。イコール検索を行った場合は直接リーフを参照することが可能ですので、レスポンス低下などシステムの問題の原因とはなりません。しかし、範囲検索を行った場合、空になったリーフを参照するI/Oが発生しますので、明らかにシステム遅延の原因となります。図6で確認してください。
インデックスがこのようになってしまうと、インデックスの再構築が必要です。最後に、インデックスの再構築の方法と実行時の考慮点をまとめましょう。
インデックスの再構築は、単純にインデックスの削除、作成でも可能ですが、データ量が大量になると再度インデックスを作成するために時間がかかり、作成中はそのインデックスを使用することができません。このためにインデックス再構築を効率的に行う方法とその注意点を確認しておきましょう。
SQL> ALTER INDEX インデックス名 REBUILD ONLINE;
先述の「4. テーブルデータを更新した場合」を再構築すると以下のようになります。
上記のような注意点をしっかり理解しておきましょう。特に領域は2つのインデックス分が必要となりますので、テーブルスペースに余裕がない場合は、新しい索引を別のテーブルスペースに作成する必要があります。
SQL> ALTER INDEX インデックス名 REBUILD TABLESPACE テーブルスペース名;
以上インデックスの詳細説明から問題解決まで確認しました。次回は同じインデックスですが、状況の確認に使用したANALYZEコマンドに関連して、監視や分析の方法を解説していきます。(次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.