UNDOに関する検証　その６

＜UNDOに関する検証その６＞
ペンネーム：クレイジーボーダー

先週は、UNDO情報を保存するのに必要な領域を、統計情報を基に下記の式から
算出した。結果は、UNDO表領域のサイズが非常に問題となる可能性があるとい
うことになった。今週はもう少しこの点に関して詰めていきたい。

UNDOの保存に必要な領域 = (UR * UPS + OVERHEAD) * DBS

UNDO表領域のサイズが非常に大きくなる可能性があるということは、逆に考え
れば、サイズ制限のあるファイルシステム内では、UNDOデータをどれくらいの
期間保存できるかということに関係してくる。

今回は、UNDO表領域本来のロールバックという観点からではなく、フラッシュ
バックを行なうためのデータを保存する期間という点に主観を置いて検証して
いく。

例えば、UNDO表領域で使用するファイルシステムは4GBまでの制限があると仮
定する。以下が今回の設定値の内容である。

– ブロックサイズは2K (DBS)
– 負荷のピーク時の1秒間に使用する(作られる)UNDOブロックの数は
大体40ぐらい (UPS)
– OVERHEADを24

以下の式を基にUNDO_RETENTIONを算出する。

UNDO_RETENTION = (UNDOデータの保存に必要な領域 / DBS – OVERHEAD) / UPS

実際にSQL文を発行する。

SQL> SELECT (((4 * 1024 * 1024 * 1024) / DBS - 24) / UPS)
     as "UNDO_RETENTION"
     FROM
    (SELECT (SUM(UNDOBLKS)/SUM((END_TIME - BEGIN_TIME) * 86400))
     AS UPS
     FROM V$UNDOSTAT),
    (SELECT VALUE AS DBS
     FROM V$PARAMETER
     WHERE NAME = 'DB_BLOCK_SIZE');

UNDO_RETENTION
52428.2

UNDOデータを約14時間保存できることを意味する。すなわち、今回のケースで
は理論上、過去14時間以内の情報であれば、フラッシュバック機能を利用し、
過去のある時点に戻って検索を行なったりすることができる。実際はその環境
毎に必要なオーバヘッドや、理論値に達した時に、更にロールバックができる
十分な領域を考慮するとUNDOデータの保存期間は短くなる。

また、アプリケーション側でコミットされる間隔が長くなったり、1秒間に使
用する(作られる)UNDOブロックの数が多くなると、サイズ制限のあるファイル
システム内では、UNDOデータの保存期間が更に短くなる。

結果として、オラクルのエラーが頻繁に起きるようになる。
例えば、スナップショットが古すぎますというオラクルのエラー（ORA-1555）
や選択したUNDO領域には使用可能な領域がないというオラクルのエラー
（ORA-30036）が起きてしまう。

ただし、逆にUNDOデータを保存する期間を長く取る必要がある場合、データフ
ァイルサイズを大きくする。又は領域に余裕のあるディスクに新しくUNDO表領
域を作成し、ALTER SYSTEMコマンドを実行し、新しく作成したUNDO表領域を使
用する必要がある。

結果として、UNDO自動管理機能では、初期化パラメータ(UNDO_RETENTION)を
変更するだけで、読取り一貫性のエラー（ORA-01555:スナップショットが古す
ぎます）などを制御しやすくなり、特別なチューニング等を必要としないの
で管理に要するコストが減ったが、自動管理に任せてしまうと、逆に領域な
どの単純な問題にぶつかってしまうことがある。

ロールバック・セグメントを使用した手動管理のように、システムの特徴を
知り尽くした技術者が監視、チューニングを行うシステムは素晴らしい
パフォーマンスが得られる。だから、自動管理と言っても、手動管理を行なう
ように、定期的な監視が必要である。

さて、領域の対処策として考えられるUNDO QUOTAについて検証していきたい。

以上、ただいま時差ボケ中の茅ヶ崎にて。

UNDOに関する検証 その６