ADOP (Ad online patching utility) in R12.2
Adop(Ad online patching utility) is used in R12.2 to apply the patches online with out any downtimeit is the new utility which to apply patches in online patching mode .It is perl script and call adpatch internally to apply the patch. It is not recommended to apply the patches directly using adpatch in R12.2
For online patching to work Oracle Apps make use of 11g database feature called as “Edition Based Redefinition”, under this feature. On the Applications side, there will be two file systems, one called as patch and other called as run file system. Both are identical to each other and services will be running out of run file system. During patching process, patches are applied to patch file system, which does not require any downtime. For the patch changes to come to effect, patch file system is switched as run file system and vice versa, and services are restarted. In essence, Downtime will be only for the time duration during which services are restarted.
A complete patching cycle is following while applying the patches with adop. It consists of many phases
1.Prepare: This syncs the current patch file system with run file system, to make sure patch file system is up to date compared to run file system and ready for the patches to get applied. This also created a new patch edition in the database. This syncing process is incremental process to be efficient.
$ adop phase=prepare
2.Apply : Patches are applied to patch file system during this phase, we can apply as many patches we want during this phase. Changed code objects are from patch edition of database. Changes to tables are stored in new columns which are only visible from patch edition of the database.
$ adop phase=apply patches=
3.Finalize: This phase involves compiling of invalid objects etc.
$ adop phase=finalize
4.Cutover: This phase configures the patch file system as new run file system and patch edition of the database as new run edition. Restart application services from new run file system of Apps. This is where downtime is required.
$ adop phase=cutover
5.Cleanup: Deletes obsolete code objects and columns from earlier patch edition are removed at database.
$ adop phase=cleanup
Some more things about adop
1)Online Help
To obtain help about the basics of adop operation, enter the command:
adop -help
2) Enabling maintenance mode is not required in R12.2; it’s not applicable for online patching.
3) There are also three special phases, for use when needed.
Special phases:
abort – Abort the current patching cycle.
actualize_all – Create new copies of all code objects in the patch edition.
fs_clone – Copy the run file system to the patch file system.
4) The adop logfiles are located on the non-editioned file system (fs_ne), under:
s_ne_base/EBSapps/log/adop//__/ext_name>/log
For example, if s_ne_base was /u01/apps/R122_EBS/fs_ne, the session ID was 20, and the
was sunxx_test, the path to the adop log files from 1th July 2013 would resemble this:
/u01/apps/R122_EBS/fs_ne/EBSapps/log/adop/20/apply_20130701_112226/sunxx_te
stsys/log
5) You can obtain a brief report for the current patching session by running the command:
$adop -status
This will display information that includes phases completed and the time taken
Adop(Ad online patching utility) is used in R12.2 to apply the patches online with out any downtimeit is the new utility which to apply patches in online patching mode .It is perl script and call adpatch internally to apply the patch. It is not recommended to apply the patches directly using adpatch in R12.2
For online patching to work Oracle Apps make use of 11g database feature called as “Edition Based Redefinition”, under this feature. On the Applications side, there will be two file systems, one called as patch and other called as run file system. Both are identical to each other and services will be running out of run file system. During patching process, patches are applied to patch file system, which does not require any downtime. For the patch changes to come to effect, patch file system is switched as run file system and vice versa, and services are restarted. In essence, Downtime will be only for the time duration during which services are restarted.
A complete patching cycle is following while applying the patches with adop. It consists of many phases
1.Prepare: This syncs the current patch file system with run file system, to make sure patch file system is up to date compared to run file system and ready for the patches to get applied. This also created a new patch edition in the database. This syncing process is incremental process to be efficient.
$ adop phase=prepare
2.Apply : Patches are applied to patch file system during this phase, we can apply as many patches we want during this phase. Changed code objects are from patch edition of database. Changes to tables are stored in new columns which are only visible from patch edition of the database.
$ adop phase=apply patches=
3.Finalize: This phase involves compiling of invalid objects etc.
$ adop phase=finalize
4.Cutover: This phase configures the patch file system as new run file system and patch edition of the database as new run edition. Restart application services from new run file system of Apps. This is where downtime is required.
$ adop phase=cutover
5.Cleanup: Deletes obsolete code objects and columns from earlier patch edition are removed at database.
$ adop phase=cleanup
Some more things about adop
1)Online Help
To obtain help about the basics of adop operation, enter the command:
adop -help
2) Enabling maintenance mode is not required in R12.2; it’s not applicable for online patching.
3) There are also three special phases, for use when needed.
Special phases:
abort – Abort the current patching cycle.
actualize_all – Create new copies of all code objects in the patch edition.
fs_clone – Copy the run file system to the patch file system.
4) The adop logfiles are located on the non-editioned file system (fs_ne), under:
s_ne_base/EBSapps/log/adop//__/ext_name>/log
For example, if s_ne_base was /u01/apps/R122_EBS/fs_ne, the session ID was 20, and the
was sunxx_test, the path to the adop log files from 1th July 2013 would resemble this:
/u01/apps/R122_EBS/fs_ne/EBSapps/log/adop/20/apply_20130701_112226/sunxx_te
stsys/log
5) You can obtain a brief report for the current patching session by running the command:
$adop -status
This will display information that includes phases completed and the time taken
Tags:
Oracle EBS Patching