Online patching is supported by the capability of storing multiple
application editions in the database, and the provision of a dual
application tier file system. At any given point in time, one of these
file systems is designated as run (part of the running system) and the
other as patch (either being patched or awaiting the start of the next
patching cycle).
For applying a patch in R12.2 you need to use adop and run through all below phases in sequence mentioned below.
1) adop phase=prepare
2) adop phase=apply patches=<patch_number1>,<patch_number2> workers=<number_of_worker>
3) adop phase=finalize workers=<number_of_worker> (called automatically)
4) adop phase=cutover workers=<number_of_worker>
5) adop phase=cleanup (called automatically)
OR
Running all phases in single command:
adop phase=prepare,apply,finalize,cutover,cleanup patches=<patch_number1>,<patch_number2>
——————————————————————————————————————–
DESCRIPTION OF EACH PHASE
1) PREPARE PHASE DETAILS
Used to start a new online patching cycle
How to execute:
A) Set the environment by executing (sourcing) the run file system environment file:
$ source <EBS install base>/EBSapps.env run
B) Verify envirionment
You can confirm that the environment is properly set by examining the relevant environment variables:
$ echo $FILE_EDITION
run
$ echo $TWO_TASK
dbSID
C) Download Patches
Download patches to be applied and place then in the $PATCH_TOP
directory of your system. This directory is pre-created by the install
in the non-editioned file system (fs_ne) and should not be changed.
Important: On a multi-node system with non-shared file systems, you
must copy the patch files to each separate $PATCH_TOP directory, so that
the patch files are available from the same location on all nodes.
D) Unzip the patch
$ unzip <patch>.zip
E) Run Prepare Command
Prepare the system for patching by running the following command to start a new patching cycle:
$ adop phase=prepare
What it will do:
• Checks whether to perform a cleanup, which will be needed if the
user failed to invoke cleanup after the cutover phase of a previous
online patching cycle.
• Checks the integrity of the database data dictionary. If any corruption is found, adop exits with an error.
• Checks system configuration on each application tier node. A number of
critical settings are validated to ensure that each application tier
node is correctly registered, configured, and ready for patching.
• Checks for the existence of the “Online Patching In Progress”
(ADZDPATCH) concurrent program. This program prevents certain predefined
concurrent programs from being started, and as such needs to be active
while a patching cycle is in progress (that is, while a database patch
edition exists). If the ADZDPATCH program has not yet been requested to
run, a request is submitted.
Note: ADZDPATCH is cancelled later on when the cutover phase is complete.
• Checks to see if the patch service has been created. adop requires
that a special database service exists for the purpose of connecting to
the patch edition. This service is created automatically, but its
continued existence is validated on each prepare.
It can be checked by the database parameter SERVICE_NAME
SQL> show parameter service_name
NAME TYPE VALUE
------------------------------------ ----------- ---------------
service_names string dba, ebs_patch
Here dba is the SID of our database and ebs_patch is additional service_name which is required by online patching tool.
If you look at tnsnames.ora file in the Application tier $TNS_ADMIN directory you will find below kind of entry:
<SID>_patch=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=<your_database_server_name>)(PORT=<your_database_port>))
(CONNECT_DATA=
(SERVICE_NAME=ebs_patch)
(INSTANCE_NAME=<your_database_SID>)
)
)
During patching phase, adop will use this tns entry to connect to database.
• Invokes the TXK script
$AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize
the patches which have been applied to the run APPL_TOP, but not the
patch APPL_TOP.
• Checks the database for the existence of a patch edition, and creates one if it does not find one.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2) APPLY PHASE DETAILS
In the apply phase, adop applies the specified patches to the system.
Patches are applied to the patch edition of the database and file
system.
How to execute:
Example:
$ adop phase=apply patches=1234,7891 workers=8
Where 1234 and 7891 are the patch numbers
What it will do:
If a post-installation patch step mentions any tasks that need to be
performed explicitly, where they are run from depends on the type of
patching:
• In a normal online patching cycle, the steps should be executed from the patch file system after the apply phase.
• If the patch is being applied in hotpatch mode or downtime mode, the
steps should be executed from the run file system after the apply phase.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3) FINALIZE PHASE DETAILS
The finalize phase will be executed while the application is still
online. It is used to perform any remaining processing that is needed to
ensure the system is ready for the fastest possible cutover.
Used to perform the final patching operations that can
How to execute:
$ adop phase=finalize
What it will do:
• Pre-compute DDL that needs to be run at cutover.
• Compile all invalid objects.
• Validate that the system is ready for cutover.
If finalize_mode=full, compute statistics for key data dictionary tables for improved
performance.
VERY IMPORTANT 1 : Up to this phase, you can run a special phase
called abort, which will undo the changes made so far in the patching
cycle. After cutover is complete, however, you cannot do this.
VERY IMPORTANT 2 : In an online patching cycle, the requisite JAR
files are initially stored in the $APPL_TOP/admin/<SID>/out
directory, and then uploaded into the database during the cutover phase.
Therefore, the out directory must not be deleted at least until cutover
(next phase) is complete.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4) CUTOVER PHASE DETAILS
Used to perform the transition to the patched environment. Shuts down
application tier services, makes the patch edition the new run edition,
and then restarts application tier services. This is the only phase the
involves a brief downtime.
Important: No users should remain on the system during cutover, as
there will be a short downtime period while the application tier
services are restarted. Also, any third-party processes connected to the
old run edition of the database should be shut down, or they will be terminated automatically.
How to execute:
$ adop phase=cutover
What it will do:
• Shut down internal concurrent manager. The adop utility signals the
internal concurrent manager to shut down, but will wait for any existing
concurrent requests to finish before it proceeds with cutover actions.
Note: Cutover will take longer if it has to wait for long-running
concurrent processes to complete. In such a case, you can expect to see
an informational message of the form: [STATEMENT] [END 2013/10/28
23:47:16] Waiting for ICM to go downIf you do not want to wait for
in-progress concurrent requests to finish normally, you can terminate
the internal concurrent manager by executing the adcmctl.sh abort
command from a different shell.
• Shut down application tier services: All application tier services
are brought down. During this period, the system is unavailable to
users.
• Cutover database: Promote patch database edition to become the new run database edition, using adzdpmgr.pl script.
• Cutover file system: Promote patch file system to become the new run
file system, switching the $FILE_EDITION values in the patch and run
enviroments. The current patch APPL_TOP becomes the new run APPL_TOP,
and the current run APPL_TOP becomes the new patch APPL_TOP. Terminate
old database sessions: Terminate any database connections to the old run
edition of the database.
• Start application tier services: Application tier services are
restarted, on the new run edition. The system is now available again to
users
• ADZDPATCH concurrent program is cancelled when the cutover phase is complete.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5) CLEANUP PHASE DETAILS
Important: If you fail to run the cleanup phase explicitly, it will
be run automatically on the next prepare cycle, but this will cause a
delay in starting your next online patching cycle.
This adop phase is used to remove obsolete code and data from old editions.
How to execute:
$ adop phase=cleanup
What it will do:
• Various actions are performed during cleanup, including dropping
(removing) obsolete: Crossedition triggers, Seed data, Editioned code
objects (covered objects), Indexes, Columns, Editions.
Using parameter cleanup_mode:
a) cleanup_mode=quick – Performs minimum cleanup, including removal of obsolete crossedition triggers and seed data.
Use quick cleanup when you need to start the next patching cycle as
soon as possible. For example, if you want to start a new patching cycle
right away, but have not yet run cleanup from the previous patching
cycle, you can use quick cleanup mode to complete the essential cleanup
tasks as fast as possible.
b) cleanup_mode=standard – Does the same as quick mode, and also
drops (removes) obsolete editioned code objects (covered objects).
This is the default mode , so does not need to be specified.
c) cleanup_mode=full – Performs maximum cleanup, which drops all obsolete code and data from earlier editions
Use full cleanup when you want to recover the maximum amount of space
in the database. If you have run a large number of patching cycles, or
applied a very large patch such as a rollup, significant space may be
consumed by obsolete table columns and recovered by running a full
cleanup. A full cleanup should only be performed when there is no
immediate need to start a new patching cycle.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
THERE ARE TWO SPECIAL PHASES:
A) ABORT PHASE DETAILS
Abort PHASE is conditional phase. This phase cannot be specified with any other phase.
If for some reason either the prepare or apply phase failed or gave
problems, you can abort the patching cycle at either of these points by
running a special phase with the Command. The actions taken will be
discarded (rollbacked).
IMPORTANT: This abort command is only available up to (but not
including) the cutover phase. After cutover, the system is running on
the new edition, and abort is no longer possible for that patching
cycle.
How to execute:
The command to perform this operation is:
$ adop phase=abort
What it will do:
• Confirms that there is an in-progress online patching cycle, so the abort call is therefore valid.
• Checks for the existence of a patch edition and drops one if it exists.
• Cancels the ADZDPATCH concurrent program, if it is running.
• Deletes the rows inserted for the pending session ID from the ad_adop_sessions and ad_adop_session_patches tables.
VERY IMPORTANT: After running abort, a full cleanup must be
performed. The cleanup command is: adop phase=cleanup
cleanup_mode=full). This will remove any columns that were added by the
patch but are no longer needed because of the abort. If they are not
removed, they may cause problems in a later patching cycle.
Alternatively, you can run a combined command to abort the patching cycle and perform a full cleanup:
$ adop phase=abort,cleanup cleanup_mode=full
If any attempt was made to apply patches to the patch edition, after
abort you must run the fs_clone phase (adop phase=fs_clone) to recreate
the patch file system.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
B) FS_CLONE PHASE DETAILS
The fs_clone phase is a command (not related to adcfgclone.pl) that
is used to synchronize 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.
How to execute:
The fs_clone phase is run using the following command:
$ adop phase=fs_clone
What it will do:
This phase is useful if the APPL_TOPs have become very unsynchronized
(meaning that there would be a large number of delta patches to apply).
It is a heavyweight process, taking a backup of the entire current
patch APPL_TOP and then cloning the run APPL_TOP to create a new patch
APPL_TOP. As this method requires more time and disk space, it should
only be used when the state of the patch file system is unknown. This
command must be invoked from the run file system, before the next
prepare phase is run.
Note: The patch file system requires at least 25 GB of free disk
space to be available for adop operations, including fs_clone. If there
is insufficient free space, the adop operation will fail.
If an fs_clone operation fails, you can rerun it with the option
force=yes to restart it from the beginning (with the same session ID),
or force=no to restart it from the point where it failed.
——————————————————————————————————————–
IMPORTANT POINTS REGARDING ONLINE PATCHING:
1. adop utility is put under $APPL_TOP_NE/ad/bin. It is a wrapper
script which calls internally the perl script $AD_TOP/bin/adzdoptl.pl
which does actual work of applying the patch.
2. adop will automatically set its environment as required, but it is
the user’s responsibility to set the environment correctly for any
other commands that may be run. Set the run edition environment whenever
executing commands that you intend to affect the run edition.
For example:
$ . <EBS_ROOT>/EBSapps.env run
$ adstrtal.sh
Set the patch edition environment whenever you intend to execute commands that affect the patch edition.
For example:
$ . <EBS_ROOT>/EBSapps.env patch
$ sqlplus apps/apps @my_custom_patch_script.sql
3. All the phases need to be completed and you can’t skip any of
these. For example, if you try to skip prepare phase, you may get error
message like “Apply phase can only be run while in a patching cycle,
i.e. after prepare phase.”
4. After an online patching cycle is started, you should not perform any
configuration changes in the run edition file system. Any that are made
will not be propagated and will therefore be lost after cutover is
complete.
5. You should not attempt to clone an Oracle E-Business Suite system while an online patching cycle is in progress.
6. The prepare, apply, and fs_clone phases all require at least 10GB of
free disk space. All other phases require 1GB of free space. A warning
message will be displayed if less than the needed amount is available.
7. The directories where you extracted the patches applied in a given
patching cycle must be retained, in the same location and with the same
contents, until the next prepare phase completes. This is also a
requirement for patches applied in a hotpatch session.
8. Maintenance Mode is not needed for online patching, and so
Maintenance Mode is not available in Oracle E-Business Suite Release
12.2.
——————————————————————————————————————-
ADOP ON MULTI-NODE
In a multi-node environment, one application tier node will be
designated as the primary node. This is the node where the Admin Server
is located, and will usually also be the node that runs Oracle HTTP
Server. All other application tier nodes are designated as secondary
nodes.
adop commands are invoked by a user on the primary node. Internally,
adop uses Secure Shell (ssh) to automatically execute required patching
actions on all secondary nodes. You must set up passwordless ssh
connectivity from the primary node to all secondary nodes.
If a node unexpectedly becomes inaccessible via ssh, it will be
abandoned by adop, and the appropriate further actions taken. Consider a
scenario where the adop phase=prepare command is run in a system with
ten application tier nodes. The command is successful on nine nodes, but
fails on the tenth. In such a case, adop will identify the services
enabled on nodes 1-9. If they are sufficient for Oracle E-Business Suite
to continue to run normally, adop will mark node 10 as abandoned and
then proceed with its patching actions. If they are not sufficient, adop
will proceed no further.
——————————————————————————————————————–
