« Gaunlet | メイン | Captivity »

マテリアライズドビューの高速リフレッシュが遅くなる現象についてのメモ

マテリアライズドビューの高速リフレッシュが遅くなる現象についてのメモ

マテリアライズドビューを高速リフレッシュする際は、
マスタテーブルのマテリアライズドビュー・ログを参照し更新状況をマテリアライズドビュー側に反映する。

この動作の処理時間が日に日に延びていき、いつしかDB全体のボトルネックと化したときの対応メモ。

先日関わったシステムは、よくあるようにリフレッシュジョブを組み一定期間でリフレッシュを行い、テーブルのレプリケーションを行っていた。

しばらくは順調に動作していたのだが、高負荷なバッチ処理をオンライン時間帯に
動作するようになってからリフレッシュ処理が遅延し、まれにORA-01555が発生していた。

確かに非常に高負荷なバッチ処理であった、
「なーんでこんなの日中に流すかなぁ!」なーんて思って、とりあえず
ORA-01555対策にUNDO_RETENTIONを延ばしたり対応していた。

ところが、日に日にDBが重くなる。
「ホニャホゲバッチのせいで、重いんだろうなあ」なーんておもっていたら
バッチが動いてなくても重くなるようになっていた。

こりゃよくないことが起こっている!っとAWRレポートを覗いてみると、
マテリアライズドビューログのPhysical Readが異様に多い。
80%も占めていた。

「な、なんじゅぁこりゃぁ???」

ってんで、空いている時間帯に試しにマテリアライズドビューログのトレースを
とってみる。

なんと、リフレッシュ時、マテリアライズドビューログをSelectするときはFullScanしているのだ。当然のことながらFullScanはHWMまで根こそぎ読み込む。

つまり、HWMが高いとリフレッシュに時間がかかるのだ。
じゃぁHWMがいつ上昇したか?
それはORA-01555が発生し、長期間リフレッシュを行わなかった時だ。
マテリアライズドビューログには大量の更新データが溜まり、HWMが上昇した。
だからPhysicalReadが増えたのだ。

なんてこった。どうすりゃいい?
マテリアライズドビューログをMOVEするかTRUNCATEするかのどちらか
しかない。
ひとまず、メンテナンス時間にマテリアライズドビューをロック後
マスタテーブル側に更新がない状態で、切り捨てを行い。
HWMを下げた。

その後、見事DBのレスポンスは復活。いやはや。

マテリアライズドビューログを読むときがFullScanってのが盲点だった。
あたりまえっちゃ当たり前なんだけど・・・。

コメントを投稿

About

2007年11月02日 14:34に投稿されたエントリーのページです。

ひとつ前の投稿は「Gaunlet」です。

次の投稿は「Captivity」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.35