Oracle EBS 12.2のAPPSおよびDRインスタンスへのパッチ適用手順

本記事では、Oracle® E-Business Suite®(EBS)R12.2.9におけるディザスタリカバリ(DR)システムのメンテナンスとパッチ適用について解説します。Oracle 12.2 ApplicationsのDRシステムに対して、データベース(DB)パッチおよびアプリケーション(APPS)パッチを適用するための汎用的な手順を紹介します。

はじめに

DRアプリケーションサイトの構築手順は、以前のブログ記事で解説したクローンシステムの作成手順とほぼ同じです。

災害発生時には、XMLファイル内のホスト名をわずかに変更するだけで、バックアップシステムを起動・稼働させることができます。システムを同期状態に保つためには、データベース環境とアプリケーションサーバー環境に対して定期的にパッチを適用する必要があります。

プライマリデータベースサーバーとの間で物理スタンバイデータベースが構成され、両データベースが同期していることを確認してください。その上で、すべてのパッチをDRアプリケーションシステムに適用します。

このプロセスの主な手順は以下の通りです。

1. アーカイブを無効化し、DRを物理スタンバイからスナップショットスタンバイに変換する
2. データベースパッチを適用するためにDRデータベースをシャットダウンする
3. DRデータベースをスナップショットスタンバイモードで起動し、ノードクリーンアップスクリプトを実行する
4. PRODシステムとファイルシステムが一致しない場合、DRアプリケーションのファイルシステムを切り替える
5. システムがダウンタイムモードの間にパッチを適用する
6. アプリケーションDRサーバーへのパッチ適用完了後、DRを物理スタンバイに戻す

このプロセスでは、アプリケーションのスイッチオーバーに対応できるシンプルなシステムを設計・構築します。アプリケーション側で災害が発生した場合に備え、このシステムはすべてのパッチレベルにおいてプライマリサイトと常に同期している必要があります。

1. 物理スタンバイからDRをスナップショットスタンバイに変換する

まず、アーカイブログの転送を無効化し、プライマリDRデータベースをスナップショットスタンバイモードに変換します。

1. プライマリ本番データベースのnode1にoracleユーザーでログインします。

2. 以下のコマンドを実行します。

   $. prodinstance.env
   $  sqlplus / as sysdba
   show parameter log_archive_dest_state_2;
   
   NAME                                 TYPE        VALUE
   ------------------------------------ ----------- --------------------
   log_archive_dest_state_2             string      enable
   alter system set log_archive_dest_state_2='Defer' scope=both sid='*';
   show parameter log_archive_dest_state_2;
   
   NAME                                 TYPE        VALUE
   ------------------------------------ ----------- --------------------
   log_archive_dest_state_2             string      Defer
   

続いて、DRデータベース上のREDOログ適用をキャンセルし、スナップショットスタンバイモードに変換します。

1. DRデータベースのnode1にoracleユーザーでログインします。

2. 以下のコマンドを実行します。

   $. drinstance.env
   $ sqlplus / as sysdba
   alter database recover managed standby database cancel;
   select FLASHBACK_ON, DATABASE_ROLE from v$database;
   
   FLASHBACK_ON       DATABASE_ROLE
   ------------       ----------------
   YES                PHYSICAL STANDBY
   

2. データベースパッチ適用のためDRデータベースをシャットダウンする

両ノードのデータベースをシャットダウンし、データベースパッチを適用します。以下のコマンドでデータベースパッチを適用します。

   $. prodinstance.env
   $ sqlplus / as sysdba
   shut immediate;
   $ cd $PATCH_DIR
   $ opatch apply

上記の手順を使用して、すべてのReal Application Clusters(RAC)システムノードにデータベースパッチを適用します。

3. データベースをスナップショットモードに変換する

DRデータベースをスナップショットスタンバイモードに変換し、ノードのクリーンアップ後にAutoConfigを実行します。

   $. prodinstance.env
   $ sqlplus / as sysdba
   SYS@PRODINSTANCE> startup mount;
   SYS@PRODINSTANCE>alter database convert to snapshot standby;
   SYS@PRODINSTANCE>alter database open;
   SYS@PRODINSTANCE>select DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE from v$database;

   DB_UNIQUE_NAME        OPEN_MODE          DATABASE_ROLE
   --------------        ----------         ----------------
   PRODINSTANCE          READ WRITE         SNAPSHOT STANDBY

次に、パッチ適用に向けてアプリケーションDRシステムを準備します。本番システムでのパッチ適用サイクルが完了すると、カットオーバー後にファイルシステムが切り替わります。その結果、本番とDRのファイルシステムが一致しなくなる可能性があります。以下の手順でこの問題に対応します。これらの手順はDBノードとAPPSノードで実行し、DRデータベースから本番環境への参照を削除します。

ノードのクリーンアップ

以下の手順を実行して、ノードのクリーンアップを準備します。

1. DRデータベースのnode1にoracleユーザーでログインします。

2. 以下のコマンドを実行します。

   $. drinstance.env
   $ sqlplus apps/apps-passwd
   exec fnd_conc_clone.setup_clean;
   truncate table applsys.adop_valid_nodes;
   

