Oracle Databaseのアップグレードでのテスト計画の開発

アップグレード処理のすべてのステージを検証するために慎重に設計された一連のテストを作成する方法を理解するには、これらのトピックを参照してください。

データベースとアプリケーションの厳密なテストを実行することをお薦めします。テストを正常に実行して完了すると、本番データベースのアップグレード処理を確実に理解して、アップグレード処理を予測可能な状態で正常に実行できます。本番データベースをアップグレードする前に、可能なかぎり十分なテストを実行することを強くお薦めします。完全で反復可能なテスト処理は、非常に重要です。

手動でテストを実行するか、テストを支援するユーティリティ(たとえば、データベース・リプレイやSQLパフォーマンス・アナライザなどのOracle Real Application Testing機能)を使用するかを選択できます。どちらの場合でも、実行するテストのタイプは同じです。

テスト計画には次のタイプのテストを含める必要があります。

アップグレード・テスト
アップグレード計画を作成、テストおよび検証します。
最小テスト
新しいリリースのテスト環境でアプリケーションの最小テストを実行すると、アプリケーションの起動または呼出しに関する問題を検出できます。
アップグレード後の機能テスト
アップグレードが完了した後に、アップグレードしたOracle Databaseの機能テストを実行します。
高可用性テスト
アップグレードしたシステムで高可用性テストを実行することを計画します。
アプリケーションの互換性を確保する統合テスト
Oracle Databaseの統合テストでは、システムのコンポーネント間で相互作用を調査します。
アップグレードしたOracle Databaseのパフォーマンス・テスト
以前のリリースと新しいリリースのOracle Database間でパフォーマンス・テストの比較を計画します。
Oracle Databaseのアップグレードでのボリューム/ロード・ストレス・テスト
データベース・リプレイを使用して、アップグレードしたOracle Database全体を、大きいボリュームとロードでボリューム/ロード・ストレス・テストを実行します。
Oracle Databaseアップグレード計画のテスト計画のガイドライン
現行のデータベースおよび新しいOracle Databaseリリースにアップグレードしたテスト・データベースに対して、計画したテストを実行します。

親トピック: Oracle Databaseのアップグレードを準備する作業

アップグレード・テスト

アップグレード計画を作成、テストおよび検証します。

Oracle Databaseのアップグレード・テストでは、Oracle Database Upgrade Assistant (DBUA)の使用、手動アップグレードの実行、エクスポート/インポートまたはその他のデータのコピー方法を使用するかに関係なく、現行のソフトウェアからOracle Database 12cへのアップグレード・パスを計画およびテストする必要があります。どのアップグレード方法を選択する場合でも、アップグレード計画を作成、テストおよび検証する必要があります。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

最小テスト

新しいリリースのテスト環境でアプリケーションの最小テストを実行すると、アプリケーションの起動または呼出しに関する問題を検出できます。

Oracle Databaseの最小テストでは、現行のデータベースからアプリケーションの全部または一部を新しいデータベースに移動し、データベースの新機能を使用可能にしないでアプリケーションを実行します。最小テストでは、実際の本番環境で発生する問題が明らかにならない可能性があります。ただし、アプリケーションの起動または呼出しに関する問題がある場合は、すぐに検出されます。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

アップグレード後の機能テスト

アップグレードが完了した後に、アップグレードしたOracle Databaseの機能テストを実行します。

Oracle Databaseの機能テストとは、システムの新機能と既存機能をアップグレード後にテストする一連のテストです。機能テストには、すべてのデータベース、ネットワーキングおよびアプリケーション・コンポーネントのテストが含まれます。機能テストの目的は、システムの各コンポーネントがアップグレード前と同様に機能し、新機能が正常に動作していることを検証することです。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

高可用性テスト

アップグレードしたシステムで高可用性テストを実行することを計画します。

Oracle Databaseの高可用性テストでは、アップグレードしたデータベース・システムが次のリカバリ・ビジネス要件を満たしていることを確認します。

