Oracle Patch Apply Steps
Oracle Patch Apply Steps
Unzip <Patch_Name.zip>
Chown oracle:oinstall <Patch_Name>
Chmod 777 <Patch_Name>
Cd /opt/oracle/PROD/fs_ne
Cd inst
Ls
See Server Name
cd <Server_Name>
Set Environment Variable
#adop –status [or on] vnc adop -status
Adop phase = prepare
Enter APPS Password
Enter SYSTEM Password
Enter WebLogic/WLSADMIN Password
W8
Adop phase = apply patches = <Patch_Name>
Enter APPS Password
Enter SYSTEM Password
Enter WebLogic/WLSADMIN Password
If system shows failed status then use this $ adop phase = abort
adop phase =finalize
adop phase = cutover
adop phase = cleanup
Give Permissions [chown oracle:oinstall <Patch Number>]
chmod 777 <Patch Name>
3- GOTO Folder cd /opt/oracle/PROD/fs_ne
cd inst
LS(ls)
shows Server Name
now cd <server name>/
. /opt/oracle/PROD/EBSapps.env run
#adop -status
adop phase = prepare
Enter apps password
Enter system password: manager
Enter weblogic password : weblogic 123
adop phase = apply = patches = <patch name>
adop phase =finalize
Copy Patch Folder ---->>>></opt/oracle/PROD/fs_ne/EBSapps/patch>
cd inst
LS(ls)
. /opt/oracle/PROD/EBSapps.env run
#adop -status
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
adop phase=prepare,apply,finalize,cutover,cleanup
patches=<patch_number1>,<patch_number2>
—————————————————————————————————————
—–
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
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
Prepare the system for patching by running the following command to start a new
patching cycle:
$ adop phase=prepare
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
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:
• 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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
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
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
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:
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.
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
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:
$ adop phase=abort
• 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:
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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++
$ adop phase=fs_clone
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.
—————————————————————————————————————
—–
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
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.
Brijesh Gogia
I’m an experienced Oracle Applications DBA with more than a decade of full-time
DBA experience. I have gained a wide knowledge of the Oracle software stack and
have worked on several big projects for multi-national companies. I enjoy working
with the leading-edge technology and have passion for database performance and
stability. Thankfully my work allows me time for researching new technologies (and
to write about them).
You can connect with me on LinkedIn.
Related Posts:
1. R12.2 ONLINE PATCHING (ADOP) PARAMETERS/COMMANDS
2. R12.2 ONLINE PATCHING (ADOP) QUESTIONS
3. ORACLE APPLICATIONS R12.2 LOG FILES
4. EBS R12.2 OS ENVIRONMENT VARIABLES
5. Oracle Applications (EBS) R12.2 Cloning process
6. Importing Java Code Signing Certificate into Oracle EBS R12.1/R12.2
7. Oracle EBS 11i to R12.1.3 Upgrade
8. FND_NO_DATABASE_CONNECTION in Oracle EBS R12
9. Oracle Apps DBA Interview Questions
10.Upgrade R12.1.1 To R12.1.3 (PART 5 in “11i to R12.1.3 upgrade” series)