Oracle E-Business Suite R12.2 ADOP (AD Online Patching) – Behind the Scenes

Start Here

Get in touch with a
TriCore Solutions specialist

Blog | May 20, 2014

Oracle E-Business Suite R12.2 ADOP (AD Online Patching) – Behind the Scenes


The inception of unified drivers was a valuable addition to an E-Business Suite patching technology. It provided some relief for the apps DBA community or any Oracle EBS managed services practice as patching was not only easier but comparatively less time consuming with unified drivers.



Introduction:

Many of us have been managing Oracle E-Business environments since the time when there was only a Oracle_EBS_suiteconventional way of patching. There were mainly three type of drivers (copy ‘c’, database ‘d’ and generate ‘g’) available in a patch for any product group. Performing a point release or a version upgrade or a major release would involve numerous patches to be applied on a system.


For a complex environment, or for those which were setup architecturally over multi-nodes and were also multilingual in nature, patching required scrupulous and diligent execution of these patches as the risk of missing a driver or sequence was possible in a multi-faceted setup.

The inception of unified drivers was a valuable addition to an E-Business Suite patching technology. It provided some relief for the apps DBA community or any Oracle EBS managed services practice as patching was not only easier but comparatively less time consuming with unified drivers.

There are many other standards which were or are currently practiced as complementary to unified drivers to ensure patching projects with less downtime and more effective and efficient execution without much intervention. However, what we aim to explore here is the big advancement in the underlying technology used for patching in the E-Business suite. In Oracle E-Business suite R12.2.0 all patching operations are online now and this has given the ability to predict patching downtime in MINUTES.

Online patching uses the latest feature of the Oracle database 11gR2 which is called “Edition Based Redefinition” and also uses multiple file systems on the application side. During online patching, business application users continue using the Oracle application and simultaneously a patch or a sequence of patches can be applied to another edition of the same database and application. Another edition here means another exact copy of database and application. And once the patching is complete the users are switched over to a patched file system/database in cutover phase by just bouncing middle tier services.

A fresh R12.2.0 is installed with three file Systems:
FS1 – Production file system that is used by application users when system is being patched.

FS2 – Exact copy of production used by the patching tool. This copy is patched by the patching tool. It gets synchronised with FS1 by the patching tool before it gets updated by a patch. When patching is complete, the patching tool swaps the FS1 and FS2 file systems. FS2 file system becomes FS1 and FS1 is switched to FS2. This way, FS2 is again ready to be used for any future patching tasks.

FS-NE – This is a non-edition file system which stores data that is stored in a file system like data import/export files, report out and log files.

R12.2.0 uses 11gR2 database and its feature Edition-Based Redefinition (EBR) for online patching.
Using EBR you can still patch or upgrade a database while it is being used and thereby minimize downtime. Edition based redefinition provides an isolation mechanism that allows pre and post patch data to co-exist. In edition based redefinition one database has three editions of the database.

Run Edition: This is the edition which is being used by the application users when patches are being applied to the production environment. No changes are applied to this edition at all.

Patch Edition: This is the edition which is used by the patching application. The Patch edition is a runtime edition which gets created when a patch starts and gets removed when patching is complete or during a cut over cycle.

Old Edition: This edition keeps copies of the pre-patched data. You can keep many backup copies in this edition that can be cleaned in the clean-up cycle or in any future clean-up cycle of the online patching tool. When a patch edition is promoted to production, the patching tool performs the following steps during its cutover cycle:

(a) Creates a copy of the run edition into an old edition as a backup.
(b) Replaces run edition with a patch edition. The Patch edition is now a run edition.


ADPATCH utility is no longer used in R12.2.0 and is being replaced by ADOP – AD Online Patching. There are five phases or life cycles of ADOP which are:
a) PREPARE
b) APPLY
c) FINALIZE
d) CUTOVER
e) CLEANUP


We will be elaborating more on this topic in a future blog. ADOP technology is rapidly gaining prominence in the online patching arena.


About TriCore Solutions
TriCore Solutions, the application management experts, provides a full suite of scalable and reliable managed application, cloud, infrastructure hosting, and consulting services to enterprise organizations. The company delivers its services and the TriCore Trusted Promise to more than 250 companies worldwide to reduce costs, raise service levels, improve customer experience, increase business agility, and accelerate innovation, unlocking the business value from their IT investments. TriCore Solutions is headquartered in Boston, MA, with offices in Gurgaon, Hyderabad and Philippines.