前回は、UNDO表領域を変更する際の注意点を説明した。要求がある時の保存期間の指定や問題について検証していきたい。UNDO領域の必要なサイズを算出する前に、実際にファイルのサイズ制限のために使用できる領域がない場合、どのようにUNDO表領域が動作するのか試してみる。この際はUNDO_RETENTIONの値は関係ない。EXTEND属性を含めず、ファイルのサイズを小さめに作成する。その後、UNDO領域を使うような処理(インポート)を行なった。"HISTORY"当然の結果だが、選択したUNDO領域には使用可能な領域がないというオラクルのエラー(ORA-30036)が表示された。この結果は後に説明するが、V$UNDOSTATのカラム(NOSPACEERRCNT)から参照できるようになっている。この対処としては、UNDO表領域を増やすか、commitの頻度を増やすしか方法はない。域のサイズを算出するかが重要になってくる。以下の式により必要な領域サイズが算出される。DBS個々の項目内容は次の通りである。DB_BLOCK_SIZE2番目の値を求めるには、動的パフォーマンス・ビュー(V$UNDOSTAT)を使用する必要がある。このビューは、UNDO領域の監視とチューニングを行うための統計情報が含まれている。ビュー内の各行には、インスタンス内で10分ごとに収集された統計が表示され、現行の作業負荷に必要なUNDO領域の量を見積もることが可能である。このビューには7日サイクルによる合計1008行が含まれる。以下を実行すると、1秒間に使用するUNDOブロックの数が計算される。V$UNDOSTAT;BEGIN_TIMEとEND_TIMEがDATEデータのために、秒に変更するため86400(60*60*24)を掛けている。1秒間に使用する(作られる)UNDOブロックの数を大体100ぐらいにし、overheadは24とする。保存期間はフラッシュバック等を行ないたい為3時間(10800)にする。'DB_BLOCK_SIZE');UNDO情報の保存に必要な領域は、約16GBになる。思っていた以上に大きなサイズが必要という結果となった。負荷が高いシステムで、1秒間に使用する(作られる)UNDOブロックの数が高い環境はもちろんだが、UNDO情報を保存する期間を延ばす場合、UNDO表領域のサイズが非常に影響し、領域の問題となってくる。次回も、この動的パフォーマンス・ビュー(V$UNDOSTAT)に関して検証していく予定である。reserved.トップページ企業概要プライバシーポリシ。