EBS R12.2でOracle CPUパッチ適用後はfs_cloneを忘れずに！ADOPサイクルの落とし穴と対処法

E-Business Suite R12.2環境において、パッチ・ファイルシステム上のWebLogic Server（WLS）やOracle® Fusion Middleware（FMW）ホームディレクトリへ変更やテクノロジーパッチを適用した後には、fs_cloneを伴うADOP（Application DBA Online Patching Utility）サイクルを必ず実行することが重要です。本記事では、実際に発生したトラブルのシナリオを通じて、その理由と簡単な対処方法を詳しく解説します。

ADOPサイクルの各フェーズ

まず、ADOPサイクルのフェーズ構成を以下の図で確認しておきましょう。

画像出典：https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm

問題の経緯

Oracle E-Business Suite R12.2インスタンスのパッチ・ファイルシステムに対してCritical Patch Update（CPU）パッチを適用し、ADOPによるフルサイクル（prepare、apply、finalize、cutover、cleanup）が完了しました。その後、別の作業のために再度ADOPサイクルを実行し、そのインスタンスを別サーバーへクローンしました。

ところが、新しいクローン環境にWLSパッチを適用しようとしたところ、コンフリクト（競合）が発生しました。パッチが想定するWLSのバージョンと実環境のバージョンが一致しないという問題です。

分析

調査の結果、以前にWLSおよびFMW Web Tier、Oracle Commonホームディレクトリへ適用したCPUパッチが、runファイルシステムとpatchファイルシステムのどちらにも反映されていないことが判明しました。さらにADOPのログファイルを精査すると、prepareフェーズではファイルシステムの同期自体は行われていたものの、パッチ適用サイクル中にOracle_homeおよびFMW_homeディレクトリへ加えられた変更内容が同期されていませんでした。

考察

以上の分析から、次のような結論が導き出されました。

1. prepareフェーズでのファイル同期は、APPL_TOPのみが対象です。
   確認したログには、run側APPL_TOPからpatch側APPL_TOPへのファイルシステム変更の反映のみが記録されていました。

2. WebLogicパッチ適用後、次のADOPサイクルを開始する前にfs_cloneが実行されていなかったため、2回目のADOPサイクル完了後も新規パッチがrun環境に反映されず、その結果、クローン先インスタンスにもパッチが存在しない状態となっていました。

推奨事項

通常、prepareフェーズでは新しいデータベースエディションを作成することで、runファイルシステムとpatchファイルシステムが同期されます。これはアプリケーショントップ配下で変更されたファイルに対する、デフォルトの増分同期処理です。

適用済みパッチを確実に同期するには、前回のパッチングサイクルでの変更内容をrunファイルシステムの$APPL_TOPへ反映するtxkADOPPreparePhaseSynchronize.plを呼び出すか、fs_cloneを実行します。なお、差分が非常に大きいケースでは、実際のfs_cloneの代わりに、$APPL_TOPに対してFsCloneStageとFsCloneApplyが呼び出されます。

どのファイル同期方式を採用するかは、Configuration Change Detector（adConfigChangeDetector.pl -detectConfigChanges）によって自動的に判定されます。

ファイル同期方式には、主に以下の選択肢があります。

オプション1 – 前回のADOPでデータベースに記録された適用済みパッチを特定し、それらをマージしてサイレントに再適用します。未適用のパッチのみが処理されるため、所要時間は比較的短くて済みます。

オプション2 – runファイルシステムの$APPL_TOPを再作成（再クローン）して、patchファイルシステムの$APPL_TOPへ反映します。差分が極めて大きい場合に選択される方式で、多くのリソースを消費します。

オプション3 – rsyncなど、任意のサードパーティ製ツールを使ってファイルシステムを同期します。

prepareフェーズで指定できるパラメータ

prepareフェーズでは、以下のパラメータを活用できます。

a) skipsyncerror – 同期時のエラーや警告を無視するオプションです。前回のパッチングサイクルでパッチ適用に失敗していた場合などに起こりうる同期エラー・失敗への回避策として利用できます。デフォルト値はNOです。

構文：adop phase=prepare skipsyncerror=yes

b) sync_mode – runファイルシステムとpatchファイルシステムを同期する方法を指定します。

構文：adop phase=prepare sync_mode=(delta|patch)

• sync_mode=patch – runファイルシステムにすでに適用済みのパッチを再適用します（デフォルトモード）。
• sync_mode=delta – カスタマイズやファイル変更をすべてコピーします。ファイルdelta_sync_drv.txtに定義された同期コマンドを使用する方式で、AD-TXK Delta 8以降で導入された新機能です。

ADOPのfs_cloneコマンド

fs_cloneコマンドは、patchファイルシステム全体を再作成（再クローン）し、runファイルシステムと同じ構成およびカスタマイズ内容を設定します。この処理は、runファイルシステムの完全バックアップを取得してからpatchファイルシステムを作成するのと同等のリソースを必要とする点に留意してください。

fs_cloneで役立つオプションは以下の通りです。

• adop phase=fs_clone force=yes – 失敗したクローン処理を最初からやり直します（デフォルト＝NO）。

• adop phase=fs_clone s_fs_backup_count=1 – runファイルシステムからpatchファイルシステムを再作成する前に保持するバックアップの数を指定します（デフォルト＝0、バックアップなし）。

重要なポイント

prepareフェーズは毎回のパッチングサイクルの冒頭で実行されますが、opatchやSmart Updateユーティリティで適用されるテクノロジースタックのパッチは、prepare段階では同期されません。

また、prepareフェーズでは以下のような手動で加えた変更も同期対象外となります。

• ユーザー定義JSPのコンパイル
• サードパーティライブラリのコピー
• ユーザー定義コンカレントプログラムのコピーとコンパイル
• ユーザー定義フォームのコピーと生成

これらのカスタムのパッチ適用作業は、prepareフェーズ用のカスタム同期ドライバーであるadop_sync.drvにあらかじめ追加しておく必要があります。

adop_sync.drvには、次の2種類のコマンドカテゴリが存在します。

• 一度だけ実行するコマンド
• ファイルシステム同期のたびに実行するコマンド

prepareフェーズでカスタマイズやファイル変更をコピーするには、次のコマンドを使用します。

adop phase=prepare sync_mode=(delta|patch)

さらに、パッチ適用が途中で中止された場合や、メンテナンスパッチ、Release Update Pack（RUP）パッチを適用した場合には、最後に必ずfs_cloneを実行し、runファイルシステムの完全な複製としてpatchファイルシステムを再作成しなければなりません。

まとめ

E-Business Suite Release 12.2のWebLogic ServerやFusion Middlewareコンポーネントに何らかの変更を加えた際は、データベース管理者がfs_cloneを実行し、runファイルシステム側のWLSやFMWに対して行った最新の変更がすべてpatchファイルシステムへ反映されていることを保証することが不可欠です。

ご質問やフィードバックがある場合は、フィードバックタブをご利用ください。データベースサービスに関する詳細情報も併せてご参照ください。