重庆思庄Oracle、Redhat认证学习论坛

标题: OPatch 12.2.0.1.5 and 11.2.0.3.14 开始,不再提供ocm响应文件 [打印本页]

作者: 郑全    时间: 2017-6-21 17:37
标题: OPatch 12.2.0.1.5 and 11.2.0.3.14 开始,不再提供ocm响应文件
[size=130%]OPatch: Behavior Changes starting in OPatch 12.2.0.1.5 and 11.2.0.3.14 releases (文档 ID 2161861.1)
转到底部

                               
登录/注册后可看大图



                               
登录/注册后可看大图

In this Document
Purpose
Scope
Details
OCM is no longer packaged with OPatch
Enhanced to handle superset/subset patch more efficiently
The change
New option for "opatch lsinv" / "opatch lsinventory"
SPU Installations
GOAL: Only rollback the current SPU
GOAL: Rollback the entire SPU
non-SPU Installations
GOAL: Only rollback the current release of the superset patch
GOAL: Rollback all releases of the superset patch and subset patch(es)
References

Applies to:   Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Siebel CRM - Version 8.1.1.8 [23012] to 8.1.1.11 [IP2013] [Release V8]
Oracle Enterprise Service Bus - Version 10.1.3.5 to 10.1.3.5
Oracle Business Process Management Suite - Version 11.1.1.7.0 to 11.1.1.7.0 [Release 11gR1]
Oracle Database - Standard Edition - Version 11.2.0.1 and later
Information in this document applies to any platform.
PurposeTo announce a change in behavior for how OPatch addresses superset/subset patching
ScopeThis is applicable to all levels of expertise for OPatch.
The 12.2.0.1.5 release of OPatch is used for all releases 12.1.0.x and later
The 11.2.0.3.14 release of OPatch is used for all releases 11.2.0.1 - 11.2.0.4
DetailsOCM is no longer packaged with OPatchNote:  This enhancement to OPatch exists in 12.2.0.1.5 release and later

In the past, when a "silent" installation was executed, it was necessary to generate a response file and include it in the command line of the OPatch apply.  For example:
# opatchauto apply <UNZIPPED_PATCH_LOCATION>/23273686 -ocmrf <ocm response file>
The option -ocmrf is used to provide OPatch the OCM responses during a silent install.  Since OCM is no longer packaged with OPatch, the -ocmrf is no longer needed on the command line.  The command can now be
# opatchauto apply <UNZIPPED_PATCH_LOCATION>/23273686
The command "emocmrsp" is used to create the response file for the option -ocmrf.  This no longer is needed since the -ocmrf is no longer needed
If -ocmrf is included in the command line, the following ignorable warning will be returned
***You are calling OPatch with -ocmrf option while this OPatch is generic, not being bundled with OCM. The -ocmrf option is being deprecated. Please remove it while calling OPatch.***
Enhanced to handle superset/subset patch more efficientlyNote:  This enhancement to OPatch exists in 12.2.0.1.5 and 11.2.0.3.14 releases and later

The changeIn the past, when OPatch recognized that the patch being installed is a superset of one already installed, it would rollback the subset patch before installing the new patch.
Beginning with these releases of OPatch, when OPatch recognized that the patch being installed is a superset of one already installed, OPatch no longer rolls back the installed patch prior to it installing the superset patch.  Additionally when the superset patch is rolled back, the original patch is reactivated
For example: Install July OJVM PSU (23177536) on top of April OJVM PSU (22674709) which is a subset of July
Prior actions taken by OPatch
  • OPatch reports July OJVM PSU (23177536) as a superset of April OJVM PSU (22674709)
  • OPatch rollsback April OJVM PSU
  • OPatch installs July OJVM PSU
  • Inventory reflects July OJVM PSU installed
  • After rolling back July OJVM PSU, nothing is installed
  • Running the Post De-install (datapatch) the July OJVM PSU is rolled back
Actions taken by OPatch starting with release 12.2.0.1.5 and 11.2.0.3.14
  • OPatch does not report July OJVM PSU (23177536) as a superset of April OJVM PSU (22674709)
  • OPatch does not 1st rollback April OJVM PSU.
  • OPatch installs July OJVM PSU
  • Inventory reflects only July OJVM PSU installed
  • After rolling back July OJVM PSU, Inventory reflects April OJVM PSU installed
  • Running the Post De-install (datapatch) the July OJVM PSU is rolled back and the April OJVM PSU is applied (12.1.x only)
