adop defaults to abandon=no restart=yes if not specified,
To restart from beginning, use restart=no abandon=yes
adop phase=apply patches=11111,11111 abandon=yes (new patch)
To restart a patch you need to use restart=yes abandon=no .
adop phase=apply patches=11111 restart=yes [abandon=no is implied and not required]
eg. adop restart=no abandon=yes phase=apply
If unable to restart, check for these two AD_ADOP_SESSIONS and AD_ADOP_SESSION_PATCHES tables and analyze the o/p:
---------------------------------------------------------------------------------------
column id format 99
column nn format a10
column nt format a6
select adop_session_id id, prepare_status pr, apply_status ap,
finalize_status fi, cutover_status cu, cleanup_status cl, abort_status ab, status st, node_name nn, node_type nt
from ad_adop_sessions
order by adop_session_id desc;
column id format 99
column bn format a12
column pr format 99999999
column afs format a40
column pfs format a40
column cs format a9
column nn format a10
column ed format a28
column drv format a28
column pt format a35
select adop_session_id id, bug_number bn, patchrun_id pr, status st,
node_name nn, cast(end_date as timestamp) ed, driver_file_name drv, patch_top pt
from ad_adop_session_patches
order by end_date desc;
To diagnostic more for the root cause why patch application failed, check for adpatch log for the failed patch 1111.
cd $APPL_TOP_NE/../log/adop/<session id>
If we wants to start from a fresh page and considering the state of these tables, making a manual modification to the AD_ADOP_SESSIONS table just so it would not hold up ADOP execution due to an incomplete hotpatch session.
update ad_adop_sessions set status='C' where adop_session_id=<from above o/p>;
restart adop and retest.
To restart from beginning, use restart=no abandon=yes
adop phase=apply patches=11111,11111 abandon=yes (new patch)
To restart a patch you need to use restart=yes abandon=no .
adop phase=apply patches=11111 restart=yes [abandon=no is implied and not required]
eg. adop restart=no abandon=yes phase=apply
If unable to restart, check for these two AD_ADOP_SESSIONS and AD_ADOP_SESSION_PATCHES tables and analyze the o/p:
---------------------------------------------------------------------------------------
column id format 99
column nn format a10
column nt format a6
select adop_session_id id, prepare_status pr, apply_status ap,
finalize_status fi, cutover_status cu, cleanup_status cl, abort_status ab, status st, node_name nn, node_type nt
from ad_adop_sessions
order by adop_session_id desc;
column id format 99
column bn format a12
column pr format 99999999
column afs format a40
column pfs format a40
column cs format a9
column nn format a10
column ed format a28
column drv format a28
column pt format a35
select adop_session_id id, bug_number bn, patchrun_id pr, status st,
node_name nn, cast(end_date as timestamp) ed, driver_file_name drv, patch_top pt
from ad_adop_session_patches
order by end_date desc;
To diagnostic more for the root cause why patch application failed, check for adpatch log for the failed patch 1111.
cd $APPL_TOP_NE/../log/adop/<session id>
If we wants to start from a fresh page and considering the state of these tables, making a manual modification to the AD_ADOP_SESSIONS table just so it would not hold up ADOP execution due to an incomplete hotpatch session.
update ad_adop_sessions set status='C' where adop_session_id=<from above o/p>;
restart adop and retest.
=================================
Aborting an Online Patching Cycle:
If a patching cycle is failing and the issue cannot be resolved quickly, it is possible to abort the patching cycle and return to normal runtime operation. The patch edition will be dropped. You can abandon a patching cycle (without applying any patches) by running the command:
$ adop phase=abort
Important: This abort command can only be used before successful completion of the cutover phase. After cutover, the system is running on the new edition, and abort is no longer possible for that patching cycle. Aborting a patching cycle will drop the patch edition, but you must then run the cleanup and fs_clone phases before starting a new patching cycle. The cleanup must be a full cleanup.
For example:
$ adop phase=prepare
$ adop phase=apply patches=123456
[Patch application encounters problems and you want to abort]
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone
Optionally, you can combine the abort and cleanup commands as follows:
$ $ adop phase=abort,cleanup cleanup_mode=full
Note: You cannot abort application of a patch applied in hotpatch mode or downtime mode.
ADOP apply phase options ABANDON and RESTART
Restarting a failed worker :
When adop is using parallel processing and an error occurs, the job fails. Review the main adop log file and the adworkxxx.log file to determine the source of the error, resolve the issues and continue. Restart adop using the adctrl command.
Restarting adop :
If you have shut down the workers, or if adop quits while performing processing actions, it saves all the actions completed up to that point in restart files. Investigate and resolve the problem that caused the failure, then restart adop.
restart options,
restart=(yes|no) [default: no]
Use restart=yes to resume the previous failed apply command from where processing terminated. If an apply command fails, check the log files for further information. If the problem can be corrected, you can then restart the apply command where it left off using the restart parameter.
Example - Restart a apply command
adop phase=apply patches=123456 restart=yes
When restarting a failed apply it is important to use the same parameters as the failed command, with only the addition of the restart=yes parameter.
abandon=(yes|no) [default: no]
Use abandon=yes to abandon the previous failed apply command and start a new apply command. Note that any changes made to the system by the failed command will remain in effect. The abandon flag is most useful when applying a replacement patch for the failing patch.
Example - Abandon previous apply command and apply replacement
adop phase=apply patches=223456 abandon=yes
If a patch fails to apply and there is no replacement patch, you may also abort the complete online patching cycle.
You have several options when restarting (or abandoning) application of individual patches, as follows :
• If you want to restart a failed patch from where it left off, you only need to specify restart=yes on the command line:
adop phase=apply patches=1234 restart=yes
• If you want to restart a failed patch from the very beginning, you need to specify abandon=yes on the command line:
adop phase=apply patches=1234 abandon=yes
• If you want to ignore a previously failed patch and apply a different one instead, you need to specify the new patch number and abandon=yes on the command line:
adop phase=apply patches=5678 abandon=yes
================================================================================
ADOP Useful Options 12.2
To restart worker where failed, while applying patch using "adop" in 12.2
wait_on_failed_job=(yes|no) [default: no]
Controls whether adop apply command exits when all workers have
failed. Instead of exiting, you can force adop to wait, and use
the "adctrl" to retry failed jobs.
adop phase=apply patches=123456 wait_on_failed_job=yes
NB: This works only for Worker jobs, Not for objects compilation fails, like forms, pll's.
For these you have to use "flags=autoskip"
adop phase=apply patches=123456 flags=autoskip
skipsyncerror=(yes|no) [default: no]
Specifies whether to ignore errors that may occur during incremental
file system synchronization. This might happen if you applied
a patch in the previous patching cycle that had errors but decided
to continue with the cutover. When the patch is synchronized on
the next patching cycle, the apply errors may occur again, but
can be ignored.
Example:
adop phase=prepare skipsyncerror=yes
Aborting an online patching cycle:
If an online patching cycle encounters problems that cannot be
fixed immediately you can abort the patching cycle and return
to normal runtime operation.
Example - Aborting a failed online patching cycle:
adop phase=prepare
adop phase=apply patches=123456
### serious unfixable error reported
adop phase=abort
adop phase=cleanup cleanup_mode=full
adop phase=fs_clone
The abort command drops the database patch edition and
returns the system to normal runtime state. Immediately
following abort, you must also run a full cleanup and
fs_clone operation to fully remove effects of the failed
online patching cycle.
adop cutover hang
If an adop cutover hangs or a server has crash or reboot issues in the middle of the adop cutover phase, execute the following steps to fix the issue and then proceed with the patch process.
SOLUTION
Make sure no services or processes are running from the PATCH file system.
Ensure that the Weblogic Admin Server and Node Manager are running on the run file system. Execute the following commands to check the status:
$ adadminsrvctl.sh status
$ adnodemgrctl.sh status
Execute the following commands:
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone force=yes
Run an empty adop cycle to make sure there is no issue in the adop cutover by executing the following command:
$adop phase=prepare, finalize, cutover, cleanup cleanup_mode=full
Start a fresh adop prepare and apply patches.
After the apply step, complete the rest of the adop phases including finalize, cutover, and cleanup.
Trying to resume a failed cutover session giving Invalid Credentials in Oracle Apps R12.2
If you attempt to resume a failed session after cutover exits with cutover_status=3, I receive an 'Invalid Credentials' error.
To check the status you can use the query as earlier posted.
This will be because the database patch edition has already been promoted to be the new run edition. To resume and complete cutover successfully, run the command:
$ adop phase=cutover action=nodb
http://soban-dba.blogspot.com/2017/04/adop-options-availble-in-r122.html
No comments:
Post a Comment