12.2 patching
12.2 patching
ADOP
stands for Application DBA Online Patching,
introduced in EBS R12.2
To
patch Oracle Applications while a system is available for users during
Patching.
ADOP
uses dual file system (feature introduced in R12.2) to support online patching.
12.2 patching
phases
Prepare ->A virtual
copy (patch edition) of the running application (run edition).
If
needed, it will create a patch edition in the database, as well as
synchronizing patches that have been previously applied to the run file system
with the patch file system. A new
concurrent program called “Online Patching in Progress” (ADZDPATCH) is checked
if already running (confirming that a patching cycle is already in motion), if
not a new one is submitted.
Finalize ->The system
in readiness for the cutover phase.
The
finalize phase will prepare the system to
allow for the fastest cutover possible by doing tasks such as compiling invalid objects and preparing data
definition language (DDL) scripts that will need to be executed at cutover.
Cutover ->To the patch
edition and make it the new run edition.
The
cutover includes shutting down the concurrent managers and the application
services. Once shut down, the database patch edition is made the new
database run edition. The patch file
system is also switched and made the new run edition. It is at this point that the system is
started back up and the users can be let back on the system.
Cleanup ->To cleanup
obsolete definitions or data to recover space.
The
final phase is the cleanup phase which will include the removal of obsolete objects such as old editions of code objects, crossedition triggers, and editions. If you choose to not run the cleanup phase,
it will be run automatically on your next patching cycle when you initiate the
prepare phase.
During
the patching cycle you have the ability to abort at any time as long as you are
in the prepare, apply, or finalize cycle. Once you start the cutover, aborting the
patching cycle is no longer possible. The abort cycle will perform cleanups such
as dropping the patch edition and
canceling the concurrent program ADZDPATCH.
fs_clone
The fs_clone phase
synchronizes the patch file system with the run file system. The fs_clone
phase should only be run when mentioned as part of a specific documented
procedure.
You
must invoke this command from the run file system, before running the next
prepare phase
NOTE
actualize_all – Create new
copies of all code objects in the
patch edition.
Default
PATCH_TOP
$NE_BASE/EBSapps/patch
CLEAN-UP MODES
Use
the following clean-up modes as needed:
cleanup_mode=quick
– Performs minimum cleanup, including removal
of obsolete cross edition triggers and seed data. Use quick cleanup when
you need to start the next patching cycle as soon as possible.
cleanup_mode=standard
– Does the same as quick mode and also drops (removes) obsolete editioned code objects (covered
objects).
cleanup_mode=full
– Performs a maximum cleanup, which drops all obsolete code and data from earlier editions.
After running an
abort, you must perform a full cleanup.
$
adop phase=abort,cleanup cleanup_mode=full
After aborting the
application of patches to the patch edition, you must fs_clone to recreate the
patch file system
$
adop phase=fs_clone
If
an fs_clone operation fails, you can rerun it with the option force=yes to
restart the process from the beginning (with the same session ID) or force=no
to restart the process from the point where it failed.
ADOP HOTPATCH
In
hotpatch mode, adop applies the patch to the run edition while application
services are still running. In this mode, the patch process cannot be aborted.
The
following example initiates a patch in hotpatch mode:
$
adop phase=apply patches=<patch_list> hotpatch=yes
After
using hotpatch, be sure to run both phase=cleanup and phase=fs_clone to
synchronize the run file system with the patch file system. This ensures that
everything is ready for the next patching cycle.
If
you need to reapply a patch, you must use the options=forceapply parameter as
shown in the following example:
$
adop phase=apply patches=<patch list> hotpatch=yes options=forceapply
If
you get a Continue as If It Were Successful error, run the following command to
proceed with the patch:
$
adop phase=apply patches=<patch list> abandon=no restart=yes
flags=autoskip
OTHER
USEFUL ADOP COMMANDS
The
following list contains various helpful adop utility operatons:
To
define workers:
$
adop phase=apply patches=<patch list> workers=5
To
define patchtop:
$
adop phase=apply patches=<patch list> patchtop=<patch location
base>
To
merge patches:
$
adop phase=apply patches=<patch list> merge=yes
To
restart adop from a failed session, run the following commands and then reapply
the patch:
$
adop phase=abort
$
adop phase=cleanup cleanup_mode=full
$
adop phase=fs_clone
To
apply for language patch:
$
adop phase=apply patches=1234456_JA:u123456.drv
To
use non-interactive adop with patchtop and a defined driver:
$
adop phase=apply options=nocopyportion patchtop=$XLA_TOP/patch/115
patches=driver:xla123456.drv
To
skip the failed workers, run the following steps:
Use
adctrl and select option #8 (This will not be visible) to skip the failed jobs.
Restart
adop by using restart=yes parameter.
If
there are many failed jobs, you should restart the patch with the
flags=autoskip option, as shown in the following example:
$
adop restart=no abandon=yes flags=autoskip
This
command restarts the patch and skips any failures that occur. Review the log
file at the end of the patch application to ensure that the appropriate
failures were skipped.
Oracle typically
recommends keeping no more than 25 editions before enacting a manual cleanup
cycle. You can perform a maximum cleanup by using
the cleanup mode full option (e.g. adop phase=cleanup cleanup_mode=full). By keeping database editions to a minimum,
you are able to recover the maximum amount of space while averting any
performance issues with your system.
Edition Based
Redefinition
Oracle
E-Business Suite AD Online Patching (ADOP) only works because the fundamental
mechanism that allows this is using the Oracle
Database feature, Edition Based Redefinition (EBR). The first step in being able to use EBR is to
edition base a schema. The APPS schema
as well as other application schemas are edition enabled out of the box with
EBS 12.2. Additionally, you will also
need to remember to edition enable your custom schema, also known as the custom
top. With EBR, database objects can
be “editioned” (versioned) and the following list shows what can or cannot be
editioned.
✅ FUNCTIONS
✅ LIBRARY
✅ PACKAGE
✅ PACKAGE BODY
✅ PROCEDURE
✅ SQL TRANSLATION PROFILE
✅ SYNONYM
✅ TRIGGER
✅ TYPE
✅ TYPE BODY VIEW
❌ TABLE
❌ INDEX
❌ MATERIALIZED VIEW
As we can see objects
that cannot be editioned are those that take up data storage such as tables,
indexes, and materialized views. These
objects on the other hand will make use of editioning views and crossedition
triggers. The editioned view will only expose the columns and data of
the table that are allowed for the current edition. The table data itself
will be maintained through the use of crossedition triggers. The
editioning view name will include a suffix using the hashtag symbol.
Any custom code must reference the editioning view or preferably the synonym
but never the table name directly. Accessing tables directly could
potentially lead to incorrect data results! The following diagram will
demonstrate the concept of an editioned view on a table in Oracle E-Business
Suite 12.2.
Comments
Post a Comment