Oracle 11gR2数据库打补丁操作指导手册

说明：本文为Oracle 11gR2数据库打补丁操作指导手册
版本：Oracle 11gR2版本说明：11.2.0.4.X → 此处的“X”为补丁编号，打补丁后这个编号会变为补丁号
注意：从11g开始每个小版本(11.2.0.N.X中的N)是需要通过升级才能上去的，这个和之前的10g/9i有所不同
温馨提示：如果您发现本文哪里写的有问题或者有更好的写法请留言或私信我进行修改优化

 

前言

为满足Oracle数据库用户对安全的需求，该方案可以更加方便的帮助并指引用户完成Oracle打补丁工作。

 

补丁简述

※ Oracle数据库补丁是oracle官方定期发布的一种用来解决相应平台和版本下的一些BUG和安全漏洞的文件，这种补丁并不会大范围的改变oracle数据库架构，只是小范围的修补，因此又叫补丁包。

※ 打补丁会使oracle数据库更加安全和稳定。但也会对运行环境造成一定的影响，所以打补丁前要针对具体环境进行评估再决定是否打补丁。

 

该文档相关实验数据环境：

1. 数据库版本: oracle 11.2.0.3.0 RAC
2. 操作系统：Linux Centos 6.4

 

该文档适用架构范围

1. Oracle 单实例环境
2. Oracle RAC环境
3. Oracle ASM+单实例环境

 

该文档适用操作系统范围

1. AIX
2. Linux

 

名词解释

1. Opatch是一个基于Java的工具，它可以进行补丁的应用和临时补丁的回滚
2. GI PSU适用于集群环境的补丁包（从11.2.0.2开始发行）（补丁含量较多）
3. PSU季度补丁集，包含了当季以及之前的重要BUG和安全补丁（补丁含量中等）
4. CPU安全补丁集，只包含安全补丁（补丁含量较少）
5. Bundle Patch (Windows 32bit / 64bit) 适由于Windows x86系列
6. Bundle Patch (Windows Itanium) 适由于Windows Itanium系列

 

补丁说明

补丁类型	适用对象
PSU	Database
GI PSU	Grid+Database
SPU(CPU)	Database
OJVM	Database

 

可能涉及系统用户

1. Oracle
2. Grid

 

注意事项：

• 打补丁可能会关闭数据库，所以对于不能停库的用户需要酌情使用
• 打补丁前务必对数据库用RMAN和expdp进行双重全备，以防打补丁失败时对数据的恢复需要。

   温馨提示：

• RMAN全备内容包括：参数文件+控制文件+归档+数据文件
• 备份前建议重启一遍数据库，以提前发现一些数据库异常，以防备份无效

• 打补丁前对于RAC环境，还需要对集群注册表OCR用ocrconfig进行物理备份
• 打补丁前需要备份Oracle软件，以备打补丁失败时对软件的恢复需要

1. 停止所有Oralce服务——实例、监听、EM、ASM、CRS等
2. 备份数据库管理系统软件目录下所有文件包括Database和Grid软件，一般情况下是“/u01”目录

     特别提示：注意保留原目录下文件权限和属性，可使用cp -ar xxx 或 tar -cvPpf xxx等

• 打补丁需要确保有一定额外的本地数据库管理系统软件目录空间和存放数据库文件的磁盘空间，这些额外的空间会在打补丁时存储一些信息，后期有可能会释放，但是打补丁过程中是必不可少的。为了避免打补丁失败或造成操作系统无法启动等问题，请预留足够大的空余空间，具体大小依实际情况有所不同。

本次实验的磁盘使用空间大小如下（实际情况会因环境不同会有所差异，建议留够充足空间）

1. 每个节点的本地磁盘空间消耗约100G
2. ASM存储磁盘空间消耗约10G

• 打补丁是一个耗时的过程，在这期间不要中断操作，以免造成打补丁操作失败。

本次实验的用时清单如下（实际情况会因环境不同会有所差异，建议留够充足时间）

① 两节点打补丁一共耗时约3*2*2=12小时

上述时间是串行用时，各节点打补丁互不影响可并行来节约时间，但升级数据字典只能在一个节点上执行，且务必等两边的软件都打好补丁后再升级数据库数据内容，如：数据字典等