リカバリ時間目標(RTO)
リカバリ・ポイント目標(RPO)

高可用性テストでは、次のテスト手順をお薦めします。

ストレス・テスト中にノードまたはインスタンス障害を作成します。ノードまたはインスタンス障害は、Oracle RACのリカバリ機能を評価するために役立ちます。
アップグレードしたデータベースの停止時間を最小化できるように、フォールバック計画および手順をテストします。
データベースのパフォーマンスおよび安定性を確認し、パフォーマンスの問題を解決します。パフォーマンスの問題を解決すれば、割り当てた時間内にアップグレード・プロセスが確実に実行できるようになります。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

アプリケーションの互換性を確保する統合テスト

Oracle Databaseの統合テストでは、システムのコンポーネント間で相互作用をテストします。

統合テストの一部として次のテストを実行することをお薦めします。

Oracle Database 12cインスタンスのPro*C/C++アプリケーション・クライアントをテストして、これらのアプリケーションがアップグレードしたデータベースと互換性を持つことを確認します。
グラフィカル・ユーザー・インタフェースをテストします。
データベースと直接的または間接的に相互作用するすべてのアプリケーションをテストします。データ型やデータ・ディクショナリのデータ(データ・ディクショナリへの行の追加、オブジェクト・タイプの変更)などのOracle Database 12cのわずかな変更は、フロントエンド・アプリケーションが新しいOracle Database 12cインスタンスに直接接続されていなくても、それらのアプリケーションに影響することがあります。
コンポーネント間のOracle NetまたはOracle Net Services接続のテストおよびストレス・テストを行います。

ノート:

Pro*C/C++アプリケーションの詳細は、『Pro*C/C++プログラマーズ・ガイド』を参照してください。

Oracle Net Servicesのアップグレードに関する推奨事項については、『Oracle Database Net Servicesリファレンス』を参照してください。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

アップグレードしたOracle Databaseのパフォーマンス・テスト

以前のリリースと新しいリリースのOracle Database間でパフォーマンス・テストの比較を計画します。

新しいOracle Databaseのパフォーマンス・テストでは、新しいデータベースでの様々なSQL文のパフォーマンスを、現行データベースでの同じ文のパフォーマンスと比較します。アップグレードする前に、現行データベースでのアプリケーションのパフォーマンス・プロファイルを分析します。特に、アプリケーションがデータベース・サーバーに対して実行するコールを分析して理解します。

データベース・リプレイとパフォーマンス・テスト
データベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できます。
SQLパフォーマンス・アナライザ
SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測します。
SQL計画管理
パフォーマンスの低下を避けるためにアップグレード後にSQL計画管理を実行する方法を理解するには、このトピックを参照してください。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

データベース・リプレイおよびパフォーマンス・テスト

新しいデータベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できます。

データベース・リプレイ機能は、本番システム上で実際のデータベースのワークロードを取得して、これをテスト・システム上でリプレイします。また、データベース・リプレイでは、潜在的な問題(エラーの発生やパフォーマンスの相違など)を示す分析とレポート作成も提供されます。さらに、自動データベース診断モニター、自動ワークロード・リポジトリ(AWR)およびアクティブ・セッション履歴など、定期的なEnterprise Managerパフォーマンスの監視およびレポート作成ツールをすべて使用して、問題に対処します。

ノート:

データベース内のストアド・プロシージャのロジックを変更できます。ただし、アプリケーション・ロジックを実装しているストアドPL/SQLプロシージャでは、アップグレード前と同じインタフェースを維持する必要があります。アプリケーションのストアド・プロシージャがアップグレードによって影響を受ける場合は、ワークロードをリプレイできない場合があります。同じインタフェースでデータベース・リプレイ・ツールを使用すると、サーバー内の新しいアプリケーション・ロジックがアップグレード後にも期待どおりに動作するかどうかを確認でき、有効な診断が行えます。