Starting in OPatch 12.2.0.1.7 and 11.2.0.3.15 releases, the following message will be returned
after a subset patch has been inactivated during an apply:
Sub-set patch [22674709] has become inactive due to the application of a super-set patch [23177536].
Please refer to Doc ID 2161861.1 for any possible further required actions.
after a subset patch has been re-activated during a rollback:
Inactive sub-set patch [22674709] has become active due to the rolling back of a super-set patch [23177536].
Please refer to Doc ID 2161861.1 for any possible further required actions.
New option for "opatch lsinv" / "opatch lsinventory"When listing patches associated to an installation, the -inactive option will list all patches that have been superseded and inactivated.  For example:
% opatch lsinv -inactive
...
Inactive patches (1) :

Patch  22674709     : applied on Thu Jul 21 16:21:49 GMT 2016
Unique Patch ID:  20057886
Patch description:  "Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016)"
   Created on 5 Apr 2016, 08:56:18 hrs PST8PDT
   Bugs fixed:
     22674709, 19176885, 22670413, 19623450, 21566993, 19153980, 19855285
     20415564, 21555660, 21047803, 21188537, 22670385, 19699946, 22139226
     19909862, 21811517, 19223010, 21068507, 19895326, 19877336, 22118851
     22118835, 20408829, 21047766, 19231857, 19895362, 19245191, 20408866, 21566944


SPU InstallationsGOAL: Only rollback the current SPUAfter running the OPatch rollback command as documented in the README
  • Run the Post de-install step as documented in the README
GOAL: Rollback the entire SPUIf using Opatch 11.2.0.3.15 or later, when OPatch completes the rollback, it will display any molecules that were re-activated due to the rollback.
  • Each re-activated molecule must also be rolled back until OPatch no longer reports patches being re-activated
    % opatch rollback -id nnnnnnnn
  • If Step 1 re-activated molecule(s), repeat step 1 till all molecules have been removed
  • Run the Post de-install step as defined in the README
Note: If using Opatch 11.2.0.3.14, OPatch will not report the re-activated subset patch.  Run "opatch lsinv" to determine which subset patch(es) were reactivated.
non-SPU InstallationsGOAL: Only rollback the current release of the superset patchFor a ROLLBACK
12.1.0.x and later
Nothing additional to any Post de-Install steps which are documented in the README
Note: datapatch will re-apply the patch which was re-activated due to the rollback of the superset
In the following example scenario:
  • 22674709 Oracle JavaVM Component (Apr2016) is applied
  • 22674709 Oracle JavaVM Component (Apr2016) is rollback before applying Oracle JavaVM Component (Jul2016)
  • 23177536 Oracle JavaVM Component (JUL2016) is applied
  • 23177536 Oracle JavaVM Component (JUL2016) is rolled back
  • 22674709 Oracle JavaVM Component (Apr2016) gets re-activated in the inventory, so datapatch automatically re-applies it
dba_registry_sqlpatch reflects the following
   PATCH_ID FLAGS   ACTION     STATUS   ACTION_TIME                    DESCRIPTION
   -------- ------- ---------- -------- ------------------------------ ----------------------------------------------------------------------
1) 22674709 UJJ     APPLY      SUCCESS  17-JUL-16 08.30.24.639263 PM   Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016)
2) 22674709 UJJ     ROLLBACK   SUCCESS  17-JUL-16 08.40.40.925152 PM   Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016)
3) 23177536 UJJ     APPLY      SUCCESS  17-JUL-16 08.40.40.936933 PM   Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016)
4) 23177536 UJJ     ROLLBACK   SUCCESS  17-JUL-16 09.20.39.324672 PM   Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016)
5) 22674709 UJJ     APPLY      SUCCESS  17-JUL-16 09.20.42.006019 PM   Database PSU 12.1.0.2.160419, Oracle JavaVM Component (Apr2016)
11.2.x
In addition to any Post de-Install steps which are documented in the README for the patch being rolled back, the Post Install step of the patch which was re-activated due to the rollback of the superset should be executed.
Failure to do this may cause components and objects to become INVALID resulting in procedures to fail.  For example, see:
Note 2173700.1 Component JServer JAVA Virtual Machine and object DBMS_JAVA invalid after running Post De-install steps for OJVM PSU
GOAL: Rollback all releases of the superset patch and subset patch(es)
  • After rolling back the superset patch, check inventory to determine if any subset patches were reactivated:
    % opatch lsinv
  • Rollback any patches that were re-activate
    % opatch rollback -id nnnnnnnn
  • Run the Post De-install actions documented in the patch's README
  • Repeat step 1-3 till all subset patches have been rolled back
NOTE: An enhancement to OPatch (Bug 24347794) 24347794 24347794 has been filed to provide the functionality of rolling back all subset patches with one command
ReferencesNOTE:2173700.1 - Component JServer JAVA Virtual Machine and object DBMS_JAVA invalid after running Post De-install steps for OJVM PSU











欢迎光临 重庆思庄Oracle、Redhat认证学习论坛 (http://bbs.cqsztech.com/) Powered by Discuz! X3.2