Patch Conflicts
All patches may not be
compatible with one another. For example, if you apply a patch, all the bugs
the patch fixes could reappear after you apply another patch. This is called a
conflict situation. OPatch detects such situations and raises an error when it
detects a conflict.
Types of Conflicts
OPatch can detect the following
types of conflicts.
Superset
If all the bugs fixed by a patch
in the system are also fixed by the patch to be applied, this patch (the patch
to be applied) is considered a superset of the patch already applied. If a bug
superset condition is detected, it is not considered an error situation. All
the subset patches are removed from the system and the new patch is applied.
Example
Consider the following scenario:
- Patch A, installed in the Oracle home,
fixed bugs 1, 2, and 3.
- Patch B, installed in the Oracle home,
fixed bugs 10, 11, and 12.
- Patch C, to be installed, fixes bugs 1,
2, 3, and 4.
Patch C is considered a superset
of Patch A.
Using the
-no_bug_superset Flag
If you want OPatch to error out
if the current patch bugs-to-fix is a superset or the same as an installed
patch bugs-fixed in the Oracle home directory, you can use the -no_bug_superset flag:
$ OPatch/opatch apply
-no_bug_superset
The following example output
shows the message you would see when you use the -no_bug_superset flag:
Oracle interim Patch Installer version 11.2.0.0.1Copyright (c) 2015, Oracle Corporation. All rights reserved.Oracle Home :
/home/oracle_TEST/product/11.1.0/db_1Central Inventory : /home/OUIHome_Opatchfrom :
/home/oracle_TEST/product/11.2.0/db_1/oraInst.locOPatch version :
11.1.0.6.6OUI version :
11.1.0.6.6OUI location :
/home/oracle_TEST/product/11.1.0/db_1/ouiLog file location : /home/oracle_TEST/product/11.1.0/db_1/cfgtoollogs/opatch/opatch-2015_Jan_25_14-03-33-IST_Wed.logApplySession applying interim patch '111000' to OH '/home/oracle_TEST/product/11.1.0/db_1'Apply Session failed: ApplySession failed to prepare the system.
Interim patch 111000 is a superset of
the patch(es) [ 111000 ] in OH /home/oracle_TEST/product/11.1.0/db_1System intact, OPatch will not attempt to restore the system OPatch
failed with error code 73
Subset
Patches to be applied can be
subsets of other patches installed in the Oracle home.
Example
Consider the following scenario:
- Patch A, installed in the Oracle home,
fixed bugs 1, 2, and 3.
- Patch B, installed in the Oracle home,
fixed bugs 10, 11, and 12.
- Patch D, to be installed, fixes bugs 1
and 2.
Patch D is a subset of Patch A.
Using the skip_subset
Option
When you want to skip patches
formerly applied in the Oracle home that are now subsets of other patches you
want to apply now, you can use theskip_subset option
of napply.
For example, if you used napply yesterday
for patch A that fixed bugs 1 and 2, then you use napply today
with theskip_subset option
for patch B that fixes bug 1 and patch C that fixes bugs 1, 2, and 3, then
subset patch A is skipped, and patch C then becomes a superset of patch A.
Example 7-1 applies
all patches under the
Example 7-1
opatch napply -skip_subset -skip_duplicate
Example 7-2 applies
patches 1, 2, and 3 that are under the
Example 7-2
opatch napply -id 1,2,3 -skip_subset
-skip_duplicate
See the description for the skip_subset option
in Table 7-3 for
more information.
Duplicate
A duplicate patch fixes the same
set of bugs fixed by another patch. For example, if you applied Patch A that
fixed bugs 1, 2 and 3, and now apply Patch B that also fixes bugs 1, 2 and 3,
then Patch B is a duplicate of Patch A. A patch is always a duplicate of
itself.
Using the skip_duplicate
Option
If you specify this option,
OPatch removes duplicate patches from the list of patches to be applied. For
example, if you used napply yesterday
for Patch A discussed above, then use napply today
with the -skip_duplicate option
for Patch A and other patches, duplicate Patch A is skipped.
Bug Conflict
A bug conflict occurs if a set
of bugs to be fixed by the current interim patch intersects with some bugs
already fixed by one or more previously installed interim patches. You must
remove the bug conflict before you proceed with the patching by using the apply command
with the -force flag,
which rolls back the conflicting patches before applying the new one.
Example
Consider the following scenario:
- Patch A, installed in the Oracle home,
fixed bugs 1, 2, and 3.
- Patch B, installed in the Oracle home,
fixed bugs 10, 11, and 12.
- Patch E, to be installed, fixes bugs 3
and 4.
Patch E conflicts with Patch A.
File
Conflict
A file conflict occurs if a set
of files to be patched by the current interim patch includes files already
patched by one or more previously installed interim patches, and it is not a
bug superset.
Example
Consider the following scenario:
- Patch A, installed in the Oracle home,
fixed bugs 1, 2, and 3, which modified files a, b, and c.
- Patch F, to be installed, fixes bugs 1,
2, 3 and 4, and modifies files a, d, and f.
Patch F conflicts with Patch A.
Patch Conflict Behavior for Apply
and Napply
The expected behavior for the Apply
and Napply commands is listed in Table 7-23.
Table 7-23 Expected
Behavior for Apply and Napply Commands
|
Command
|
Superset
|
Subset
|
Duplicate
|
File
Conflict or Bug Conflict Patch
|
|
Apply
|
OPatch performs an automatic
rollback, then an apply.
|
After the merge request,
OPatch performs an automatic rollback, then performs an apply.
|
OPatch performs an automatic
rollback, then performs a reapply.
|
OPatch reports the conflict.
After the merge request, OPatch performs an automatic rollback, then an apply.
|
|
Napply
|
OPatch performs an automatic
rollback, then an apply.
|
OPatch reports the subset and
skips the subset patch. It then continues and applies the other patches.
|
OPatch performs an automatic
rollback, then a reapply.
|
OPatch reports the conflict,
then asks you to run again without applying a bug conflict patch.
You can use the -force option
to instruct OPatch to automatically roll back the conflicting patch, then
apply the new patch.
|
Patch Conflict Detection and
Resolution
OPatch detects and reports any
conflicts encountered when applying an Interim patch with a previously applied
patch. The patch application fails in case of conflicts. You can use the -force option
of OPatch to override this failure. If you use this option, the installer first
rolls back any conflicting patches and then proceeds with the installation of
the desired interim patch.
You may encounter a bug conflict
and might want to remove the conflicting patch. This process is known as patch
rollback. During patch installation, OPatch saves copies of all the files the
new patch replaced before the new versions of these files are loaded and stores
them in$ORACLE_HOME/.patch_storage.
These saved files are called Rollback files and are the key to making patch
rollback possible. When you roll back a patch, these Rollback files are
restored to the system. You should only override the default behavior by using
the -force flag
if you completely understand the patch Rollback process. To roll back a patch,
execute the following command:
$ OPatch/opatch rollback
-id
Problem Resolution
The following sections provide
information and instructions on the following tasks to resolve problems:
- Using
logs and traces
- Recovering
from a failed patching session
- Resolving
OPatch application errors
Logging and Tracing
Logging and tracing is a common
aid for debugging. OPatch maintains logs for all Apply, Rollback, and
Lsinventory operations. Each time you execute OPatch, a new log file is
created. The log files are located in the /cfgtoollogs/opatch directory.
Each log file is tagged with the timestamp of the operation.
Log files are
named as opatch__ .
For example, if a log file is
created on May 17th, 2015 at 11.55 PM, it will be named as follows:
opatch_05-17-2015_23-55-00.log
Note:
You can set OPatch to debug mode
by setting the environment variable OPATCH_DEBUG to TRUE.
Command Index
OPatch also maintains an index
of the commands executed with OPatch and the log files associated with it in
the history.txt file
located in the/cfgtoollogs/opatch directory.
An example of the history.txt file
is as follows:
Date & Time : Tue Dec
26 23:00:55 PDT 2015
Oracle Home :
/private/oracle/product/11.2.0/db_1/
OPatch Ver. : 11.2.0.0.0
Current Dir :
/scratch/oui/OPatch
Command : lsinventory
Log File :
/private/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch-2015_Dec_26_23-00-55-PDT_Tue.log
Levels of Logging
OPatch follows the Oracle
Diagnostic Logging (ODL) guidelines. You can set the log level by using the -logLevel
OPatch supports the following
log levels:
- SEVERE
- WARNING
- INFO
- CONFIG
- FINE
- FINER
- FINEST
No comments:
Post a Comment