Adop is the patch utility introduced in R12.2 to apply the patches online without any downtime.It is perl script and call internally adpatch . Uncompounded to apply patches directly using adpatch in R12.2.
Online patching make use of 11g database feature called as “Edition Based Redefinition” and applications side, there will be two file systems,patch and run(both are identical to each other and services will be running out of run file system). 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 services are restarted.
Adop Phases:
Prepare:This sync current file system with run file system, to make sure patch file is up to date to run file system and ready for patch to be applied. This also create a new patch edition in database.
$ adop phase=prepare
Apply: In this phase, patches are applied to patch file system,many patches can be applied 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=<patch no>
Finalize: This phase involves compiling of invalid objects etc.
$ adop phase=finalize
Cutover: In this patch file system will become as new run file system and patch edition of the database as new run edition. Restart application services from new run file system. This is where basically downtime is required.
$ adop phase=cutover
Cleanup: Deletes obsolete code objects and columns from earlier patch edition are removed at database.
$ adop phase=cleanup
Need to know:
adop -help
Enabling maintenance mode is not required in R12.2.
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.
Log location:
s_ne_base/EBSapps/log/adop//__/ext_name>/log
example, if s_ne_base was /u01/apps/R122/fs_ne, the session ID was 50, and the
was xxx_test, the path to the adop log files from 1th
July 2013 would resemble this:
/u01/apps/R122/fs_ne/EBSapps/log/adop/50/apply_20130701_112226/xxx_test/log
brief report for the current patching session.
display information of completed phases and time taken
Online patching make use of 11g database feature called as “Edition Based Redefinition” and applications side, there will be two file systems,patch and run(both are identical to each other and services will be running out of run file system). 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 services are restarted.
Adop Phases:
Prepare:This sync current file system with run file system, to make sure patch file is up to date to run file system and ready for patch to be applied. This also create a new patch edition in database.
$ adop phase=prepare
Apply: In this phase, patches are applied to patch file system,many patches can be applied 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=<patch no>
Finalize: This phase involves compiling of invalid objects etc.
$ adop phase=finalize
Cutover: In this patch file system will become as new run file system and patch edition of the database as new run edition. Restart application services from new run file system. This is where basically downtime is required.
$ adop phase=cutover
Cleanup: Deletes obsolete code objects and columns from earlier patch edition are removed at database.
$ adop phase=cleanup
Need to know:
adop -help
Enabling maintenance mode is not required in R12.2.
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.
Log location:
s_ne_base/EBSapps/log/adop//__/ext_name>/log
example, if s_ne_base was /u01/apps/R122/fs_ne, the session ID was 50, and the
was xxx_test, the path to the adop log files from 1th
July 2013 would resemble this:
/u01/apps/R122/fs_ne/EBSapps/log/adop/50/apply_20130701_112226/xxx_test/log
brief report for the current patching session.
display information of completed phases and time taken
No comments:
Post a Comment