Oracle EBSアプリケーション向けディザスタリカバリ(DR)システムの構築手順

本記事では、Oracle® Enterprise Business Suites(EBS)アプリケーション向けディザスタリカバリ(DR)システムの構築と運用方法について解説します。テスト環境に存在する12.2.5システムを活用し、バージョン12.2アプリケーションのDRシステムを構築するための汎用的なプロセスを紹介します。

はじめに

DRアプリケーションサイトの構築手順は、クローンシステムを作成する場合の手順とほぼ同じです。万が一障害が発生した際には、XMLファイル内のホスト名など、いくつかの項目を修正するだけで、システムを稼働させる準備が整います。また、PRODサイトとの同期を維持するためには、rsyncなどの同期スクリプトを実行してDRサイトに変更内容を反映します。さらに、DR用データベースおよびDRサイトのアプリケーションノードにもパッチを適用しておく必要があります。

以下の手順では、フィジカルスタンバイデータベースがすでにプライマリデータベースサーバーと接続され、両者が同期済みであることを前提としています。

DR構成の手順

ここでは、DRシステムを構成するための主なステップを以下の通り解説します。

1. アーカイブ処理を無効化し、DRシステムをフィジカルスタンバイモードからスナップショットスタンバイモードへ変換する。
2. precloneを実行し、プライマリサイトからDRサイトへアプリケーションをコピーする。
3. node1をdualfsで構成する。
4. PRODサイトと一致するよう、追加ノードを登録する。
5. node1の起動・停止を行い、サービスを確認する。
6. アプリケーションDRのセットアップ完了後、DRシステムをフィジカルスタンバイモードに戻す。

1. DRシステムをスナップショットスタンバイモードに設定する

ログ適用を無効化し、DRデータベースをスナップショットスタンバイモードに設定するには、以下のコマンドを実行します。

$ dgmgrl /
$ edit database "TESTDR" set state=apply-off;

次に、フラッシュバックデータベース操作のために、スタンバイデータベースでフラッシュバックロギングを使用するよう設定します。

SQL> alter system set db_recovery_file_dest_size=1000G scope=both;
SQL> alter system set db_recovery_file_dest='+FRA' scope=both;
SQL> alter system set db_flashback_retention_target=1440 scope=both;

$ Shutdown node2 DR DB
$ sqlplus '/as sysdba'

SQL> shutdown immediate;

続いて、DR DBのnode1で以下のコマンドを実行します。

$ sqlplus '/as sysdba'

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database convert to snapshot standby;
SQL> alter database open;
SQL> select name, DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE from v$database;

NAME      DB_UNIQUE_NAME                 OPEN_MODE            DATABASE_ROLE
--------- ------------------------------ -------------------- ----------------
TESTPRD  TESTDR                        READ ONLY WITH APPLY              SNAPSHOT STANDBY

最後に、DR DBのnode2をマウントモードで起動します。

$ sqlplus '/as sysdba'

SQL> startup  mount;

2. precloneの実行とfnd_nodesのクリーンアップ

fnd_nodesをクリーンアップするには、以下のコマンドを実行します。

SQL> exec fnd_conc_clone.setup_clean;
SQL> exec ad_zd_fixer.clear_valid_nodes_info;

DR DBノードに対して、node1 → node2 → node1 の順序でauto-configを実行します。その後、PRODアプリケーション層でprecloneを実行し、RUNファイルシステム(FS)のnode1から、対応するDRアプリケーション層のnode1 FSへアプリケーションファイルをコピーします。

3. dualfsの実行

DRアプリケーション層のnode1上でFSに移動し、以下のコマンドを実行します。

$ perl adcfgclone.pl appsTier dualfs from <APPL_BASE>/<SID>/apps/<RUN-FS>/EBSapps/comn/clone/bin

以下のようなプロンプトが表示された場合は、adcfgcloneが正常に完了しています。自動構成中にエラーが表示されても無視して問題ありません。

Do you want to startup the Application Services for ……..? (y/n) [n] :

4. PRODサイトに合わせてノードを追加する

