Royは週末、金融機関のお客様がいくつかのシステムのOracle Database 11gR2 (11.2.0.2) へのアップグレードに立ち会っていました。十分にテストし、綿密に計画されていましたが、移行時に1個のデータベースだけがうまく移行できなかったのです（11gR2からJOB_QUEUE_PROCESSESの意味が変わった件については、Royのエントリを参照して下さい）。
昨日、Royからメッセージを受け取りました。その内容は、私は顧客が開いて重大なパフォーマンスの問題が原因で本稼動後に大規模なパフォーマンス問題のためにお客様がオープンしたサービスリクエスト(SR)をよく見て欲しい、ということでした。お客様はMUTEX S CONTENTIONをAWRで見ており、ADDMはクラスタ全体がスローダウンしているというレポートを出していました。BDEのサポートチームは深掘りして問題を診断してくれて本当に助かりました。しかし、解決策は非常に驚きの内容なのです。
2011年4月のPSU 11.2.0.2.2 (Patch 11724916) に修正パッチが含まれているというのです。
修正パッチがPSUに含まれているなら、この修正コードが有効になっていると考えますよね。少なくとも私はそう考えます。でも、Royが言うところの、「古い『隠れたバグ修正』のトリックが…」のせいで、コードがあっても有効にしなければならない、というのです。MOS (My Oracle Support) 10187168.8 によれば、有効にする必要があるということです。Bug:10187168 Enhancement to obsolete parent cursors if VERSION_COUNT exceeds a threshold
ということで、実際にこの隠しパラメータを設定する必要があります。
_cursor_features_enabled=1026それに加えて、このナイスなイベントをinit.ora/spfileに設定します。
events= "106001 trace name context forever, level 1024"インスタンスを立ち上げると…ほら、できあがり。パッチが有効になっています。
怖いですか、そんなことないですよ。
私は、OracleのRDBMSのサポートとして6年間勤務していた当時と同じく、まずパッチのReadMeを確認して、この内容がどこかで言及されているかどうかを確認していましたが、このバグを指している唯一の発言は以下のとおりです。
Bug 10264680 - INCORRECT VERSION_NUMBER REPORTED AFTER PATCH FOR 10187168 APPLIEDこのパラメータは、バージョンカウントが定義されたしきい値を超えた場合に、親カーソルを廃止するという機能拡張リクエストから生まれたものです。このしきい値は、新しいアンダースコア（_）の
_cursor_obsolete_thresholdで設定できます。
しかし、このPSUに含まれる他のパッチは、この新たに導入された下線イベント106001を知らないということが原因で、別途閾値を設定する必要があります。
事情がより複雑になっているのは、この修正を有効にするためには、
_cursor_features_enabledというアンダースコアで始まる値も設定する必要がある、ということなのです。（上記の私のコメントを参照）。
そして、この値はパッチレベルにより設定すべき値が異なります。例えばoracle 11.2.0.2なら1026を設定するのですが、Oracle 11.1.0.7であれば、18を設定する必要があります。
これらのパラメータはOracleのサポートによる指示の下に設定、調整して下さいますようお願いします。
原文はこちら。
http://blogs.oracle.com/UPGRADE/entry/upgrade_and_an_interesting_surprise
0 件のコメント:
コメントを投稿