参照:

ワークロードの取得およびリプレイ方法の詳細は、『Oracle Database Testingガイド』を参照してください。
自動ワークロード・リポジトリの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

親トピック: アップグレードしたOracle Databaseのパフォーマンス・テスト

SQLパフォーマンス・アナライザ

SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測します。

SQLパフォーマンス・アナライザによって、SQLワークロードへのアップグレードの影響を評価できます。SQLパフォーマンス・アナライザはアップグレードにより影響を受けるSQL文を特定することにより、起こりうる問題を検出します。次に、アップグレード前とアップグレード後のSQLワークロードのパフォーマンスの相違を測定します。この分析により、ユーザーはSQLパフォーマンスに対する全体的な影響を評価できます。そうすれば、SQLワークロードの変更がユーザーに影響を与える前に、変更の結果の悪影響を避けるための対策を講じることができます。

参照:

潜在的なデータベース変更の分析にSQLパフォーマンス・アナライザを使用した詳細および例は、『Oracle Database Testingガイド』を参照してください。

親トピック: アップグレードしたOracle Databaseのパフォーマンス・テスト

SQL計画管理

パフォーマンスの低下を避けるためにアップグレード後にSQL計画管理を実行する方法を理解するには、このトピックを参照してください。

新しいバージョンのオプティマイザをインストールするデータベースのアップグレードでは、通常、ほんのわずかなSQL文に対して計画の変更が発生します。ほとんどの計画の変更においてパフォーマンスに変化や向上は見られません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。SQL計画の管理を使用すると、SQL計画の情報を取得、選択および改良するためのコンポーネントが用意されているため、SQL文の実行計画に対する突然の変更によるパフォーマンスの低下を回避できます。SQL計画管理は、一定期間におけるSQL文の実行計画を記録および評価する予防的メカニズムであり、反復的な使用により効率的であることが証明されている既存の計画セットで構成されたSQL計画のベースラインを構築します。SQL計画管理では、システムで発生している変更に関係なく、対応するSQL文のパフォーマンスを保持するためにSQL計画のベースラインを使用します。

SQL計画管理を使用すると、オプティマイザによって実行計画が自動的に管理され、既知の計画または検証済の計画のみが使用されます。SQL計画管理は、SQL文に新しい計画を見つけると、データベースが新しい計画の互換性を確認するか、現在の計画よりも高いパフォーマンスを検出するまで、この計画を使用しません。SQL計画管理を現行の実行計画でシードすると、それらの計画は各文のSQL計画のベースラインになります。オプティマイザは、アップグレード後にこれらの計画を使用します。異なる計画でパフォーマンスが向上する可能性があるとOracle Database 12cオプティマイザが判断した場合でも、新しい計画は検証のためにキューに格納され、現行の計画と同等かそれ以上のパフォーマンスを実現できる計画であることが確認されるまでは、使用されません。

SQL管理ベース(SMB)を実行計画にシードまたは移入するには、複数の方法があります。

カーソル・キャッシュからのSQL管理ベースのバルク・ロード

実行計画またはSQL計画ベースラインのカーソル・キャッシュからのバルク・ロードは、データベースをOracle Database 11gからOracle Databaseの最新リリースにアップグレードする場合に役立ちます。カーソル・キャッシュは共有SQL領域で、バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。

Oracle Databaseのソース・リリースでは、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはOracle Enterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。
データベースをアップグレードします。

参照:

共有SQL領域からPL/SQLまたはOracle Enterprise Managerを使用して計画をロードする方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード

実行計画またはSQL計画のベースラインのバルク・ロードは、SQLチューニング・セットを使用して実行できる場合があります。これは、カーソル・キャッシュから直接ロードするため、または自動ワークロード・リポジトリから履歴計画をロードするためのSQL Management Base (SMB)がないOracle Database 10gからアップグレードを行う場合に役立ちます。