各アプリケーションノードで、PRODから対応するDRノードへenvファイルをコピーします。必要に応じてディレクトリ名やファイル名を変更したうえで、以下のコマンドを実行してください。

$ scp prodnode1:/home/applmgr/prodprd.env /home/applmgr/proddr.env
$ scp prodnode1:/home/applmgr/prodprd_run.env /home/applmgr/proddr_run.env
$ scp prodnode1:/home/applmgr/prodprd_patch.env /home/applmgr/proddr_patch.env

このコマンドを他のすべてのノードに対しても繰り返し実行します。

その後、envを読み込み、RUN FSとPATCH FSそれぞれに対してauto-configを実行します。想定される実行結果の例は以下の通りです。

Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED

AutoConfig completed successfully.

Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED

AutoConfig completed with errors.

注意: PATCH FSに関するエラーは無視してください。

5. テスト

最初のノードを起動・停止させて、構成をテストします。まず、以下のコマンドでサービスを起動します。

$ . ./proddr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstrtal.sh apps/<passwd>

次に、URLの確認、ログイン、アプリケーションのシャットダウンを以下のコマンドで行います。

$ cd $ADMIN_SCRIPTS_HOME
$ ./adstpall.sh apps/<passwd>

通常のクローン作成プロセスと同様に、PRODインフラに一致するよう追加ノードを登録します。対象のnode1のRUN FSとPATCH FSに対してprecloneを実行し、その後ノードを追加します。まず、RUN FSとPATCH FSの管理サーバーサービスを起動し、以下のようにprecloneを実行します。

$ . ~/testdr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ . ~/testdr_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ cd  <RUN_FS_TOP>/EBSapps/comn/clone/bin
$./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes

node2を構成するには、以下のコマンドを実行します。

$ cd  <RUN_FS_TOP>/EBSapps/comn/clone/bin
$ ./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \
  -contextfile=<RUN-FS-CONTEXT.xml \
  -configoption=addMS \
  -oacore=testdr2.sherwin.com:<port> \
  -oafm=testdr2.sherwin.com:<port> \
  -forms=testdr2.sherwin.com:<port> \
  -formsc4ws=testdr2.sherwin.com:<port>    -- ポート情報はすべてコンテキストファイル内で確認できます。

同様の手順で、PRODシステムに一致するよう他のノードや外部層も追加していきます。

6. DRシステムをフィジカルスタンバイモードに戻す

すべてのノードの追加が完了したら、DRシステム上の全サービスを停止し、DR DBをフィジカルスタンバイモードへ変換して、Data GuardをONに設定します。

DR DB上のサービスを停止し、マウント状態で起動したうえで、フィジカルスタンバイモードへ変換するには、以下のコマンドを実行します。

SQL> alter database convert to physical standby;
DGMGRL> edit database "TESTDR" set state=apply-on;

最後に同期状況を検証します。以下のような結果が表示されれば成功です。

### Monitor to see Transport Lag and Apply Lag to be:
Transport Lag:      0 seconds (computed 0 seconds ago)
Apply Lag:          0 seconds (computed 0 seconds ago)

まとめ

本記事では、検証済みのDRサイトを活用してEBSアプリケーションの障害に備える方法を解説しました。コンテキストファイル内のいくつかのパラメータを更新するだけで、システムをすぐに稼働させることができます。すべてのアプリケーションシステムのバックアップを保持し、そこから復元する必要はありません。PRODサイトとDRサイトの間にrsyncプロセスを設定し、DBパッチやADオンライン・パッチング(ADOP)パッチをPRODサイトに適用すると同時にDRサイトにも適用しておくことをおすすめします。

ご意見やご質問がある場合は、フィードバックタブからお気軽にお寄せください。

Oracle製品に関する豊富な専門知識を持つ私たちが、お客様のOracle投資の価値最大化をサポートいたします。データベースサービスの詳細については、ぜひご相談ください。Rackspaceのディザスタリカバリソリューションに関する詳細情報は、ホワイトペーパーをダウンロードしてご確認いただけます。