| Oracle® Databaseアップグレード・ガイド 11g リリース2(11.2) B56310-08 |
|
 前 |
 次 |
Oracle Databaseのアップグレード処理には、システムの考慮点および要件の理解と、実際にアップグレード手順を実行する前の様々な問題のトラブルシューティングが含まれます。Oracle Databaseをアップグレードする前に、新しい機能および動作の変更点について詳しく理解しておく必要があります。アップグレードに備えて、新しいOracleソフトウェアをインストールします。このリリースの新しいOracleソフトウェアでは、最新のアップグレード前情報ツールを提供していますので、簡単に要件を理解してアップグレード前の処理を完了できます。
この章の内容は次のとおりです。
Oracle Databaseのアップグレードに備えて、新しい機能を確認し、最適なアップグレード・パスおよびアップグレード方法を決定します。アップグレード処理をテストし、バックアップ計画を準備することをお薦めします。
アップグレードの準備として、次の作業を行います。
アップグレード処理を計画する前に、新しいOracle Database 11gリリースの機能を理解します。Oracle Databaseのリリース間の相違点については、『Oracle Database新機能ガイド』を参照してください。特定のコンポーネントの新機能については、Oracle Database 11gのドキュメント・ライブラリにある固有のガイドを参照してください。たとえば、Oracle Real Application Clustersの変更点については、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
|
注意:
|
|
関連項目: My Oracle Support(https://support.oracle.com)のNote ID 854428.1「Patch Set Updates for Oracle Products」 |
新しいOracle Database 11gリリースへアップグレードするために必要なパスは、現行のデータベースのリリース番号によって異なります。現行のリリースのOracle Databaseから最新のリリースに直接アップグレードできない場合があります。現行のリリースによっては、新しいOracle Database 11gリリースへのアップグレードに、1つ以上の中間リリースを介したアップグレードが必要となる場合があります。
たとえば、現行のデータベースがリリース9iを実行している場合は、次の手順に従います。
リリース2(10.2)の『Oracle Databaseアップグレード・ガイド』の指示に従って、リリース9.0.1.4からリリース10.2.0.4へアップグレードします。
このマニュアルの指示に従って、リリース10.2.0.4から新しいOracle Database 11gリリースへアップグレードします。
表2-1に、Oracle Databaseのリリースごとに必要なアップグレード・パスを示します。ご使用のデータベースに固有のアップグレード・パスおよびドキュメントを使用してアップグレードします。
表2-1 Oracle Databaseのアップグレードに対してサポートされているアップグレード・パス
| 現行リリース | アップグレード・パス |
|---|---|
|
9.0.1.3以下 |
直接のアップグレードはサポートされていません。次のように、新しいOracle Database 11gリリースへアップグレードする前に、中間リリースのOracle Databaseにアップグレードする必要があります。
Oracle Databaseの中間リリースのドキュメントの指示に従って、中間リリースへアップグレードします。次に、第3章「Oracle Databaseの新しいリリースへのアップグレード」の指示に従って、中間リリースのデータベースを新しいOracle Database 11gリリースにアップグレードします。 |
|
9.2.0.8 10.1.0.5 10.2.0.2 11.1.0.6 |
9.2.0.8以上、10.1.0.5以上、10.2.0.2以上および11.1.0.6以上から新しいOracle Database 11gリリースへの直接のアップグレードがサポートされています。Oracle Clusterwareリリース10.2.0.nは、リリース10.2.0.3以上にしてからOracle Clusterware 11gにアップグレードする必要があることに注意してください。「Oracle Real Application Clusters(Oracle RAC)Databaseのアップグレードの概要」を参照してください。 リリース9.2.0.3の場合は、次のように、まず中間リリースのOracle Databaseにアップグレードする必要があります。 9.2.0.3(以下)→ 9.2.0.8 → 11.2 第3章「Oracle Databaseの新しいリリースへのアップグレード」の指示に従って、新しいOracle Database 11gリリースにアップグレードします。 |
データベースを新しいOracle Database 11gリリースへアップグレードする際に使用できる方法は次のとおりです。
Database Upgrade Assistant(DBUA)は、対話形式でアップグレード処理の手順を実行し、新しいOracle Database 11gリリースのデータベースを構成します。DBUAを使用すると、通常は手動で実行するアップグレード処理のすべてのタスクが自動化されます。DBUAでは、表領域、REDOログなどの構成オプションの適切な推奨値が提供されます。ユーザーは、この推奨値を使用できます。
DBUAでは、Oracle Real Application Clusters(Oracle RAC)がサポートされています。Oracle RAC環境では、DBUAは、クラスタ内のすべてのノードにあるすべてのデータベースおよび構成ファイルをアップグレードします。
手動アップグレードでは、コマンドラインからSQLスクリプトおよびユーティリティを実行して、データベースを新しいOracle Database 11gリリースへアップグレードします。
手動アップグレードでは、アップグレード処理をより詳細に制御できますが、実行されなかったアップグレード手順またはアップグレード前の手順がある場合、または不適切な順序で実行された場合にエラーが発生する可能性がより高くなります。
次のリストに、手動のアップグレード手順の概要を示します。
アップグレード前情報ツールを使用して、データベースを分析します。アップグレード前情報ツールは、新しいOracle Database 11gリリースに付属するSQLスクリプトであり、DBUAでは、アップグレード処理の一部としてこのスクリプトが使用されます。アップグレードするデータベースでこのスクリプトを実行します。
アップグレード前情報ツールでは、データベースで発生する可能性のあるアップグレードの問題に関する警告が表示されます。また、新しいOracle Database 11gリリースで必要な初期化パラメータの情報が表示されます。
新しいOracleホームを準備します。
データベースのバックアップを実行します。
アップグレードしているデータベースのリリースに応じて、次のような追加のアップグレード前の手順が必要な場合があります。
アップグレードに向けたパラメータ・ファイルの調整
廃止された初期化パラメータの削除
アップグレードの問題が発生する可能性のある初期化パラメータの調整
|
関連項目: 『Oracle Database管理者ガイド』および『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
COMPATIBLEパラメータが明示的に設定されていない場合は、このパラメータを設定します。
DBUAまたは手動アップグレードとは異なり、Oracle Data Pump Export/Importユーティリティは、現行のデータベースのデータを新しいデータベースに物理的にコピーします。Oracle Database 10gリリース1(10.1)以上からアップグレードする場合は、パフォーマンス向上および新しいデータ型サポートの点から、データ・ポンプ・エクスポート/インポートを使用することをお薦めします。
現行のデータベースのエクスポート・ユーティリティは、データベースの特定部分をエクスポート・ダンプ・ファイルにコピーします。次に、新しいOracle Database 11gリリースのインポート・ユーティリティが、このエクスポートされたデータを新しいデータベースにロードします。ただし、エクスポート・ダンプ・ファイルからロードする前に、新しいOracle Database 11gのデータベースを準備しておく必要があります。
以前のリリースからデータをインポートする場合、新しいOracle Database 11gリリースのインポート・ユーティリティでは、以前のリリースのエクスポート・ダンプ・ファイルを読み込む際に、データ定義に適切な変更を加えます。
次の項では、データベースのアップグレードにエクスポート/インポートを使用するかどうかを決定する際に有効な、エクスポート/インポートの特長について説明します。
|
注意:
|
エクスポート/インポートによるアップグレード方法では、現行のデータベースが変更されないため、データベースはアップグレード処理を通して常に使用可能な状態です。ただし、一貫性のあるデータベースのスナップショットが必要な場合(データの整合性保持またはその他の目的のため)、データベースは、制限モードで実行するか、またはエクスポート手順の実行中は変更禁止にする必要があります。現行のデータベースを使用可能な状態にしておくことができるため、たとえば、既存の本番データベースを実行しながら、エクスポート/インポートによる新しいOracle Database 11gデータベースの作成を同時に行うことができます。このアップグレード処理中にデータベースの完全な一貫性を維持するには、データベースのデータを変更する場合に、新しいOracle Database 11gデータベースにも同じ変更を加える必要があります。
最も重要なことは、エクスポート/インポート操作の結果として、新しいデータベースが作成されることです。現行のデータベースには最終的に指定したデータのコピーが含まれますが、アップグレードしたデータベースは、元のデータベースとは異なる方法で運用される場合があります。たとえば、エクスポート/インポート操作によってデータベースと同一のコピーを作成しても、データのディスク配置やチューニング・パラメータの解除など、その他の要素が予期しないパフォーマンスの劣化につながることがあります。
データ・ポンプ・エクスポート/インポートを使用したアップグレード:
データの断片化を解消できます。インポートされたデータを圧縮することによって、パフォーマンスを向上できます。
データベースを再構築できます。新しい表領域を作成するか、または既存の表や表領域、インポートによってデータがロードされる先のパーティションを変更できます。
完全に新しいデータベースが作成されるため、Oracle Databaseの新旧バージョンの比較テストを行うことができます。
指定されたデータベース・オブジェクトまたはユーザーをコピーできます。オブジェクト、ユーザーおよびその他の必要な項目のみをインポートすると、本番データのサブセットにのみ新規ソフトウェアのテスト環境を確立する場合に役に立ちます。データ・ポンプ・エクスポート/インポートでは、データのサブセット化機能を柔軟に使用できます。
バックアップ・アーカイブとして機能します。データベースの全体エクスポートを現行のデータベースのアーカイブとして使用できます。
アップグレードするデータベースをサポートしていないオペレーティング・システムまたはハードウェア・プラットフォーム上に、アップグレードしたデータベースを確立できます。ネットワーク・ベースのデータ・ポンプ・インポートにより、新規Oracle Databaseは、アップグレード対象の古いデータベースからネットワークを介して直接ロードできます。したがって、ダンプ・ファイルが介在する必要はありません。
新しいOracle Database 11gリリースに、現行のリリースのOracleホームとは別のOracleホームの場所を選択する必要があります。Oracle Database 11gのパッチ・セット・リリースをインストールしないかぎり、新しいソフトウェアを現行のリリースと同じOracleホームの場所にインストールすることはできません。パッチ・セット・リリースの場合、Oracle Database 11gと同じOracleホームを使用できます。
別のインストール・ディレクトリを使用すると、既存のソフトウェアをインストールしたままで、新しいソフトウェアを使用できます。この方法によって、本番環境全体を置き換える前にテスト・データベース上でアップグレード処理をテストできます。
アップグレード処理のすべての段階を検証するために、一連のテストを慎重に設計する必要があります。緻密なテストを正常に完了できれば、本番データベースのアップグレード処理を十分に理解し、予測できるようになり、アップグレード処理の成功が確実になります。本番データベースをアップグレードする前に、できるだけ多くのテストを実行してください。完全で反復可能なテスト処理は、非常に重要です。
データベース・リプレイやSQLパフォーマンス・アナライザなどのReal Applicationのテスト機能を使用するか、または手動でテストを実行するかに関係なく、実行するテストのタイプは同じです。
テスト計画には次のタイプのテストを含める必要があります。
アップグレード・テストでは、DBUAの使用、手動アップグレードの実行、エクスポート/インポートまたはその他のデータのコピー方法を使用するかに関係なく、現行のソフトウェアから新しいOracle Database 11gリリースへのアップグレード・パスを計画およびテストする必要があります。どのアップグレード方法を選択する場合でも、アップグレード計画を作成、テストおよび検証する必要があります。
最小テストでは、現行のデータベースからアプリケーションの全部または一部を新しいデータベースに移動し、データベースの新機能を使用可能にしないでアプリケーションを実行します。最小テストでは、実際の本番環境で発生するような問題が検出されない場合があります。ただし、アプリケーションの起動または呼出しに関する問題がある場合は、すぐに検出されます。
機能テストとは、システムの新機能と既存機能をアップグレード後にテストする一連のテストです。機能テストには、すべてのデータベース、ネットワーキングおよびアプリケーション・コンポーネントのテストが含まれます。機能テストの目的は、システムの各コンポーネントがアップグレード前と同様に機能し、新機能が正常に動作していることを検証することです。
高可用性テストでは、次が行われます。
アップグレードしたシステムが、引き続きRecovery Time Objective(RTO)およびRecovery Point Objective(RPO)のビジネス要件を満たしていることを確認します。たとえばOracle RAC環境において、ストレス・テスト中にノードまたはインスタンスの挿入に失敗した場合、この事実からOracle RACのリカバリ可能性が変化したかどうかを評価することができます。
フォールバック計画および手順をテストします。
データベースのパフォーマンスおよび安定性を確認し、パフォーマンスの問題を解決します。
|
関連項目: 『Oracle Database高可用性概要』およびMy Oracle Support(http://support.oracle.com/)のNote 785351.1で参照可能な「The Upgrade Companion」Webサイト。 |
統合テストでは、システムのコンポーネント間で相互作用をテストします。統合テストを計画するときは、次のことを考慮する必要があります。
新しいOracle Database 11gのインスタンスで稼働するPro*C/C++アプリケーションは、新しいソフトウェアで問題がないことを確認するためにテストする必要があります。
Graphical User Interfaceを他のコンポーネントでテストする必要があります。
新しいOracle Database 11gのインスタンスにアプリケーションが直接接続されるかどうかに関係なく、データ型やデータ・ディクショナリのデータの変更(データ・ディクショナリへの行の追加、オブジェクト型の変更)などの新しいOracle Database 11gリリースのわずかな変更でも、フロントエンド・アプリケーションにまで影響することがあります。
2つのコンポーネントがOracle NetまたはOracle Net Servicesを使用して接続されている場合は、ストレス・テストとともにその接続のテストも行う必要があります。
新しいデータベースのパフォーマンス・テストでは、新しいデータベースでの様々なSQL文のパフォーマンスを、現行データベースでの同じ文のパフォーマンスと比較します。アップグレードする前に、現行データベースでのアプリケーションのパフォーマンス・プロファイルを理解する必要があります。特に、アプリケーションがデータベース・サーバーに対して実行するコールを理解する必要があります。
この項では、次のようなパフォーマンス・テストについて説明します。
Oracle Database 11gリリース1(11.1)以上では、新しいデータベース・リプレイ機能を使用して、本番データベースを実際にアップグレードする前に、ユーザーのサイトの本番ワークロード上でデータベースをアップグレードする現実的なテストを実行できるようになりました。この機能は、本番システム上で実際のデータベースのワークロードを取得して、これをテスト・システム上でリプレイします。また、潜在的な問題(エラーの発生やパフォーマンスの相違など)を示す分析とレポート作成も提供されます。さらに、自動データベース診断モニター、自動ワークロード・リポジトリ(AWR)およびアクティビティ・セッション履歴など、定期的なEnterprise Managerパフォーマンスの監視およびレポート作成ツールをすべて使用して、問題に対処します。
|
注意: データベース内のストアド・プロシージャのロジックは変更できますが、アプリケーション・ロジックを実装しているストアドPL/SQLプロシージャでは、アップグレード前と同じインスターフェースを維持する必要があります。アプリケーションのストアド・プロシージャがアップグレードによって影響を受ける場合は、ワークロードをリプレイできない場合があります。このようにデータベース・リプレイ・ツールを使用すると、サーバー内の新しいアプリケーション・ロジックがアップグレード後にも期待どおりに動作するかどうかを確認でき、有効な診断が行えます。 |
|
関連項目: ワークロードの取得およびリプレイの方法については、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。 |
Oracle Database 11gリリース1(11.1)より、SQLパフォーマンス・アナライザを使用して、システムの変更がSQLワークロードに及ぼす影響を予測できるようになりました。SQLパフォーマンス・アナライザでは、アップグレードによって影響を受けたSQL文を識別してパフォーマンスの相違を測定することで、データベースのアップグレードなどの変更による影響を予測できます。分析により、アップグレードによるSQLパフォーマンスに対する全体的な影響を評価し、悪い結果をユーザーが影響を受ける前に回避できます。
|
関連項目: 潜在的なデータベース変更のWhat-if分析にSQLパフォーマンス・アナライザを使用した詳細および例は、『Oracle Database Real Application Testingユーザーズ・ガイド』を参照してください。 |
SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。SQL計画管理は、一定期間におけるSQL文の実行計画を記録および評価する予防的メカニズムであり、効率的であることが確認されている既存の計画で構成されたSQL計画のベースラインを構築します。SQL計画のベースラインは、システムで発生している変更に関係なく、対応するSQL文のパフォーマンスを保持するために使用されます。
新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、通常、SQL文に対して若干の計画変更がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。
SQL計画管理では、SQL計画の情報を取得、選択および展開するためのコンポーネントを提供することで、SQL文の実行計画が急に変更された場合に起こるパフォーマンスの低下を回避できます。新しいオプティマイザ・バージョンをインストールするデータベース・アップグレードでは、SQL文に対して若干の計画変更がある場合がありますが、ほとんどの計画変更ではパフォーマンスは変化しません。ただし、ある一部の計画変更では、パフォーマンスが低下する場合があります。
SQL計画管理を使用すると、オプティマイザによって実行計画が自動的に管理され、既知の計画または検証済の計画のみが使用されます。SQL文に対する新しい計画が検出されても、その計画が現行の計画と同等かそれ以上のパフォーマンスであることがデータベースによって確認されるまでは使用されません。そのため、SQL計画管理を現行(Oracle Database 11gよりも前)の実行計画でシードすると、これらは各文のSQL計画のベースラインになり、これらの計画は、アップグレード後に使用されます。異なる計画を使用する必要があるとOracle Database 11gオプティマイザが判断した場合でも、新しい計画は検証のためにキューに格納され、現行の計画と同等かそれ以上のパフォーマンスを実現できる計画であることが確認されるまでは、使用されません。
SQL管理ベース(SMB)を実行計画にシードまたは移入するには、次の2つの方法があります。
実行計画の自動取得(Oracle Database 11g以上で使用可能)
実行計画または既存のSQL計画ベースラインのバルク・ロード
実行計画またはSQL計画ベースラインのバルク・ロードは、データベースを以前のリリースからOracle Database 11gにアップグレードする場合に特に役立ちます。バルク・ロードされるSQL計画は、自動的にそのまま使用され、SQL計画ベースラインとして既存または新規の計画履歴に追加されます。
アップグレードの一部としてSQL管理ベースをバルク・ロードするには、次の操作を実行します。
特定のSQLチューニング・セット(STS)に対して実行計画を移入する(「SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード」を参照)。
または、
ステージング表からの既存のSQL計画ベースラインを展開する(「ステージング表からの既存のOracle DatabaseのSQL計画ベースラインの展開」を参照)。
SQLチューニング・セット(STS)を使用したSQL管理ベースのバルク・ロード
STSから実行計画を使用してSQL管理ベースをバルク・ロードするには、次の手順を実行します。
Oracle Database 10gリリース2(10.2)で、各SQL文の実行計画を含むSTSを作成します。
STSをステージング表にロードし、ステージング表をダンプ・ファイルにエクスポートします。
ステージング表をダンプ・ファイルからOracle Database 11gにインポートし、STSをアンロードします。
Oracle Enterprise ManagerまたはDBMS_SPM.LOAD_PLANS_FROM_SQLSETを使用して、実行計画をSQL管理ベースにロードします。
ステージング表からの既存のOracle DatabaseのSQL計画ベースラインの展開
次の一連の手順を実行し、すべての重要なSQL問合せをOracle Database 11gのテスト環境でテストおよびチューニングしてから、その正確なSQL実行計画をOracle Database 11gの本番環境に移動します。
Oracle Database 11gのテスト環境で、重要なSQL問合せをテストおよびチューニングするには、次の手順を実行します。
Oracle Database 11gのテスト環境で、すべてのテストとチューニングを完了してから、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計画ベースラインを展開します。
|
関連項目: SQL計画管理の使用の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
ボリューム/ロード・ストレス・テストでは、アップグレードしたデータベース全体を、大きいボリュームとロードでテストします。ボリュームとは、操作されるデータの量を表します。ロードとは、システム上の同時要求のレベルを表します。ボリューム/ロード・ストレス・テストの目的は、様々なボリュームとロードでの本番システムの動作をエミュレートすることです。
ボリューム/ロード・ストレス・テストは非常に重要ですが、一般に見過ごされがちです。ユーザーは、どのようなボリューム/ロード・ストレス・テストも実行しないことが多いようです。そのかわりに、ビジネス・アプリケーションを特に考慮しているわけではないベンチマークが広く利用されています。アプリケーションのベンチマークは、機能、パフォーマンスおよび統合に関する問題点を検証するために使用するものであり、ボリューム/ロード・ストレス・テストのかわりになるものではありません。
ロード・テストには、本番稼働時に発生する可能性のあるロード条件で新しいエラーやパフォーマンス上の問題などがアプリケーションに発生しないことを確認するため、新リリースのデータベースに対するアプリケーション・ロードの実行を含みます。多くの場合、問題は特定のロード条件で明らかになるため、通常、機能テストでは見つかりません。データベース・リプレイ機能は、本番環境のシステム・ワークロードを取得し、テスト・システム上で同一形式でリプレイできるため、このようなロード・テストに最適です。
アップグレードが最終的に成功するかどうかは、適切なバックアップ計画の立案と実行で決まります。
バックアップ計画を展開するには、次のような問題について考慮する必要があります。
業務上、本番データベースの実行不可能状態の許容範囲がどの程度の期間か。
可用性要件を満たすには、どのバックアップ計画が必要か。
サイトから離れた安全な場所にバックアップをアーカイブする必要があるか。
どのくらいの時間でバックアップをリストアできるか(オフサイト記憶域でのバックアップを含む)。
リカバリ手順は正常にテストされているか。
バックアップ計画は、これらの問題のすべてに答え、データベースを正常にバックアップおよびリカバリするための手順を備えている必要があります。
|
関連項目: データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
現行の本番データベースに影響しないテスト環境を作成します。
テスト環境は、選択したアップグレード方法によって異なります。
DBUAを使用する場合または手動アップグレードを実行する場合は、現行の本番データベースのテスト・バージョン(通常はサブセット)を作成してアップグレードをテストします。
エクスポート/インポートを使用する場合は、現行の本番データベースからほんの一部分をテストとしてエクスポート/インポートします。
テスト環境を使用してデータベースのアップグレードを行います。最良のアップグレード・テスト(作成が可能な場合)とは、ダウンサイズしたコピーまたはテスト・データに対してではなく、アップグレードするデータベースの正確なコピーに対して実行することです。なんらかの理由で正確なコピーを実行できない場合は、データの代表的なサブセットを慎重に選択してテスト環境に移動し、そのデータでアップグレードをテストします。
新しいOracle Databaseで使用するOCIとプリコンパイラ・アプリケーションを、必ずアップグレードしてください。それによって、現行の本番データベースをアップグレードする前に、それらのアプリケーションをサンプルのデータベースでテストできます。
現行のデータベースおよび新しいOracle Database 11gリリースへアップグレードされたテスト・データベースに対して、計画したテストを実行します。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかを確認するために、この新しくアップグレードされたテスト・データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションが現行のデータベースの場合と同様に動作するかを最初に確認してください。