すべてのアプリケーション層およびデータベース層でAutoConfigを実行する

データベースノードとアプリケーションノードでadautoconfigを実行します。

DBノード:

1. DRデータベースのnode1にoracleユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/
   $ sh adautocfg.sh
   

2. DR DBのnode2にoracleユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/
   $ sh adautocfg.sh
   

アプリケーションノード(RUNファイルシステム):

1. DRアプリケーションのnode1にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

2. DRアプリケーションのnode2にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

3. DR外部アプリケーションのnode1にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. DR外部アプリケーションのnode2にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

アプリケーションノード(PATCHファイルシステム):

1. DRアプリケーションのnode1にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

2. DRアプリケーションのnode2にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

3. DR外部アプリケーションのnode1にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. DR外部アプリケーションのnode2にapplmgrユーザーでログインし、以下のコマンドを実行します。

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. PRODシステムと一致しない場合、DRアプリのファイルシステムを切り替える

以下の手順は、PRODサーバーとDRサーバー間でRUNファイルシステムとPATCHファイルシステムに差異がある場合にのみ実行する必要があります。両者が一致している場合は、直接パッチ適用に進むことができます。

すべてのDR APPS層ノードで以下の手順を実行します。

1. すべてのDRアプリケーションノード(外部・内部)にログインし、以下のコマンドを実行します。

   $. ./drinstance.env
   $ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -contextfile=<スタンバイ側の現在のRUNコンテキストファイルのフルパス> -patchcontextfile=<スタンバイ側の現在のPATCHファイルシステムのコンテキストファイルのフルパス> -outdir=<出力ディレクトリのフルパス>
   

2. すべてのノードで環境を再設定し、ファイルシステムが切り替わったかどうかを確認します。

これでDRはアプリケーションパッチ適用の準備が整いました。

5. ダウンタイムモードでDRアプリケーションノードにアプリケーションパッチを適用する

まず、DR側ではアプリケーションサービスを停止したままにするため、以下の手順に従ってダウンタイムモードでRUNファイルシステムにパッチを適用します。

1. DRアプリケーションのnode1にログインします。

2. 以下のコマンドを実行します。

   $. drinstance.env
   $ adop phase=apply patches=<patch1, patch2> patchtop=/apps_stage/patch \ apply_mode=downtime options=nodbportion
   

以下の警告メッセージが表示される場合があります。その場合はYで応答して続行してください。

   [WARNING]    adop has detected a configured disaster recovery site.
   [WARNING]    Follow the instructions in the section "Oracle E-Business Suite
   [WARNING]   
   Maintenance with Standby Database" of Business Continuity for
   [WARNING]    Oracle E-Business Suite Release 12.2 depending on the database version used.
   Do you want to continue with the apply phase [Y/N]? Y

次に、標準手順に従ってすべてのFMW層パッチを適用します。

RUNファイルシステムとPATCHファイルシステムを同期するには、以下のコマンドを実行して、RUNファイルシステムに加えられた変更をPATCHファイルシステムにクローンします。

$. drinstance.env
$ adop phase=fs_clone

6. アプリケーションDRパッチ適用完了後、DRを物理スタンバイに戻す

最後に、DRデータベースを物理スタンバイモードに戻し、DRデータベースへのredo applyを有効化して、PRODからDRデータベースへのアーカイブログ転送を再開します。

まず、DRデータベースを物理スタンバイに戻します。

1. DRデータベースのnode1にログインし、以下のコマンドを実行します。

   $. drinstance.env
   $ sqlplus / as sysdba;
   shutdown immediate;
   startup  mount;
   alter database convert to physical standby;
   SELECT open_mode, database_role FROM v$database;
   
   OPEN_MODE            DATABASE_ROLE
   -------------------- ----------------
   MOUNTED              PHYSICAL STANDBY
   
   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
   

2. DRデータベースのnode2にログインし、以下のコマンドでインスタンスを起動します。

   $. drinstance.env
   $ sqlplus / as sysdba;
   startup;
   

次に、以下のコマンドを実行して、プライマリデータベース上のアーカイブログ転送を有効化します。

   1. 本番データベースのnode1にログインします。
   2. 以下のコマンドを実行します:

   $. prodinstance.env
   $ sqlplus / as sysdba;
   show parameter log_archive_dest_state_2;
   alter system set log_archive_dest_state_2='enable' scope=both sid='*';
   alter system set log_archive_dest_state_2='defer' scope=both sid='*';
   alter system set log_archive_dest_state_2='enable' scope=both sid='*';

まとめ

本記事では、PRODのEBS 12.2サイトに適用される更新およびパッチを、ディザスタリカバリ用EBSアプリケーションシステムで管理する方法について解説しました。すべてのアプリケーションシステムのバックアップを保持して、そこからシステムを復元する必要はありません。PRODサイトとDRサイト間でrsyncプロセスを設定し、PRODサイトにデータベースパッチおよびADオンラインパッチング(ADOP)パッチを適用する際に、DRサイトにも同じパッチを適用することをお勧めします。

データサービスの詳細については、こちらをご覧ください。

ご意見やご質問がある場合は、フィードバックタブをご利用ください。また、私たちとの対話を始めることもできます。