Readme - Patch Installation and Deinstallation For 11.2.0.3.x GI PSU (文档 ID 1494646.1)

Oracle® Database

Oracle Grid Infrastructure 11.2.0.3.x Patch Set Update SUPPLEMENTAL README

Released: January 15, 2013

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.

Note:

The purpose of this note is to serve as a SUPPLEMENTAL README for all 11.2.0.3.x GI PSU.

The primary reference document for every 11.2.0.3.x GI PSU is the README shipped with that PSU. This document serves as a supplement to that README.

This supplemental readme contains  additional application scenarios  and  manual apply/rollback steps .

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 any 11.2.0.3.x GI PSU, see the README for that GI PSU, and see also these related documents that are available at My Oracle Support ( http://support.oracle.com/ ):

  • Document  854428.1   Patch Set Updates for Oracle Products

  • Document  1500862.1   11.2.0.3.X Grid Infrastructure Bundle/PSU 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, "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.5

Grid Infrastructure home

GI PSU 11.2.0.3.5

Client-Only Installations

Database PSU 11.2.0.3.4 to address CVE-2012-3151

Instant Client Installations

None

(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

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

For GI PSU prior to 11.2.0.3.6, you must use the OPatch utility version 11.2.0.3.0 or later to apply this patch. For GI PSU 11.2.0.3.6 and above, you must use OPatch utility version 11.2.0.3.4 or later.. Oracle recommends that you use the latest released OPatch 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:

  1. Download the OPatch utility to a temporary directory.

  2. 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.0 or later (11.2.0.3.4 or later for GI PSU 11.2.0.3.6 and above).

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.

Important Note:

In this readme:

  • The downloaded patch location directory is referred as  <UNZIPPED_PATCH_LOCATION> .

  • The Patch Number of the 11.2.0.3.x GI PSU as a whole is referred to as  <GI_PSU_number> .

  • The Patch Number of the 11.2.0.3.x DB PSU, which is bundled with the GI PSU, is referred to as  <DB_PSU_number> .

  • The Patch Number of the Grid components of the 11.2.0.3.x GI PSU is referred to as  <GI_Components_number> .

For GI PSU 11.2.0.3.1 - 11.2.0.3.4, the GI PSU itself and the Grid components have the same patch number.
For GI PSU 11.2.0.3.5+, the Grid components of the GI PSU have a separate patch number.

Pre-11.2.0.3.5 Example:
Bug 14275572 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.4  contains
       Bug 14275572  - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.4
       Bug 14275605  - DATABASE PATCH SET UPDATE 11.2.0.3.4
In this example, the  <GI_PSU_number>  and  <GI_Components_number>  are both  14275572 . The  <DB_PSU_number>  is  14275605 .

11.2.0.3.5 and up:

BUG 14727347 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.5  contains
       BUG 15876003  - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.5 (GI COMPONENTS) 
       BUG 14727310  - DATABASE PATCH SET UPDATE 11.2.0.3.5 
In this example, the  <GI_PSU_number>  is  14727347 ; the  <GI_Components_number>  is  15876003 ; and the  <DB_PSU_number>  is  14727310 .

BUG 16083653 - 11.2.0.3.6 (Apr 2013) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 16315641 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.6(GI COMPONENTS) 
       BUG 16056266  - 11.2.0.3.6 (Apr 2013) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  16083653 ; the  <GI_Components_number>  is  16315641 ; and the  <DB_PSU_number>  is  16056266 .

BUG 16742216 - 11.2.0.3.7 (Jul 2013) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 16619898 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.7(GI COMPONENTS) 
       BUG 16619892  - 11.2.0.3.7 (Jul 2013) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  16742216 ; the  <GI_Components_number>  is  16619898 ; and the  <DB_PSU_number>  is  16619892 .

BUG 17272731 - 11.2.0.3.8 (Oct 2013) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 17076717 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.8(GI COMPONENTS) 
       BUG 16902043 - 11.2.0.3.8 (Oct 2013) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  17272731 ; the  <GI_Components_number>  is  17076717 ; and the  <DB_PSU_number>  is  16902043 .

BUG 17735354 - 11.2.0.3.9 (Jan 2014) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 17592127 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.9(GI COMPONENTS) 
       BUG 17540582 - 11.2.0.3.9 (Jan 2014) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  17735354 ; the  <GI_Components_number>  is  17592127 ; and the  <DB_PSU_number>  is  17540582 .

BUG 17735354 - 11.2.0.3.9 (Jan 2014) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 17592127 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.9(GI COMPONENTS) 
       BUG 17540582 - 11.2.0.3.9 (Jan 2014) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  17735354 ; the  <GI_Components_number>  is  17592127 ; and the  <DB_PSU_number>  is  17540582 .

BUG 18139678 - 11.2.0.3.10 (Apr 2014) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 17592127 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.9(GI COMPONENTS) 
       BUG 18031683 - 11.2.0.3.10 (Apr 2014) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  18139678 ; the  <GI_Components_number>  is  17592127 ; and the  <DB_PSU_number>  is  18031683 .

BUG 18706488 - 11.2.0.3.11 (Jul 2014) Grid Infrastructure Patch Set Update (GI PSU)  contains
       BUG 17592127 - GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.9(GI COMPONENTS) 
       BUG 18522512 - 11.2.0.3.11 (Jul 2014) Database Patch Set Update (PSU)
In this example, the  <GI_PSU_number>  is  18706488 ; the  <GI_Components_number>  is  17592127 ; and the  <DB_PSU_number>  is  18522512 .

$ cd <UNZIPPED_PATCH_LOCATION>

Check that the directory is empty.

$ ls

Unzip the patch as grid home owner.

$ unzip p<GI_PSU_number>_112030_<platform>.zip

For example, if  <UNZIPPED_PATCH_LOCATION>  in your environment is  /u01/oracle/patches , enter the following command:

$ cd /u01/oracle/patches

If the GI PSU patch number is 14275572, as the Grid home owner execute:

$ unzip p14275572_112030_<platform>.zip

Continuing the example: 
In the case of patch 14275572, which is GI PSU 11.2.0.3.4, it is bundled with 14275605 which is DB PSU 11.2.0.3.4 . 
By unzipping  p14275572_112030_<platform>.zip  in  /u01/oracle/patches , two directories are created: 14275572 and 14275605.

$ ls -1 /u01/oracle/patches
14275572
14275605
bundle.xml
README.html
README.txt

The PSU patch may include multiple patches and you may notice that there are multiple directories created with distinct bug numbers. For a discussion of the different patch numbers for the GI and DB components of the GI PSU, please see this  important note . The GI and DB components are separate patches. When the apply instructions have separate instructions for the DB and GI PSU patches, you must be careful to follow the instructions for the correct one.

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 .

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

This section will guide you through the steps required to apply this patch to Oracle RAC database homes, the Grid home, or all relevant homes on the cluster.

The patch instructions will differ based on the configuration of the Grid infrastructure and the Oracle RAC database homes.

The patch installations will also differ based on following aspects of your existing configuration:

  • GI home is shared or non-shared

  • The Oracle RAC database home is shared or non-shared

  • The Oracle RAC database home software is on ACFS or non-ACFS file systems.

  • Patch all the Oracle RAC database and the GI homes together, or patch each home individually

You must choose the most appropriate case that is suitable based on the existing configurations and your patch intention.

Note:

You must stop the EM agent processes running from the database home, prior to patching the Oracle RAC database or GI Home. Execute the following command on the node to be patched.

As the Oracle RAC database home owner execute:

$ <ORACLE_HOME>/bin/emctl stop dbconsole
  • Case 1: Patching Oracle RAC Database Homes and the GI Home Together

  • Case 2: Patching Oracle RAC Database Homes

  • Case 3: Patching GI Home Alone

  • Case 4: Patching Oracle Restart Home

  • Case 5: Patching a Software Only GI Home Installation or Before the GI Home Is Configured

Case 1: Patching Oracle RAC Database Homes and the GI Home Together

Follow the instructions in this section if you would like to patch all the Oracle RAC database homes of release version 11.2.0.3 and the 11.2.0.3 GI home.

Case 1.1: GI Home Is Not Shared

Case 1.1.1: ACFS File System Is Not Configured and Database Homes Are Not Shared

Follow these instructions in this section if the GI home is not shared and none of the Oracle database homes is shared.

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

# opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>

Case 1.1.2A: Patching the GI Home and Database Home Together, the GI Home Is Not Shared, the Database Home Is Shared, ACFS May Be Used

  1. 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>
    
  2. On the 1st node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. 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>
    
  4. 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.

  5. On the 1st node, remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  6. 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>
    
  7. 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>
    
  8. On the 2nd (next) node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  9. 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>
    
  10. 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.

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

  12. On the 2nd node, remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  13. 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>
    
  14. Repeat Steps 8 through 13 for all remaining nodes of the cluster.

Case 1.1.2B: Patching the GI Home and the Database Home Together, the GI Home Is Not Shared, the Database Home Is Not Shared, ACFS May Be Used

For each node, perform the following steps:

  1. On the local node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  2. On the local node, apply the patch to the GI home and to the Database home.

    As root user, execute the following command:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>
    

    This operation will patch both the CRS home and the Database home.

  3. 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.

  4. The  opatch auto  command will restart the stack on the local node and restart the Databases on the local node.

  5. Repeat Steps 1 through 3 for all remaining nodes of the cluster.

Case 1.2: GI Home Is Shared

Follow these instructions in this section if the GI home is shared.

Note:

Patching a shared GI home requires shutdown of Oracle GI stack on all the remote nodes in the cluster. This also means you need to stop all Oracle RAC databases which depend on GI stack, ASM for data files, or an ACFS file system.

  1. From the Oracle database home, make sure to stop the Oracle RAC databases running on all nodes.

    As Oracle database home owner:

    $ <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>
    

    ORACLE_HOME: Complete path of the Oracle database home.

  2. Make sure the ACFS file systems are unmounted on all the nodes.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. As root user, execute the following on all the remote nodes to stop the CRS stack:

    # <GI_HOME>/bin/crsctl stop crs
    
  4. Patch the GI home.

    On local node, as root user, execute the following command:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>
    
  5. 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.

  6. On each remote node:

    1. As root user, run:

      # <GI_HOME>/crs/install/rootcrs.pl -patch
      
    2. 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.

    3. Restart the stack on each remote node.

      As root user execute:

      # <GI_HOME>/bin/crsctl start crs
      
  7. Mount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  8. For each Oracle RAC database home, execute the following command on each node if the database home software is not shared. Note that a USM only patch cannot be applied to a Database home.

    For each database home execute the following as root user:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <ORACLE_HOME> -ocmrf <ocm response file>
    

    ORACLE_HOME: Complete path of Oracle database home.

    Note:

    The previous command should be executed only once on any one node if the database home is shared.

  9. Restart the Oracle databases that you have previously stopped in step 1.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database –d <db-unique-name>
    

Case 2: Patching Oracle RAC Database Homes

You should use the following instructions if you prefer to patch Oracle RAC databases alone with this patch. Note that a USM only patch cannot be applied to a Database Home.

Case 2.1: Non-Shared Oracle RAC Database Homes

  1. Execute the following command on each node of the cluster.

    As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <Comma separated Oracle home paths> -ocmrf <ocm response file>
    

Case 2.2: Shared Oracle RAC Database Homes

  1. Make sure to stop the databases running from the Oracle RAC database homes that you would like to patch. Execute the following command to stop each database.

    As Oracle database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop database -d <db_unique_name>
    
  2. As root user execute only on the local node.

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <Comma separated Oracle home paths> -ocmrf <ocm response file>
    
  3. Restart the Oracle databases that were previously stopped in Step 1. Execute the following command for each database.

    As Oracle database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database -d <db_unique_name>
    

Case 3: Patching GI Home Alone

You should use the following instructions if you prefer to patch Oracle GI (Grid Infrastructure) home alone with this patch.

Case 3.1: Non-Shared GI Home

If the GI home is not shared then use the following instructions to patch the home.

Case 3.1.1: ACFS File System Is Not Configured

Follow these instructions in this section if the GI home is not shared and none of the Oracle database homes use ACFS file system for its software files.

Execute the following on each node of the cluster.

As root user execute:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>

Case 3.1.2: ACFS File System Is Configured

Repeat Steps 1 through 6 for each node in the cluster:

  1. From the Oracle database home, stop the Oracle RAC database running on that node.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop instance –d <db-unique-name> -n <node_name>
    
  2. Unmount all ACFS file systems on this node.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. Apply the patch to the GI home on that node using the  opatch auto  command.

    Execute the following command on that node in the cluster.

    As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>
    
  4. 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.

  5. Remount ACFS file systems on that node.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  6. Restart the Oracle database on that node that 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>
    

Case 3.2: Shared GI Home

Follow these instructions in this section if the GI home is shared.

Note:

Patching a shared GI home requires shutdown of Oracle GI stack on all the remote nodes in the cluster. This also means you need to stop all Oracle RAC databases that depend on the GI stack, ASM for data file, or ACFS file system for database software.

  1. Make sure to stop the Oracle databases running from the Oracle RAC or Oracle RAC One Node database homes.

    As Oracle database home owner:

    $ <ORACLE_HOME>/bin/srvctl stop database –d <db-unique-name>
    
  2. Make sure the ACFS file systems are unmounted on all the nodes.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. As root user, execute the following on all the remote nodes to stop the CRS stack:

    # <GI_HOME>/bin/crsctl stop crs
    
  4. Execute the following command on the local node

    As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -ocmrf <ocm response file>
    
  5. 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.

  6. On each remote node:

    1. As root user, run:

      # <GI_HOME>/crs/install/rootcrs.pl -patch
      
    2. 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.

    3. Start the Oracle GI stack on all the remote nodes.

      As root user execute:

      # <GI_HOME>/bin/crsctl start crs
      
  7. Mount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  8. Restart the Oracle databases that you have previously stopped in Step 1.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database –d <db-unique-name>
    

Case 4: Patching Oracle Restart Home

You must keep the Oracle Restart stack up and running when you are patching. Use the following instructions to patch Oracle Restart home.

As root user execute:

# opatch auto <UNZIPPED_PATCH_LOCATION> -ocmrf <ocm response file>

To patch the ACFS software in an Oracle Restart environment:

  1. Unmount all ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  2. Run  <GridHome>/bin/acfsroot install .

  3. 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.

  4. Remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

Case 5: Patching a Software Only GI Home Installation or Before the GI Home Is Configured

  1. Apply the CRS patch using.

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch napply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/<GI_components_number>
    

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/<DB_PSU_number>
    

2.5  Patch Post-Installation Instructions

After installing the patch, perform the following actions:

  1. Apply conflict resolution patches as explained in  Section 2.5.1 .

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

  3. 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 .

  1. 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 .

  2. 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

You can use the following steps to roll back patches. Choose the instructions that apply to your needs.

Note:

You must stop the EM agent processes running from the database home, prior to rolling back the patch from Oracle RAC database or GI Home. Execute the following command on the node to be patched.

As the Oracle RAC or Oracle RAC One Node database home owner execute:

<ORACLE_HOME>/bin/emctl stop dbconsole
  • Case D1: Rolling Back the Oracle RAC Database Homes and GI Homes Together

  • Case D2: Rolling Back from the Oracle RAC Database Homes

  • Case D3: Rolling Back from the GI Home Alone

  • Case D4: Rolling Back the Patch from Oracle Restart Home

  • Case D5: Rolling Back the Patch from a Software Only GI Home Installation or Before the GI Home is Configured

Case D1: Rolling Back the Oracle RAC Database Homes and GI Homes Together

Follow the instructions in this section if you would like to rollback the patch from all the Oracle RAC database homes of release version 11.2.0.3 and the 11.2.0.3 GI home.

Case D1.1: GI Home Is Not Shared

Case D1.1.1: ACFS File System Is Not Configured and Database Homes Are Not Shared

Follow these instructions in this section if the GI home is not shared and none of the Oracle database homes is shared.

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 D1.1.2A: GI Home and Database Home Together, the GI Home Is Not Shared, the Database Home Is Shared

  1. 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>
    
  2. On the 1st node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. On the 1st node, to 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>
    
  4. 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.

  5. On the 1st node, remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  6. 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>
    
  7. 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>
    
  8. On the 2nd (next) node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  9. 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>
    
  10. 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.

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

  12. On the 2nd node, remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  13. 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>
    
  14. Repeat Steps  8  through  13  for all remaining nodes of the cluster.

Case D1.1.2B: GI Home and the Database Home Together, the GI Home Is Not Shared, the Database Home Is Not Shared

For each node, perform the following steps:

  1. On the local node, unmount the ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  2. On the local node, roll back the patch to the GI home and to the Database home.

    As root user, execute the following command:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -rollback -ocmrf <ocm response file>
    

    This operation will patch both the CRS home and the Database home.

  3. 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.

  4. The  opatch auto  command will restart the stack on the local node and restarts the Database on the local node.

  5. Repeat Steps 1 through  4  for all remaining nodes of the cluster.

Case D1.2 GI Home Is Shared

Follow these instructions in this section if the GI home is shared.

Note:

An operation on a shared GI home requires shutdown of the Oracle GI stack on all the remote nodes in the cluster. This also means you need to stop all Oracle RAC databases that depend on the GI stack, ASM for data file, or ACFS file system.

  1. Make sure to stop the Oracle databases running from the Oracle RAC database homes.

    As Oracle database home owner:

    $ <ORACLE_HOME>/bin/srvctl stop database -d <db-unique-name>
    

    ORACLE_HOME: Complete path of the Oracle database home.

  2. Make sure the ACFS file systems are unmounted on all the nodes.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. As root user, execute the following on all the remote nodes to stop the CRS stack:

    # <GI_HOME>/bin/crsctl stop crs
    
  4. Roll back the patch from the GI home.

    On local node, as root user, execute the following command:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -rollback -ocmrf <ocm response file>
    
  5. 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.

  6. Start the Oracle GI stack on all the remote nodes.

    As root user execute:

    # <GI_HOME>/bin/crsctl start crs
    
  7. Mount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  8. For each Oracle RAC database home, execute the following command on each node if the database home software is not shared. Note that a USM only patch cannot be applied to a Database home.

    For each database home, execute the following as root user:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <ORACLE_HOME> -rollback -ocmrf <ocm response file>
    

    ORACLE_HOME: Complete path of Oracle database home.

    Note:

    The previous command should be executed only once on any one node if the database home is shared.

  9. Restart the Oracle databases that you have previously stopped in Step 1.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database -d <db-unique-name>
    

Case D2: Rolling Back from the Oracle RAC Database Homes

You should use the following instructions if you prefer to roll back the patch from Oracle RAC databases homes alone.

Case D2.1: Non-Shared Oracle RAC Database Homes

Note that a USM only patch cannot be applied to a Database home.

Execute the following command on each node of the cluster.

As root user execute:

# opatch auto <UNZIPPED_PATCH_LOCATION> -oh <Comma separated Oracle home paths> -rollback -ocmrf <ocm response file>

Case D2.2: Shared Oracle RAC Database Homes

Note that a USM only patch cannot be applied to a Database home.

  1. Make sure to stop the databases running from the Oracle RAC database homes from which you would like to roll back the patch. Execute the following command to stop each database.

    As Oracle database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop database -d <db_unique_name>
    
  2. As root user execute only on the local node.

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <Comma separated Oracle home paths> -rollback -ocmrf <ocm response file>
    
  3. Restart the Oracle databases that were previously stopped in Step 1. Execute the following command for each database.

    As Oracle database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database -d <db_unique_name>
    

Case D3: Rolling Back from the GI Home Alone

You should use the following instructions if you prefer to roll back the patch from the Oracle GI (Grid Infrastructure) home alone.

Case D3.1 Shared GI Home

Follow these instructions in this section if the GI home is shared.

Note:

An operation in a shared GI home requires shutdown of Oracle GI stack on all the remote nodes in the cluster. This also means you need to stop all Oracle RAC databases that depend on the GI stack, ASM for data file, or ACFS file system for database software.

  1. Make sure to stop the Oracle databases running from the Oracle RAC database homes.

    As Oracle database home owner:

    $ <ORACLE_HOME>/bin/srvctl stop database -d <db-unique-name>
    
  2. Make sure the ACFS file systems are unmounted on all the nodes.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. As root user, execute the following on all the remote nodes to stop the CRS stack:

    # <GI_HOME>/bin/crsctl stop crs
    
  4. Execute the following command on the local node.

    As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -rollback -ocmrf <ocm response file>
    
  5. 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.

  6. Start the Oracle GI stack on all the remote nodes.

    As root user execute:

    # <GI_HOME>/bin/crsctl start crs
    
  7. Mount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  8. Restart the Oracle databases that you have previously stopped in Step 1.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start database -d <db-unique-name>
    

Case D3.2: Non-Shared GI Home

If the GI home is not shared, then use the following instructions to roll back the patch from the GI home.

Case D3.2.1: ACFS File System Is Not Configured

Follow these instructions in this section if the GI home is not shared and none of the Oracle database homes is shared.

Execute the following on each node of the cluster.

As root user execute:

# 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.

Case D3.2.2: ACFS File System Is Configured

Repeat Steps 1 through 6 for each node in the cluster:

  1. From the Oracle database home, stop the Oracle RAC database running on that node.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop instance -d <db-unique-name> -n <node_name>
    
  2. Make sure the ACFS file systems are unmounted on that node.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  3. Roll back the patch to the GI home on that node using the  opatch auto  command.

    Execute the following command on each node in the cluster.

    As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <GI_HOME> -rollback -ocmrf <ocm response file>
    
  4. 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.

  5. Remount ACFS file systems on that node.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  6. Restart the Oracle database on that node that you have previously stopped in Step 1.

    As the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start instance -d <db-unique-name> -n <node_name>
    

Case D4: Rolling Back the Patch from Oracle Restart Home

You must keep the Oracle Restart stack up and running when you are rolling back the patch from the Oracle Restart home. Use the following instructions to roll back the patch from the Oracle Restart home.

  1. As root user execute:

    # opatch auto <UNZIPPED_PATCH_LOCATION> -oh <Oracle-Restart-home> -rollback -ocmrf <ocm response file>
    
  2. 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.

To update ACFS software in an Oracle Restart configuration:

  1. Unmount all ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for unmounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

  2. Update ACFS:  <Oracle-Restart-home>/bin/acfsroot install

  3. Remount ACFS file systems.

    Follow the instructions in the following My Oracle Support Document for mounting ACFS file systems:

    1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? .

Case D5: Rolling Back the Patch from a Software Only GI Home Installation or Before the GI Home is Configured

  1. Roll back the CRS patch.

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch rollback -local -id <GI_components_number> -oh <GI_HOME>
    $ <GI_HOME>/OPatch/opatch rollback -local -id <DB_PSU_number> -oh <GI_HOME>
    

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.:

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

  2. 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.

  3. 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" .

  4. 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  1500862.1   11.2.0.3.X Grid Infrastructure Bundle/PSU Known Issues .

4  References

The following documents are references for this patch.

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

5  Manual Steps for Apply/Rollback Patch

Steps for Applying the Patch

Note:

You must stop the EM agent processes running from the database home, prior to patching the Oracle RAC database or GI Home. Execute the following command on the node to be patched.

As the Oracle RAC database home owner execute:

$ <ORACLE_HOME>/bin/emctl stop dbconsole

Execute the following on each node of the cluster in non-shared CRS and DB home environment to apply the patch.

  1. Stop the CRS managed resources running from DB homes.

    If this is a GI Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>
    

    If this is an Oracle Restart Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location>
    

    Note:

    You need to make sure that the Oracle ACFS file systems are unmounted (see My Oracle Support document  1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? ) and all other Oracle processes are shutdown before you proceed.

  2. Run the pre root script.

    If this is a GI Home, as the root user execute:

    # <GI_HOME>/crs/install/rootcrs.pl -unlock
    

    If this is an Oracle Restart Home, as the root user execute:

    # <GI_HOME>/crs/install/roothas.pl -unlock
    
  3. Apply the CRS patch using.

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch napply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/<GI_components_number>
    

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/<DB_PSU_number>
    
  4. Run the pre script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>
    
  5. Apply the DB patch.

    As the database home owner execute:

    $ <ORACLE_HOME>/OPatch/opatch napply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>
    $ <ORACLE_HOME>/OPatch/opatch apply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/<DB_PSU_number>
    
  6. Run the post script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>
    
  7. Run the post script.

    As the root user execute:

    # <GI_HOME>/rdbms/install/rootadd_rdbms.sh
    

    If this is a GI Home, as the root user execute:

    # <GI_HOME>/crs/install/rootcrs.pl -patch
    

    If this is an Oracle Restart Home, as the root user execute:

    # <GI_HOME>/crs/install/roothas.pl -patch
    
  8. 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.

  9. Start the CRS managed resources that were earlier running from DB homes.

    If this is a GI Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name>
    

    If this is an Oracle Restart Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location>
    

Steps for Rolling Back the Patch From a GI Home

Execute the following on each node of the cluster in non-shared CRS and DB home environment to rollback the patch.

  1. Stop the CRS managed resources running from DB homes.

    If this is a GI Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>
    

    If this is an Oracle Restart Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location>
    

    Note:

    You need to make sure that the Oracle ACFS file systems are unmounted (see My Oracle Support document  1494652.1   How to Mount or Unmount ACFS File System While Applying GI Patches? ) and all other Oracle processes are shut down before you proceed.

  2. Run the pre root script.

    If this is a GI Home, as the root user execute:

    # <GI_HOME>/crs/install/rootcrs.pl -unlock
    

    If this is an Oracle Restart Home, as the root user execute:

    # <GI_HOME>/crs/install/roothas.pl -unlock
    
  3. Roll back the CRS patch.

    As the GI home owner execute:

    $ <GI_HOME>/OPatch/opatch rollback -local -id <GI_components_number> -oh <GI_HOME>
    $ <GI_HOME>/OPatch/opatch rollback -local -id <DB_PSU_number> -oh <GI_HOME>
    
  4. Run the pre script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>
    
  5. Roll back the DB patch from the database home.

    As the database home owner execute:

    $ <ORACLE_HOME>/OPatch/opatch rollback -local -id <GI_components_number> -oh <ORACLE_HOME>
    $ <ORACLE_HOME>/OPatch/opatch rollback -local -id <DB_PSU_number> -oh <ORACLE_HOME>
    
  6. Run the post script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>
    
  7. Run the post script.

    As the root user execute:

    # <GI_HOME>/rdbms/install/rootadd_rdbms.sh
    

    If this is a GI Home, as the root user execute:

    # <GI_HOME>/crs/install/rootcrs.pl -patch
    

    If this is an Oracle Restart Home, as the root user execute:

    # <GI_HOME>/crs/install/roothas.pl -patch
    
  8. 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.

  9. Start the CRS managed resources that were earlier running from DB homes.

    If this is a GI Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name>
    

    If this is an Oracle Restart Home environment, as the database home owner execute:

    $ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location>
    

Patching an Oracle RAC Home Installation Manually

Note that USM only patches cannot be applied to a Database home.

  1. Run the pre script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>
    
  2. Apply the DB patch.

    As the database home owner execute:

    $ <ORACLE_HOME>/OPatch/opatch napply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>
    $ <ORACLE_HOME>/OPatch/opatch apply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/<DB_PSU_number>
    
  3. Run the post script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>
    

Rolling Back the Patch from an Oracle RAC Home Installation Manually

  1. Run the pre script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>
    
  2. Roll back the DB patch from the database home.

    As the database home owner execute:

    $ <ORACLE_HOME>/OPatch/opatch rollback -local -id <GI_components_number> -oh <ORACLE_HOME>
    $ <ORACLE_HOME>/OPatch/opatch rollback -local -id <DB_PSU_number> -oh <ORACLE_HOME>
    
  3. Run the post script for DB component of the patch.

    As the database home owner execute:

    $ <UNZIPPED_PATCH_LOCATION>/<GI_components_number>/custom/server/<GI_components_number>/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>
    

6  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/pls/topic/lookup?ctx=acc&id=trs  if you are hearing impaired.


Oracle Grid Infrastructure 11.2.0.3.x Patch Set Update SUPPLEMENTAL README

Copyright © 2006, 2013, 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, 2013, Oracle and/or its affiliates. All rights reserved.

Community Discussions

Still have questions? Use the communities window below to search for similar discussions or start a new discussion on this subject.

Note: Window is the  LIVE  community not a screenshot.

Click  here  to open in main browser window.



About Me

........................................................................................................................

● 本文作者:小麦苗,部分内容整理自网络,若有侵权请联系小麦苗删除

● 本文在itpub( http://blog.itpub.net/26736162 )、博客园( http://www.cnblogs.com/lhrbest )和个人weixin公众号( xiaomaimiaolhr )上有同步更新

● 本文itpub地址: http://blog.itpub.net/26736162

● 本文博客园地址: http://www.cnblogs.com/lhrbest

● 本文pdf版、个人简介及小麦苗云盘地址: http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答: http://blog.itpub.net/26736162/viewspace-2134706/

● DBA宝典今日头条号地址: http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群号: 230161599 (满) 、618766405

● weixin群:可加我weixin,我拉大家进群,非诚勿扰

● 联系我请加QQ好友 ( 646634621 ) ,注明添加缘由

● 于 2018-10-01 06:00 ~ 2018-10-31 24:00 在魔都完成

● 最新修改时间:2018-10-01 06:00 ~ 2018-10-31 24:00

● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

........................................................................................................................

● 小麦苗的微店 : https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

● 小麦苗出版的数据库类丛书 : http://blog.itpub.net/26736162/viewspace-2142121/

● 小麦苗OCP、OCM、高可用网络班 : http://blog.itpub.net/26736162/viewspace-2148098/

● 小麦苗腾讯课堂主页 : https://lhr.ke.qq.com/

........................................................................................................................

使用 weixin客户端 扫描下面的二维码来关注小麦苗的weixin公众号( xiaomaimiaolhr )及QQ群(DBA宝典)、添加小麦苗weixin, 学习最实用的数据库技术。

........................................................................................................................

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-2218056/,如需转载,请注明出处,否则将追究法律责任。

【mos 1494646.1】Patch Installation and Deinstallation For 11.2.0.3.x GI PSU相关推荐

  1. 信息学奥赛一本通 1855:【09NOIP提高组】潜伏者 | OpenJudge NOI 1.7 11:潜伏者 | 洛谷 P1071 [NOIP2009 提高组] 潜伏者

    [题目链接] ybt 1855:[09NOIP提高组]潜伏者 OpenJudge NOI 1.7 11:潜伏者 洛谷 P1071 [NOIP2009 提高组] 潜伏者 [题目考点] 1. 字符串 2. ...

  2. 【天池龙珠计划】Python训练营 Task04 Python数据分析:从0完成一个数据分析实战

    [天池龙珠计划]Python训练营 Task04 Python数据分析:从0完成一个数据分析实战(利用Pandas分析美国选民总统喜好度) 文章目录 [天池龙珠计划]Python训练营 Task04 ...

  3. 【mos 1265700.1】Oracle Patch Assurance - Data Guard Standby-First Patch Apply

    Oracle Patch Assurance - Data Guard Standby-First Patch Apply (文档 ID 1265700.1) In this Document Pur ...

  4. 【Linux环境部署】最新版 elasticsearch + kibana(7.15.0)安装、配置、启动(多个问题处理 + kibana仪表盘使用)

    本文的安装文件是 2021.09.23 最新发布的[elasticsearch-7.15.0-linux-x86_64.tar.gz]和[kibana-7.15.0-linux-x86_64.tar. ...

  5. 华为p20pro系统鸿蒙升级,【华为P20Pro评测】华为P20 Pro初尝EMUI 9.0 升级令人称奇(全文)_华为 P20 Pro(8GB RAM/全网通)_手机评测-中关村在线...

    01华为P20 Pro升级EMUI 9.0 最近,包括华为P20 Pro在内的9款机型升级了最新的EMUI 9.0系统,给用户带来耳目一新的感觉,系统界面充满了简洁与自然美感,功能却只增不减.特别是A ...

  6. 【Bug解决记录】类文件具有错误的版本 61.0, 应为 52.0

    今天用测试类调试MyBatis-plus的时候遇到了这个bug,初步思路是jdk版本不对应,把项目的jdk版本和Setting里的jdk版本都设置为同一版本,但没有作用 也尝试过更换maven版本,但 ...

  7. 【甘道夫】Win7x64环境下编译Apache Hadoop2.2.0的Eclipse插件

    目标: 编译Apache Hadoop2.2.0在win7x64环境下的Eclipse插件 环境: win7x64家庭普通版 eclipse-jee-kepler-SR1-win32-x86_64.z ...

  8. 【甘道夫】Win7x64环境下编译Apache Hadoop2.2.0的Eclipse小工具

    目标: 编译Apache Hadoop2.2.0在win7x64环境下的Eclipse插件 环境: win7x64家庭普通版 eclipse-jee-kepler-SR1-win32-x86_64.z ...

  9. 【MOS 966023.1】How to Create an OCM Response file to Apply a Patch in Silent

    How to Create an OCM Response file to Apply a Patch in Silent Mode - opatch silent (文档 ID 966023.1) ...

最新文章

  1. maven打包导入本地jar包
  2. python函数(三)
  3. folders默认配置 shell_分布式存储Ceph RBD-Mirror灾备方案(二)镜像模式配置
  4. java工程师占比_Java过时了吗?
  5. 修建道路 贪心,思维(女赛)
  6. window系统下安装mysql5.7教程
  7. OpenCV 凸包Convex Hull
  8. 【C#】获取网页内容及HTML解析器HtmlAgilityPack的使用
  9. 广西师范大学计算机调剂难吗,2014年广西师范大学考研调剂过来人给的建议
  10. 76岁“爷爷考生”第5次备战研究生考试
  11. vim复制、删除和粘贴一行
  12. c# winform TreeView与ListView的项互相拖动的应用[转载]
  13. Python基础知识有哪些?你都知道吗
  14. html5 响应式背景图
  15. Java各种日期计算
  16. 阿里云语音识别模型端核心技术选讲
  17. mysql change column_Modify column Vs change column
  18. Go的研习笔记-day12(以Java的视角学习Go)
  19. 请给孩子多一点点空间
  20. “无文件”攻击方式渗透实验

热门文章

  1. 学习笔记(01):SAS数据分析:从入门到企业实战-SAS PROC步骤I-2
  2. SylixOS 设备树
  3. Uncaught SyntaxError: Cannot use import statement outside a module的解决方法
  4. 【巩固地基】系列之:unity基础读书笔记(杂)
  5. Matlab实现普朗克函数
  6. 【Nginx】Nginx 发布最新稳定版-1.24.0
  7. 软件设计师-JAVA程序设计语言
  8. CodePlus | C# 网页所有图片批量下载
  9. Turbo Boost
  10. 李宏毅《机器学习》国语课程(2022)来了!附Slides和视频!