Friday, March 6, 2015

Patch Conflicts



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  applies all patches under the  directory. OPatch skips duplicate patches and subset patches (patches under that are subsets of patches installed in the Oracle home).

Example  

opatch napply -skip_subset -skip_duplicate

Example   applies patches 1, 2, and 3 that are under the  directory. OPatch skips duplicate patches and subset patches (patches under  that are subsets of patches installed in the Oracle home).

Example  

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  option available. This controls the amount of logging OPatch performs, according to the ODL guidelines.
OPatch supports the following log levels:
  • SEVERE
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST
Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)