② 升级数据字典耗时约1小时

• 打补丁的结果只能通过opatch和一些dba视图可见，v$version和PL/SQL不可见

 

具体操作步骤

由于Oracle有多种针对不同需求的补丁，而且每种补丁会因操作系统、数据库版本等环境的不同而变化，因此每种补丁的实施步骤请根据压缩包内的“README.html”官方文档进行操作即可。

 

回滚

• 补丁的回滚

如果打补丁失败了，可以参考“README.html”官方文档进行操作即可。如果回滚不了可以采用软件文件的回滚和数据库数据的回滚

• 数据库管理系统软件的回滚

如果在给数据库管理系统软件打补丁的过程中失败了，可以直接用之前备份的数据库管理系统软件的文件替换失败的软件目录下的所有软件文件即可。

需要注意的是——替换时确保文件的属性和权限，必须使用cp -ar xxx等具有权限和属性保留属性的命令

• Oracle数据信息的回滚

如果在升级Oracle数据库数据字典等时失败了，可以用之前的全备进行恢复

• 集群注册表OCR的恢复

根据打补丁之前刚备份的副本对现有OCR进行恢复即可

 

寻求帮助

如果在打补丁过程中遇到问题可以自行上网搜索相关资料，或咨询相关DBA和Oracle人员寻求帮助。

 

Read Me样例

补丁名称：p20996944_112030_Linux-x86-64.zip

补丁类型：GI PSU（RAC集群补丁）

下图为《readme.html》快照（文章末尾有文字版）（以下内容仅供学习参考，版权归Oracle所有）

Skip Headers
Oracle® Database
Patch 20996944 - Oracle Grid Infrastructure Patch Set Update 11.2.0.3.15 (Jul2015) (Includes Database PSU)

 

Released: July 14, 2015

In this document Oracle Database Home refers to Enterprise Edition or Standard Edition Database software. GI refers to Grid Infrastructure and PSU refers to Patch Set Update.

The GI PSU patch includes updates for both the Clusterware home and Database home that can be applied in a rolling fashion.

This patch is Data Guard Standby First Installable - See My Oracle Support Document 1265700.1 Oracle Patch Assurance - Data Guard Standby-First Patch Apply for details on how to remove risk and reduce downtime when applying this patch.

