Oracle 9.2.0.7 から 9.2.0.8 へのアップグレードを計画しています。提案されたアップグレードの主な理由は、DBMS_STATS.GATHER_SCHEMA_STATS.
提案されたアップグレードが Java アプリケーションに悪影響を及ぼしたり、最悪の場合、Java アプリケーションでサポートされなくなる可能性があることを懸念しています。
Oracle 9.2.0.7 から 9.2.0.8 へのアップグレードが Java アプリケーションに悪影響を与えたり、Java アプリケーションが正しく機能しないようにするために、どのようなアプローチまたは戦略を講じることができますか。基本的に、アプリケーションが引き続き Oracle 9.2.0.8 をサポートすることを確認したいだけです。
ありがとうございました。
最初のステップは、正確な本番レイアウトと現在のソフトウェア（9.2.0.7）を使用してテストシステムをセットアップすることです。
少しの間実行して問題がないことを確認してから、テストシステムでアップグレードを実行し、少し長く実行して、何も壊れていないことを確認します。私はカウボーイ開発者について「5分間実行すれば大丈夫」タイプのテストについて話しているのではありません。可能であれば、すべての機能とパフォーマンスを徹底的にテストする必要があります。
テストのレベルに満足したら、本番環境に対して同じことを行うことを計画できます。
これはロケット科学ではありません。自分自身とサードパーティの両方のソフトウェアのアップグレードをテストできるプロダクションミラーを常に用意する必要があります。また、テストにもかかわらず、本番環境のアップグレードが失敗する可能性がある場合は、バックアウト戦略を立てる必要があります。
私たちはかなり妄想的であるため、実際には、可能な限り多くのことを行う前に、まったく新しいマシンをセットアップしました。次に、カットオーバー時に、現在の本番環境を無効にし、新しいマシンにまだ必要な転送を実行してから、それを起動してテストします。テスト中のいずれかの時点でアップグレードウィンドウで何かを修正できない場合は、古いマシンをオンラインに戻し、後で再試行します。障害の原因となった人のために、リアエンドで適切なキックを行います:-)
私は Paxdiablo の回答に賛成しました。本番システムのフルサイズのコピーで、できるだけ多くのアプリケーション カバレッジをテストする近道はほとんどありません。
一般的に、アップグレードで次の 2 つの質問に答えようとしていると思います。
9.2 という早い時期に、オプティマイザは実行計画の決定にシステム統計を含めると考えているため、テスト システムのハードウェアが本番環境と異なる場合は、少なくともその情報をテスト システムに持ち込み、オプティマイザの変数を削減する必要があります。
Oracle 11g にアップグレードして $$$$ を持っている場合は、Real Application Testing のライセンスを取得して構成できます。これにより、基本的に、テスト インスタンスでデータベース アクティビティを記録および再生して、これら 2 つの質問に答えることができます。
dpbradley＆paxdiabloによる優れた回答に加えて、データベースにパッチを適用する前に、Oracleサポートサイトsupport.oracle.comで、このパッチによって発生する可能性のある既知の問題を確認する価値があります。 ！！
Oracleサポートサイトにログインするには、有効なサポートライセンスが必要ですが、9.2.0.8に関する注記が以下に提出されています。
9.2.0.8パッチセット-可用性と既知の問題[ID388281.1]