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を新しいリリースにアップグレードする場合、アップグレード計画を作成、テストおよび検証することをお薦めします。

Oracle Databaseのアップグレード・テストでは、現行のOracle Databaseソフトウェアから新しいOracle Databaseリリースへのアップグレード・パスの計画とテストを実行します。Oracle Database Upgrade Assistant (DBUA)を使用するか、手動アップグレードを実行するか、またはAutoUpgradeユーティリティを使用するかに関係なく、アップグレードを計画およびテストすることをお薦めします。Oracle Data Pumpエクスポート/インポートなどのデータ移行方法または他のデータコピー方法を使用する場合も、計画およびテストが適用されます。選択するアップグレードまたはデータ移行方法に関係なく、変更を計画、テスト、および検証する必要があります。

最小テスト

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

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

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

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

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

高可用性テスト

サービス・レベル契約を継続して満たせるようにするには、アップグレードしたOracle Databaseシステムで高可用性テストの実行を計画します。

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

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

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

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

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

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

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

• Pro*C/C++アプリケーションとアップグレードしたデータベースとの互換性を確認するには、アップグレードしたOracle Databaseを使用してPro*C/C++アプリケーション・クライアントをテストします

• グラフィカル・ユーザー・インタフェースをテストします。

• データベースと直接的または間接的に相互作用するすべてのアプリケーションをテストします。アップグレードされたOracle Databaseのデータ型やデータ・ディクショナリのデータなどのわずかな変更(データ・ディクショナリの追加行、オブジェクト型の変更など)が、アップグレードされたOracle Databaseインスタンスに直接接続されていないフロントエンド・アプリケーションにも影響する可能性があります。

• コンポーネント間のOracle NetまたはOracle Net Services接続のテストおよびストレス・テストを行います。

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

以前のリリースとアップグレードしたOracle Database間でパフォーマンス・テストの比較を計画します。

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

本番システムと同じストレージ、データおよびその他の特性を持つテスト・システムを設定することをお薦めします。

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

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

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

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

ノート:

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

参照:

• ワークロードの取得およびリプレイ方法の詳細は、『Oracle Database Testingガイド』を参照してください。

• 自動ワークロード・リポジトリの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

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

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

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

参照:

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

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計画ベースラインとして既存または新規の計画履歴に追加されます。

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

2. データベースをアップグレードします。

参照:

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

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

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

1. Oracle Databaseのソース・リリースで、各SQL文の実行計画を含むSTSを作成します。

2. STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。

3. ステージング表をダンプ・ファイルからOracleの新しいリリースにインポートし、STSをアンロードします。

4. Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。

参照:

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

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

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

1. Oracle Database 12cのテスト・システムで、すべてのテストとチューニングを完了してから、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。

2. DBMS_SPM.CREATE_STGTAB_BASELINEプロシージャを使用して、ステージング表を作成します。

3. DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、ステップ1で作成したSQL計画ベースラインをステージング表に格納します。

4. データ・ポンプを使用して、ステージング表をフラット・ファイルにエクスポートします。

5. このフラット・ファイルをターゲット・システムに転送します。

6. データ・ポンプを使用して、フラット・ファイルからステージング表をインポートします。

7. DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。

• SQL計画管理を実行する理由
  Oracle Databaseのアップグレード後のパフォーマンスの低下を防ぐために、SQL計画管理を実行します。
• カーソル・キャッシュからのSQL管理ベースのバルク・ロード
  カーソル・キャッシュからの実行計画またはSQL計画ベースラインのバルク・ロードは、以前のリリースをOracle Databaseの最新リリースにアップグレードする場合に役立ちます。
• SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード
  実行計画またはSQL計画ベースラインのバルク・ロードは、自動ワークロード・リポジトリから履歴計画をロードする場合に役立ちます。
• ステージング表からの既存のSQL計画ベースラインの展開
  DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEを使用してテスト用に移行可能なステージング表を作成することにより、重要なSQL問合せおよび実行計画をテストします。

参照:

• ステージング表からの計画のロードの詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。

• データ・ポンプの使用については、『Oracle Databaseユーティリティ』を参照してください。

SQL計画管理を実行する理由

Oracle Databaseのアップグレード後のパフォーマンスの低下を防ぐために、SQL計画管理を実行します。

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

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

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

実行計画またはSQL計画ベースラインのカーソル・キャッシュからのバルク・ロードは、以前のリリースをOracle Databaseの最新リリースにアップグレードする場合に役立ちます。

カーソル・キャッシュは、共有SQL領域です。バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。

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

2. データベースをアップグレードします。

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

実行計画またはSQL計画ベースラインのバルク・ロードは、自動ワークロード・リポジトリから履歴計画をロードする場合に役立ちます。

実行計画またはSQL計画のベースラインのバルク・ロードは、SQLチューニング・セットを使用して実行できる場合があります。これは、以前のOracle Database自動ワークロード・リポジトリから履歴計画をロードする場合に役立ちます。

1. Oracle Databaseのソース・リリースで、各SQL文の実行計画を含むSTSを作成します。

2. STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。

3. ステージング表をダンプ・ファイルからOracleの新しいリリースにインポートし、STSをアンロードします。

4. Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。

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

DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEを使用してテスト用に移行可能なステージング表を作成することにより、重要なSQL問合せおよび実行計画をテストします。

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

1. 新しいOracle Databaseリリースのテスト・システムで、すべてのテストとチューニングを完了してから、DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHEプロシージャまたはEnterprise Managerを使用して、カーソル・キャッシュ内の実行計画をすべてSQL管理ベースにロードします。

2. DBMS_SPM.CREATE_STGTAB_BASELINEプロシージャを使用して、ステージング表を作成します。

3. DBMS_SPM.PACK_STGTAB_BASELINEファンクションを使用して、ステップ1で作成したSQL計画ベースラインをステージング表に格納します。

4. Oracle Data Pumpを使用して、ステージング表をフラット・ファイルにエクスポートします。

5. このフラット・ファイルをターゲット・システムに転送します。

6. Oracle Data Pumpを使用して、フラット・ファイルからステージング表をインポートします。

7. DBMS_SPM.UNPACK_STGTAB_BASELINEファンクションを使用して、ステージング表からターゲット・システムのSQL管理ベースにSQL計画ベースラインを展開します。

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

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

Oracleリプレイは、アップグレードされたOracle Databaseリリースを本番に移行する前に、ロードの問題を明らかにするために役立ちます。ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。したがって、実際の本番システムのボリュームとロードを取得してリプレイするときに、アップグレードしたOracle Databaseのロードをエミュレートし、様々なボリュームとロードでのパフォーマンスを観察できます。

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

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

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

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

• テスト結果を比較し、相違点を記録します。

• 問題が解決されるまで、必要な回数、テスト・アップグレードを繰り返します。

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

• 利用可能なOracle Databaseの機能を追加して、拡張された機能および新しい機能についてテストします。

• アプリケーションが現行のデータベースの場合と同様に動作することを確認します。

参照:

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