Oracle Databaseのソース・リリースで、各SQL文の実行計画を含むSTSを作成します。
STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。
ステージング表をダンプ・ファイルからOracleの新しいリリースにインポートし、STSをアンロードします。
Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。

参照:

実行計画またはSQL計画のベースラインのバルク・ロードの詳細な手順は、『Oracle Database SQLチューニング・ガイド』を参照してください。

ステージング表からの既存のSQL計画ベースラインの展開

すべての重要なSQL問合せをOracle Databaseのテスト環境でテストおよびチューニングしてから、そのSQL実行計画をOracle Databaseの本番環境に移動できます。または、アップグレード前Oracle Databaseの本番環境からSQL問合せの計画を実行してから、アップグレード後の本番環境にそれらを移動できます。

Oracle Database 12cのテスト・システムで、すべてのテストとチューニングを完了してから、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。
DBMS_SPM.CREATE_STGTAB_BASELINEプロシージャを使用して、ステージング表を作成します。
DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、ステップ1で作成したSQL計画ベースラインをステージング表に格納します。
データ・ポンプを使用して、ステージング表をフラット・ファイルにエクスポートします。
このフラット・ファイルをターゲット・システムに転送します。
データ・ポンプを使用して、フラット・ファイルからステージング表をインポートします。
DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。

参照:

ステージング表からの計画のロードの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
データ・ポンプの使用については、『Oracle Databaseユーティリティ』を参照してください。

親トピック: アップグレードしたOracle Databaseのパフォーマンス・テスト

Oracle Databaseのアップグレードでのボリューム/ロード・ストレス・テスト

データベース・リプレイを使用して、アップグレードしたOracle Database全体を、大きいボリュームとロードでボリューム/ロード・ストレス・テストを実行します。

ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。ボリューム/ロード・ストレス・テストは、様々なボリュームとロードでの本番システムの動作をエミュレートできます。

ボリューム/ロード・ストレス・テストは非常に重要です。しかしそれは一般に見過ごされています。ユーザーは、どのようなボリューム/ロード・ストレス・テストも実行しないことが多いようです。そのかわりに、ビジネス・アプリケーションを特に考慮しているわけではないベンチマークが広く利用されています。Oracleではアプリケーションのベンチマークを実行するよう、お薦めしています。ベンチマークは機能、パフォーマンス、統合に関連した問題を明らかにします。ただし、ベンチマークはボリューム/ロード・ストレス・テストに代わるものではありません。

ロード・テストには、新しいOracle Databaseリリースに対してアプリケーションのロードを実行することも含まれます。ロード・テストにより、本番環境で見られそうなロード条件下でアプリケーションが新しいエラーやパフォーマンス問題などの問題に遭遇しないことが保証されます。多くの場合、問題は特定のロード条件でのみ明らかになるため、通常、機能テストでは見つかりません。データベース・リプレイ機能はそうしたロード・テストに最適です。データベース・リプレイでは、本番環境のシステム・ワークロードを取得し、テスト・システムでそれを同じようにリプレイできます。

参照:

ストレス・テストでのデータベース・リプレイの使用の詳細は、『Oracle Database Testingガイド』を参照してください。

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発

Oracle Databaseアップグレード計画のテスト計画のガイドライン

現行のデータベースおよび新しいOracle Databaseリリースへアップグレードされたテスト・データベースに対して、計画したテストを実行します。

テスト結果を比較し、相違点を記録します。
問題が解決されるまで、必要な回数、テスト・アップグレードを繰り返します。

新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。

利用可能なOracle Databaseの機能を追加して、拡張された機能および新しい機能についてテストします。
アプリケーションが現行のデータベースの場合と同様に動作することを確認します。

参照:

データベースのアップグレードのテストの詳細は、『Oracle Database Testingガイド』を参照してください

親トピック: Oracle Databaseのアップグレードでのテスト計画の開発