This document is accurate at the time of release. For any changes and additional information regarding PSU 11.2.0.3.15, see these related documents that are available at My Oracle Support (http://support.oracle.com/):

Document 854428.1 Patch Set Updates for Oracle Products

Document 2006070.1 Oracle Grid Infrastructure Patch Set Update 11.2.0.3.15 Known Issues

This document includes the following sections:

Section 1, "Patch Information"

Section 2, "Patch Installation and Deinstallation"

Section 3, "Known Issues"

Section 4, "References"

Section 5, "Manual Steps for Apply/Rollback Patch"

Section 6, "Bugs Fixed by This Patch"

Section 7, "Documentation Accessibility"

1 Patch Information
GI PSUs are cumulative and include the Database PSU and associated CPU program security content.

Table 1 describes installation types and security content. For each installation type, it indicates the most recent patches, which includes new security fixes that are pertinent to that installation type. If there are no security fixes to be applied to an installation type, then "None" is indicated. If a specific patch is listed, then apply that or any later patch to be current with security fixes.

Table 1 Installation Types and Security Content

Installation Type	Latest PSU with Security Fixes
Server homes

GI PSU 11.2.0.3.15

Grid Infrastructure home

GI PSU 11.2.0.3.15

Client-Only Installations

Database PSU 11.2.0.3.7 to address CVE-2013-3751.

Instant Client Installations

Database PSU 11.2.0.3.7 to address CVE-2013-3751.

(The Instant Client installation is not the same as the client-only Installation. For additional information about Instant Client installations, see Oracle Call Interface Programmer's Guide.)


Table 2 lists the various configurations and the applicable PSU that should be used to patch that configuration.

Table 2 Configuration and PSU Mapping

Configuration	GI Version	Database Versions	PSU Patch (to Apply)	OPatch Command	Comments
GI Home in conjunction with RAC, RACOne, or Single Instance home

11.2.0.3

11.2.0.3

GI PSU

OPatch auto

GI Home and all the Database Homes will be patched

GI Home in conjunction with RAC, RACOne, or Single Instance home

11.2.0.3

11.2.0.3 and prior versions

GI PSU

OPatch auto

GI Home and Database Home at 11.2.0.3 version will be patched.

For Database home with version other than 11.2.0.3, apply the appropriate Database PSU for that version. For example, apply 11.1.0.7.x PSU to Database version 11.1.0.7.0.

GI Home in conjunction with RAC, RACOne, or Single Instance home

11.2.0.3

Versions prior to 11.2.0.3

GI PSU

OPatch auto

GI Home alone is patched.

For Database home, apply the appropriate Database PSU for that version. For example, apply 11.1.0.7.x PSU to Database version 11.1.0.7.0.

Oracle Restart Home

11.2.0.3

11.2.0.3

GI PSU

OPatch auto

GI Home and all the Database Homes will be patched.

Database Single Instance home

NA

11.2.0.3

Database PSU

OPatch apply

None

Database Client home

NA

11.2.0.3

Database PSU

OPatch apply

None


Table 3 lists the various patches by patch number getting installed as part of this GI PSU patch.

Table 3 Patch Numbers Getting Installed as Part of this GI PSU Patch

Patch Number	Description	Applicable Homes
20760997


DB PSU 11.2.0.3.15 (INCLUDES CPUJUL2015)

Both DB Homes and Grid Home

17592127


GIPSU 11.2.0.3.9 (GI Components)

Both DB Homes and Grid Home


2 Patch Installation and Deinstallation
This section includes the following sections:

Section 2.1, "Patch Installation Prerequisites"

Section 2.2, "One-off Patch Conflict Detection and Resolution"

Section 2.3, "OPatch auto for GI"

Section 2.4, "Patch Installation"

Section 2.5, "Patch Post-Installation Instructions"

Section 2.6, "Patch Post-Installation Instructions for Databases Created or Upgraded after Installation of Patch in the Oracle Home"

Section 2.7, "Patch Deinstallation"

Section 2.8, "Patch Post-Deinstallation Instructions for an Oracle RAC Environment"

2.1 Patch Installation Prerequisites
You must satisfy the conditions in the following sections before applying the patch:

OPatch Utility Information

OCM Configuration

Validation of Oracle Inventory

Download and Unzip the Patch

Stop EM Agent Processes Prior to Patching and Prior to Rolling Back the Patch

2.1.1 OPatch Utility Information
You must use the OPatch utility version 11.2.0.3.5 or later to apply this patch. Oracle recommends that you use the latest released OPatch version for 11.2 releases, which is available for download from My Oracle Support patch 6880880 by selecting ARU link for the 11.2.0.0.0 release. It is recommended that you download the Opatch utility and the patch in a shared location to be able to access them from any node in the cluster for the patch application on each node.

When patching the GI Home, a shared location on ACFS only needs to be unmounted on the node where the GI Home is being patched.

The new opatch utility should be updated in all the Oracle RAC database homes and the GI home that are being patched.

To update Opatch, use the following instructions:

Download the OPatch utility to a temporary directory.

For each Oracle RAC database home and the GI home that are being patched, run the following commands as the home owner to extract the OPatch utility.

$ unzip <OPATCH-ZIP> -d <ORACLE_HOME>
$ <ORACLE_HOME>/OPatch/opatch version
The version output of the previous command should be 11.2.0.3.5 or later.

For information about OPatch documentation, including any known issues, see My Oracle Support Document 293369.1 OPatch documentation list.

2.1.2 OCM Configuration
The OPatch utility will prompt for your OCM (Oracle Configuration Manager) response file when it is run. You should enter a complete path of OCM response file if you already have created this in your environment. OCM response file is required and is not optional.

If you do not have the OCM response file (ocm.rsp), see the following My Oracle Support Document 966023.1 How To Create An OCM Response File For Opatch Silent Installation.

2.1.3 Validation of Oracle Inventory
Before beginning patch application, check the consistency of inventory information for GI home and each database home to be patched. Run the following command as respective Oracle home owner to check the consistency.

$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>
If this command succeeds, it lists the Oracle components that are installed in the home. Save the output so you have the status prior to the patch apply.

If this command fails, contact Oracle Support Services for assistance.

2.1.4 Download and Unzip the Patch
To apply the patch, it must be accessible from all nodes in the Oracle cluster. Download the patch and unzip it to a shared location, this is called the <UNZIPPED_PATCH_LOCATION>. This directory must be empty and not be /tmp. Additionally, the directory should have read permission for the ORA_INSTALL group.

$ cd <UNZIPPED_PATCH_LOCATION>
Check that the directory is empty.

$ ls
Unzip the patch as grid home owner.

$ unzip p20996944_112030_<platform>.zip
2.1.5 Stop EM Agent Processes Prior to Patching and Prior to Rolling Back the Patch
You must stop the EM agent processes running from the database home, prior to patching the Oracle RAC database or GI Home and prior to rolling back the patch from Oracle RAC database or GI Home. Execute the following command on the node to be patched or the node where the patch is to be rolled back.

As the Oracle RAC database home owner execute:

$ <ORACLE_HOME>/bin/emctl stop dbconsole
2.2 One-off Patch Conflict Detection and Resolution
See My Oracle Support Document 1061295.1 Patch Set Updates - One-off Patch Conflict Resolution to determine, for each conflicting patch, whether a conflict resolution patch is already available, and if you need to request a new conflict resolution patch or if the conflict may be ignored.

The fastest and easiest way to determine whether you have one-off patches in the Oracle home that conflict with the patch, and to get the necessary conflict resolution patches, is to use the Patch Recommendations and Patch Plans features on the Patches & Updates tab in My Oracle Support. These features work in conjunction with the My Oracle Support Configuration Manager. Recorded training sessions on these features can be found in Document 603505.1.

However, if you are not using My Oracle Support Patch Plans, the My Oracle Support Conflict Checker tool enables you to upload an OPatch inventory and check the patches that you want to apply to your environment for conflicts.

If no conflicts are found, you can download the patches. If conflicts are found, the tool finds an existing resolution to download. If no resolution is found, it will automatically request a resolution, which you can monitor in the Plans and Patch Requests region of the Patches & Updates tab.

For more information, see Knowledge Document 1091294.1, How to use the My Oracle Support Conflict Checker Tool.


Note:

When performing the conflict analysis on the Database Oracle Home inventory, use the Database PSU patch instead of the Grid Infrastructure PSU patch.
2.3 OPatch auto for GI
The Opatch utility has automated the patch application for the Oracle Grid Infrastructure (GI) home and the Oracle RAC database homes when run with root privileges. It must be executed on each node in the cluster if the GI home or Oracle RAC database home is in non-shared storage. The utility should not be run in parallel on the cluster nodes.

For more information about opatch auto, see My Oracle Support Document 1339140.1 FAQ: OPatch/Patch Questions/Issues for Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environments.

For detailed patch installation instructions, see Section 2.4, "Patch Installation".

2.4 Patch Installation
The patch instructions will differ based on the configuration of the Grid infrastructure and the Oracle RAC database homes. Patching instructions for Oracle RAC Database Homes and GI together are listed below.

The most common configurations are listed as follows:

Case 1: GI Home and the Database Homes that are not shared and ACFS file system is not configured.

Case 2: GI Home is not shared, Database Home is shared, ACFS may be used.

For other configurations listed below, see My Oracle Support Document 1494646.1:

GI Home is not shared, the Database Home is not shared, ACFS may be used.

Patching Oracle RAC Database Homes.

Patching GI Home alone.

Patching Oracle Restart Home.

Patching a software only GI Home installation or before the GI Home is configured.

Patching Oracle RAC Database Homes and GI Together

Case 1: GI Home and the Database Homes that are not shared and ACFS file system is not configured.

As root user, execute the following command on each node of the cluster:

# opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>
Case 2: GI Home is not shared, Database Home is shared, ACFS may be used.

Patching instructions:

From the Oracle database home, make sure to stop the Oracle RAC databases running on all nodes. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>
On the 1st node, unmount the ACFS file systems. See My Oracle Support Document 1494652.1 for unmounting ACFS file systems.

On the 1st node, apply the patch to the GI Home using the opatch auto command. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>
If the message, "A system reboot is recommended before using ACFS” is shown, then a reboot must be issued before continuing. Failure to do so will result in running with an unpatched ACFS\ADVM\OKS driver.

On the 1st node, remount ACFS file systems. See My Oracle Support Document 1494652.1 for mounting ACFS file systems.

On the 1st node, apply the patch to the Database home using the opatch auto command. Since the Database home is shared, this operation will patch the Database home across the cluster. Note that a USM only patch cannot be applied to a database home. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <DATABASE_HOME> -ocmrf <ocm response file>
On the 1st node only, restart the Oracle instance, which you have previously stopped in Step 1. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
On the 2nd (next) node, unmount the ACFS file systems. See My Oracle Support Document 1494652.1 for unmounting ACFS file systems.

On the 2nd node, apply the patch to GI Home using the opatch auto command. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>
If the message, "A system reboot is recommended before using ACFS” is shown, then a reboot must be issued before continuing. Failure to do so will result in running with an unpatched ACFS\ADVM\OKS driver.

On the 2nd node, running the opatch auto command in Step 9 will restart the stack.

On the 2nd node, remount ACFS file systems. See My Oracle Support Document 1494652.1 for mounting ACFS file systems.

On the 2nd node only, restart the Oracle instance, which you have previously stopped in Step 1. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
Repeat Steps 8 through 13 for all remaining nodes of the cluster.

2.5 Patch Post-Installation Instructions
After installing the patch, perform the following actions:

Apply conflict resolution patches as explained in Section 2.5.1.

If applying a PSU, load modified SQL files into the database, as explained in Section 2.5.2.

Upgrade Oracle Recovery Manager catalog, as explained in Section 2.5.3.

2.5.1 Applying Conflict Resolution Patches
Apply the patch conflict resolution one-off patches that were determined to be needed when you performed the steps in Section 2.2, "One-off Patch Conflict Detection and Resolution".

2.5.2 Loading Modified SQL Files into the Database
The following steps load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.

For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT
The catbundle.sql execution is reflected in the dba_registry_history view by a row associated with bundle series PSU.

For information about the catbundle.sql script, see My Oracle Support Document 605795.1 Introduction to Oracle Database catbundle.sql.

If the OJVM PSU was applied for a previous GI PSU patch, you may see invalid Java classes after execution of the catbundle.sql script in the previous step. If this is the case, run utlrp.sql to re-validate these Java classes.

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
Check the following log files in $ORACLE_BASE/cfgtoollogs/catbundle for any errors:

catbundle_PSU_<database SID>_APPLY_<TIMESTAMP>.log
catbundle_PSU_<database SID>_GENERATE_<TIMESTAMP>.log
where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, see Section 3, "Known Issues".

2.5.3 Upgrade Oracle Recovery Manager Catalog
If you are using the Oracle Recovery Manager, the catalog needs to be upgraded. Enter the following command to upgrade it:

$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;
2.6 Patch Post-Installation Instructions for Databases Created or Upgraded after Installation of Patch in the Oracle Home
These instructions are for a database that is created or upgraded after the installation of the patch.

You must execute the steps in Section 2.5.2, "Loading Modified SQL Files into the Database" for any new database only if it was created by any of the following methods:

Using DBCA (Database Configuration Assistant) to select a sample database (General, Data Warehouse, Transaction Processing)

Using a script that was created by DBCA that creates a database from a sample database

There are no actions required for databases that have been upgraded.

2.7 Patch Deinstallation
The patch rollback instructions will differ based on the configuration of the Grid infrastructure and the Oracle RAC database homes. Roll Back instructions for Oracle RAC Database Homes and GI are listed below.

The most common configurations are listed as follows:

Case 1: GI Home and Database Homes that are not shared and ACFS file system is not configured.

Case 2: GI Home is not shared, Database Home is shared and ACFS may be used.

For other configurations listed below, see My Oracle Support Document 1494646.1:

GI Home is not shared, the Database Home is not shared, ACFS may be used.

Rolling back from Oracle RAC Database Homes.

Rolling back from GI Home alone.

Rolling back the patch from Oracle Restart Home.

Rolling back the patch from a software only GI Home installation or before the GI Home is configured.

Roll Back the Oracle RAC Database Homes and GI Together

Case 1: GI Home and Database Homes that are not shared and ACFS file system is not configured.

As root user, execute the following command on each node of the cluster.

# opatch auto <UNZIPPED_PATCH_LOCATION> -rollback -ocmrf <ocm response file>
If the message, "A system reboot is recommended before using ACFS" is shown, then a reboot must be issued before continuing. Failure to do so will result in running with an unpatched ACFS\ADVM\OKS driver.

Case 2: GI Home is not shared, Database Home is shared and ACFS may be used.

From the Oracle database home, make sure to stop the Oracle RAC databases running on all nodes. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>
On the 1st node, unmount the ACFS file systems. See My Oracle Support Document 1494652.1 for unmounting ACFS file systems.

On the 1st node, roll back the patch from the GI Home using the opatch auto command. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -rollback -ocmrf <ocm response file>
If the message, "A system reboot is recommended before using ACFS” is shown, then a reboot must be issued before continuing. Failure to do so will result in running with an unpatched ACFS\ADVM\OKS driver.

On the 1st node, remount ACFS file systems. See My Oracle Support Document 1494652.1 for mounting ACFS file systems.

On the 1st node, roll back the patch to the Database home using the opatch auto command. This operation will rollback the patch to the Database home across the cluster given that it is a shared ACFS home. Note that a USM only patch cannot be applied to a Database home. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <DATABASE_HOME> -rollback -ocmrf <ocm response file>
On the 1st node only, restart the Oracle instance, which you have previously stopped in Step 1. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
On the 2nd (next) node, unmount the ACFS file systems. See My Oracle Support Document 1494652.1 for unmounting ACFS file systems.

On the 2nd node, roll back the patch to GI Home using the opatch auto command. As root user, execute the following command:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -rollback -ocmrf <ocm response file>
If the message, "A system reboot is recommended before using ACFS” is shown, then a reboot must be issued before continuing. Failure to do so will result in running with an unpatched ACFS\ADVM\OKS driver.

On the 2nd node, running the opatch auto command in Step 9 will restart the stack.

On the 2nd node, remount ACFS file systems. See My Oracle Support Document 1494652.1 for mounting ACFS file systems.

On the 2nd node only, restart the Oracle instance, which you have previously stopped in Step 1. As the database home owner execute:

$ <ORACLE_HOME>/bin/srvctl start instance –d <db-unique-name> -n <nodename>
Repeat Steps 8 through 13 for all remaining nodes of the cluster.

2.8 Patch Post-Deinstallation Instructions for an Oracle RAC Environment
Follow these steps only on the node for which the steps in Section 2.5.2, "Loading Modified SQL Files into the Database" were executed during the patch application.:

Start all database instances running from the Oracle home. (For more information, see Oracle Database Administrator's Guide.)

For each database instance running out of the ORACLE_HOME, connect to the database using SQL*Plus as SYSDBA and run the rollback script as follows:

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle_PSU_<database SID PREFIX>_ROLLBACK.sql
SQL> QUIT
In an Oracle RAC environment, the name of the rollback script will have the format catbundle_PSU_<database SID PREFIX>_ROLLBACK.sql.

If the OJVM PSU was applied for a previous GI PSU patch, you may see invalid Java classes after execution of the catbundle.sql script in the previous step. If this is the case, run utlrp.sql to re-validate these Java classes.

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql
Check the log file for any errors. The log file is found in $ORACLE_BASE/cfgtoollogs/catbundle and is named catbundle_PSU_<database SID>_ROLLBACK_<TIMESTAMP>.log where TIMESTAMP is of the form YYYYMMMDD_HH_MM_SS. If there are errors, see Section 3, "Known Issues".

Ensure that you verify the Oracle Inventory and compare the output with the one you ran in Section 2.1.3, "Validation of Oracle Inventory" and re-apply any patches that were rolled back as part of this patch apply. To verify the inventory, run the following command:

$ opatch lsinventory
All other instances can be started and accessed as usual while you are executing the deinstallation steps.

3 Known Issues
For issues documented after the release of this PSU, see My Oracle Support Document 2006070.1 Oracle Grid Infrastructure Patch Set Update 11.2.0.3.13 Known Issues.

This section includes the following known issues:

Section 3.1, "Possible Workaround Needed for Quality of Service Management (QoSM) Customers"

Section 3.2, "Warnings May Be Returned During the Re-link Phase of 20760997"

3.1 Possible Workaround Needed for Quality of Service Management (QoSM) Customers
This workaround is relevant to either of the following scenarios:

All Quality of Service Management (QoSM) customers

Customers who have explicitly/manually secured the ora.oc4j resource by changing the default password of the QoSM admin user and/or ora.oc4j admin user in either of the following situations:

Prior to applying the 11.2.0.3.6 GIPSU.

After applying 11.2.0.3.6 GIPSU, and prior to the rollback of the 11.2.0.3.6 GIPSU.

To verify whether the workaround is necessary, run the following qosctl command utility:

qosctl -checkpasswd <QosM admin|ora.oc4j admin user>
If you encounter either of the following errors after running the utility, the workaround described in Section 3.1.1, "Workaround" should be applied:

An error returned:

"User is deactivated" for the QosM admin user
        oracle.security.jazn.spi.xml.XMLRealmUser authenticate
        INFO: User(jazn.com/<user_name>) is deactivated. AUTH FAILURE.
        oracle.security.jazn.login.module.RealmLoginModule authenticate
        SEVERE:                 [RealmLoginModule] authentication failed
        Authentication Failed
An error returned:

Unsuccessful verification of user/password pair for the ora.oc4j admin user
        Unsuccessful verification of user/password pair.
3.1.1 Workaround
The following steps describe the workaround to apply if you encounter either of the two errors previously described:

Stop the OC4J container.

#srvctl stop oc4j
Set the OCR wallet credential. You will be prompted for a new password.

#crsctl modify wallet -type APPQOSADMIN  -user qosadmin -passwd
Get the latest JAZN data file to local node.

#crsctl get jazn $ORACLE_HOME/oc4j/j2ee/home/OC4J_DBWLM_config/system-jazn-data.xml -f
Modify the JAZN data file using the new password:

Open and edit the JAZN data file using the vi editor.

Locate the credentials for qosadmin and replace it by: <credentials>!new_passwd</credentials>, where new_passwd must match the new password in Step 2.

Set local JAZN data file to OCR.

#crsctl set jazn $ORACLE_HOME/oc4j/j2ee/home/OC4J_DBWLM_config/system-jazn-data.xml -f
Restart OC4J in local node where local_node is the local node name.

#crsctl start resource ora.oc4j -n <local_node>
Activate the qosadmin user.

#qosctl qosadmin -setpasswd qosadmin <new_passwd> <new_passwd>
Restart the OC4J to refresh the in-memory credentials of the container.

#srvctl stop oc4j
#srvctl start oc4j
3.2 Warnings May Be Returned During the Re-link Phase of 20760997
Warnings may be returned during the re-link phase of 20760997. These warnings may be ignored.

warning: overriding commands for target `nmosudo'
warning: ignoring old commands for target `nmosudo'
See the following document for additional information.

Document 1562458.1 Relinking the DB Control 11.2.0.3 Agent Displays a Warning Message "overriding commands for target 'nmosudo'"

4 References
The following documents are references for this patch.

Document 1494646.1 Patch Installation and Deinstallation

Document 1494652.1 Instructions for Mounting/Unmounting ACFS File Systems

Document 854428.1 Patch Set Updates for Oracle Products

Document 360870.1 Impact of Java Security Vulnerabilities on Oracle Products

Document 468959.1 Enterprise Manager Grid Control Known Issues

Document 1339140.1 Opatch/Patch Questions/Issues for Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environments

Document 2006070.1 Oracle Grid Infrastructure Patch Set Update 11.2.0.3.13 Known Issues

5 Manual Steps for Apply/Rollback Patch
See My Oracle Support Document 1494646.1 for cases where opatch auto cannot be used.

6 Bugs Fixed by This Patch
See My Oracle Support Document 1517790.1.

7 Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/us/corporate/accessibility/support/index.html if you are hearing impaired.

Patch 20996944 - Oracle Grid Infrastructure Patch Set Update 11.2.0.3.15 (Jul2015)

Copyright © 2006, 2015, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Copyright © 2006, 2015, Oracle and/or its affiliates. All rights reserved.

※ 如果您觉得文章写的还不错， 别忘了在文末给作者点个赞哦 ~

over