表領域とディスクI/Oの要注意ポイント：Oracleパフォーマンス障害の克服（8）（2/2 ページ）

» 2005年04月26日 00時00分公開

表領域のフラグメンテーションを解消する

　エクステントに関連して、表領域のフラグメンテーション（断片化）という問題がよく発生します。前ページの図3で確認した表領域の空き容量は、データとして使用されていない領域の総計になります。Oracleはエクステント単位で領域を確保していきます。オブジェクトなどの構成要素が削除された場合、割り当てられていた領域は解放されて空き領域となります。表領域内のさまざまな個所で確保された領域であれば、削除に伴う空き領域は必然的に分散して生じます。

　また、エクステントは連続したデータ・ブロックで構成されたデータ管理の最小構成要素ですので、隣り合ったエクステントが存在したとしても、またがってデータを確保できないという状況も生まれます。さらに「PICTINCREASE」を増分で設定していると、過去に使用されたエクステントよりも大きなエクステントを確保しようとしますので、過去に使用された領域は使用されず、歯抜け状態で残っていってしまいます。この状況を表領域のフラグメンテーションと呼びます。

SQL> SELECT
        TABLESPACE_NAME,
        FILE_ID,
        BLOCK_ID AS 開始ブロック,
        BLOCK_ID + BLOCKS - 1 AS 終了ブロック,
        BYTES AS サイズ,
        BLOCKS AS ブロック数
      FROM DBA_FREE_SPACE
      WHERE TABLESPACE_NAME = '表領域名'
      ORDER BY BLOCK_ID;

リスト5　フラグメンテーション（断片化）の確認

図6　リスト5の出力結果（クリックすると拡大します）

　図6の1件目と2件目はテーブルを削除した領域です。つまりデータベース内で歯抜けの状態ができています。この断片化した状態を解消するには、「連続する空き領域を結合する方法」と「歯抜けの状態を解消する方法」の2つがあります。

連続する空き領域の結合

　連続する空き領域を結合するには、リスト6のSQLを発行します。

SQL> ALTER TABLESPACE APP COALESCE;

リスト6　連続する空き領域の結合

歯抜けの状態を解消する方法

　連続していない領域が断片化している状態を解消するには、EXPORTコマンドを使用してデータをいったん抜き出し、オブジェクトを削除し、IMPORTコマンドでデータを挿入する操作が必要です。

　ここまでは領域の管理のうち、データの管理方法を紹介してきましたが、このほかにも領域にはオブジェクトに割り当てられたブロックの中でデータ・ブロックの最後尾を示す「ハイウォーターマーク」や、行データが複数のデータ・ブロックにまたがって記録される「行連鎖」など、考慮しなければならないものがありますが、まずはエクステントが断片化していないか確認してみましょう。

データファイルのアクセスによるディスクI/Oの確認

　ディスクに関する挙動は、Oracleのパフォーマンス劣化や問題発生時には注意すべき項目です。基本的にディスクの管理はOSに依存する以上、Oracleからその障害を検知することはできません。UNIX系のOSの場合であれば「iostat」コマンドを使用し、問題がないか確認することが重要です。

#iostat [データ間隔] [データ取得回数]

リスト7　iostatコマンドによるディスクの監視
※上記のiostatを使用した情報はSTATSPACKを使用し、拡張機能としてディスクI/O情報を追加すると、パフォーマンス・チューニングに役立つ重要な情報となります

　今回の連載はSTATSPACKなどの使用を前提としていません（障害が起きる前にSTATSPACKなどを導入している環境は少ないと思われます）ので、Oracleから確認できるディスク関連項目を挙げておきます。連載第3回「Bツリーインデックスに最高のパフォーマンスを」の索引の解説でも、パフォーマンス障害の原因はディスクI/Oに起因することが多いと注意してきましたが、実際にディスクI/Oの回数は確認していませんでした。索引の負荷確認を行う際など、ディスクI/Oの状態を確認しましょう。リスト8のSQLでは、各物理ファイルに対してどの程度ディスクI/Oが発生しているか確認できます。データベース起動時からの累積回数でしか回数を取得できませんので、負荷の高い時間帯に10分など間隔を空けて確認します。

SQL> SELECT D.FILE_NAME ファイル名, 
        C.NAME AS TABLESPACE_NAME,
        B.PHYRDS AS 累積回数
      FROM V$DATAFILE A, V$FILESTAT B, V$TABLESPACE C, DBA_DATA_FILES D
      WHERE A.FILE# = B.FILE#
      AND A.FILE# = D.FILE_ID
      AND A.TS# = C.TS# 
      AND C.NAME = 'APP';

リスト8　ディスクI/O回数の確認

図7　リスト8の出力結果（クリックすると拡大します）

　データベース起動からの累計とある時間帯の回数を分析し、もし極端に回数が増えていれば問題があると考えられます。特に参照系データオブジェクトのデータファイルであるならば、ディスクI/Oの回数はそれだけレスポンス遅延に直結することを意識してください。

　8回にわたって解説してきた「Oracleパフォーマンス障害の克服」はいかがでしたでしょうか。実際の障害に直面したときに役に立つ項目、これだけは理解していないと障害を理解できない項目に絞って取り上げてきました。本来ならば開発と導入、運用が一体となって環境を構築していくべきですが、その状況をつくるのは難しくなっています。開発メンバーはSQLのチューニングだけ分かっていればいいとか、運用メンバーはリカバリの方法しか知らないなどという状況では、ユーザーに対して最大限のサービスを提供できないと思います。本連載で示したキーワードを元に、それぞれの立場からOracleへの理解を深めてほしいと思います。それが筆者の最大の願いです。ご愛読いただき、本当にありがとうございました。（連載完）

「Oracleパフォーマンス障害の克服」バックナンバー