{"id":7969,"date":"2019-11-01T13:10:58","date_gmt":"2019-11-01T13:10:58","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/reminders-for-applying-oracle-cpu-patches\/"},"modified":"2026-11-03T19:29:11","modified_gmt":"2026-11-03T19:29:11","slug":"reminders-for-applying-oracle-cpu-patches","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/de\/blogs\/reminders-for-applying-oracle-cpu-patches\/","title":{"rendered":"Reminders for applying Oracle CPU patches"},"content":{"rendered":"

Introduction<\/strong>
\nThis blog reviews the importance of running an ADOP (Application DBA Online Patching Utility) cycle with fs_clone<\/em> after any changes or technology patches are made to the Weblogic Server (WLS) or Oracle\u00a9 Fusion Middleware (FMW) home directories on your patch file system. The blog explores a problem scenario and explains how to handle related issues easily.<\/p>\n

The ADOP cycle phases<\/strong><\/p>\n

The following image shows the phases of the ADOP cycle:<\/p>\n

\"oracle<\/p>\n

Image Source<\/em><\/a> <\/p>\n

Problem history<\/strong><\/p>\n

After applying Critical Path Update (CPU) patches to an Oracle version R12.2 instance on a patch file system, ADOP completed a full cycle run (prepare, apply, finalize, cutover, and cleanup). After running another ADOP cycle for a different
\nactivity, the instance was cloned to another server.<\/p>\n

However, when applying WLS patches on the new cloned environment, the system encountered a conflict. The patch was pointing to a version mismatch of the WLS.<\/p>\n

Analysis<\/strong><\/p>\n

Research showed that the CPU patches previously applied to WLS and FMW Web Tier and Oracle common home directories were not included in run and patch file system. On further investigation into the ADOP logfiles, we noticed the prepare file
\nsynchronized the file system, however we couldn’t see the changes made to the Oracle\\_home<\/strong> and FMW\\_home<\/strong> directories during the patching cycle.<\/p>\n

Deduction:<\/strong><\/p>\n

From our analysis, we draw the following conclusions:<\/p>\n

1. The file synchronization in the prepare phase is only for the APPL\\_TOP<\/strong>.<\/p>\n

   The log files we reviewed showed propagating file system changes from run
\n   APPL\\_TOP<\/strong> to patch APPL\\_TOP<\/strong>.<\/p>\n

2. After Weblogic patches were applied, `fs_clone<\/em>` was not run before initiating the next ADOP cycle.  Thus, the new patches don’t show up in the successive un even after the second ADOP cycle completes, and it was not available in the cloned instance.<\/p>\n

Recommendation<\/strong><\/p>\n

In the prepare phase, the patch file system is usually synchronized with the run file system by creating a new database edition. This is a default incremental synchronization of files that are changed on the application top.<\/p>\n

To synchronize the applied patches, invoke txkADOPPreparePhaseSynchronize.pl<\/em>
\nto the $APPL\\_TOP<\/strong> of run file system from the last patching cycle or invoke `fs_clone<\/em>`. In this case, we don’t call the actual `fs_clone<\/em>`. Instead, we call FsCloneStage<\/em> and `sCloneApply<\/em> for the $APPL_TOP<\/strong>, which is very unsynchronized.<\/p>\n

The file system synchronization method is selected automatically based on the Configuration Change Detector (`adConfigChangeDetector.pl -detectConfigChanges<\/em>`)<\/p>\n

\nDifferent file synchronization methods include the following options:<\/p>\n

Option 1<\/strong> \u2013 identify patches from the database that were applied in the last ADOP. Merge and apply these silently. This process takes less time because the system applies only the unapplied patches.<\/p>\n

Option 2<\/strong> \u2013 Recreate or reclone the run file system $APPL\\_TOP<\/strong> to
\nthe patch file system $APPL\\_TOP<\/strong>. This is extremely unsynchronized and consumes more resources.<\/p>\n

Option 3<\/strong> \u2013 Use the third-party software of your choice (such as `rsync<\/em>`) to synchronize the file system.<\/p>\n

 Parameters passed with prepare<\/strong><\/p>\n

`Prepare<\/em>` uses the following parameters:<\/p>\n

a) Use the `Skipsyncerror<\/em>` option in the ADOP prepare phase to ignore errors and    warnings as a workaround for synchronization errors and failures, which might happen if the patch application failed in a previous patching cycle. The
\n   default value is NO<\/strong>.<\/p>\n

   syntax:<\/strong> `adop phase=prepare skipsyncerror=yes<\/em>`<\/p>\n

b) Use the `sync_mode<\/em>` option to specify the method to use to sync the patch file system with a run file system. Syntax<\/strong> `adop phase=prepare sync_mode=(delta|patch)<\/em>`<\/p>\n

   sync_mode patch<\/em> \u2013 Reapplies patches which were already applied to run
\n   file system (default mode).
\n   sync_mode delta <\/em>\u2013 Copies all customizations and file changes. This mode
\n   uses the synchronization command from the file delta\\_sync\\_drv.txt<\/strong> and
\n   is a new feature from `AD-TXK delta 8<\/em>`.
\n <\/p>\n

ADOP fs_clone command<\/strong><\/p>\n

 The `fs_clone` command recreates or reclones the entire patch file system including setting all configurations and customizations on the patch file system in the same manner as the run file system. Doing this is as resource intensive as taking a full backup of the run file system and then creating a patch file system.<\/p>\n

`fs_clone<\/em>` has the following useful commands:<\/p>\n