Accessibility Preferences My Oracle Support Logo

Last Login: May 29, 2021 6:44 AM IST

Switch to Cloud Support

IBM GTS India (Available)

Last Refreshed: May 30, 2021 9:19 AM IST

(0)

Help

Give Feedback...

Supplemental Readme - Patch Installation and Deinstallation for 12.1.0.x.x GI PSU and Database Proactive Bundle Patch (Doc ID 1591616.1)

To Bottom

In this Document

Main Content

1 Patch Information

2 Patch Installation and Deinstallation

2.1 Patch Installation Prerequisites

2.1.1 OPatch Utility Information

2.1.2 OCM Configuration

2.1.3 Validation of Oracle Inventory

2.1.4 Unzipping the Patch

2.1.5 One-off Patch Conflict Detection and Resolution

2.2 OPatch Automation for GI

2.3 Patch Installation

2.4 Patch Post-Installation Instructions

2.5 Patch Deinstallation

2.6 Unmounting ACFS File Systems

2.7 Mounting ACFS File Systems

3 Known Issues

4 References

5 Manual Steps for Apply/Rollback Patch

6 Documentation Accessibility

References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.2.0.1 to 12.2.0.1 [Release 12.2]
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.2 [Release 12.1]
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Information in this document applies to any platform.

MAIN CONTENT

This patch is RAC Rolling Installable.

1 Patch Information

You can install this patch automatically using the "opatchauto" command. Automatic patching helps you reduce the number of manual steps involved in patching the Oracle homes. Technically, as a preinstallation step, automatic patching stops all the dependent databases, the CRS resources, and the entire GI stack. It then patches the OracleClusterware and all applicable databases, and then, as a postinstallation step, it automatically restarts the entire GI stack, the CRS Resources, the the dependent databases.

Note:
- Oracle recommends you to avoid applying any temporary patch unless you are directed by Oracle Support who have reviewed your environment and determined that it is applicable.
- A non-clustered RDBMS home running the CSSD and ASM may also benefit from a number of the GI home patches.

These instructions can be used to apply all 12.1 GI PSUs.

The tracking bugs for PSUs along with their various component bug numbers are in the PSU readme, please use those tracking bugs while applying the patches manually.

2 Patch Installation and Deinstallation

2.1 Patch Installation Prerequisites

You must satisfy the conditions in the following sections before applying the patch:

2.1.1 OPatch Utility Information

You must use the OPatch utility version12.1.0.1.5 or later to apply this patch. Oracle recommends that you use the latest released OPatch for 12.1 releases, which is available for download from My Oracle Support patch 6880880. 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.

Note:

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 is being patched, run the following commands as the home owner to extract the OPatch utility.

$ rm -rf <ORACLE_HOME>/OPatch/* 

$ unzip <OPATCH-ZIP> -d <ORACLE_HOME>

$ <ORACLE_HOME>/OPatch/opatch version

The version output of the previous command should be 12.1.0.1.5 or later.

For information about OPatch documentation, including any known issues, see My Oracle Support Note 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.

If you do not have the OCM response file (ocm.rsp), then you should run the following command to create it.

As the GI home owner execute:

$ <ORACLE_HOME>/OPatch/ocm/bin/emocmrsp

Note: as latest opatch doesn't contain OCM anymore, the option "-ocmrf" is unnecessary if latest opatch is being used, refer to the following for details:

note 2161861.1 - OPatch: Behavior Changes starting in OPatch 12.2.0.1.5 and 11.2.0.3.14 releases

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  -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 you have not started patching, the output will also print out the GI home on all the nodes along with its patching level. The patching level must be identical for all the nodes. If they are not, do not patch. Contact Oracle Support Services for assistance.

If this command fails or the patching level is not the same on all nodes, contact Oracle Support Services for assistance.

2.1.4 Unzipping the Patch

The patch application requires explicit user actions to run 'opatchauto' command on each node of the cluster. So, it is recommended that you download and unzip the patch in a shared location to be able to access it from any node in the cluster and then as the Grid home owner execute the unzip command. To prevent installation failures, this location should be an empty directory.

Note:

Do not unzip the patch in the top level /tmp directory.

The unzipped patch location should have read permission for ORA_INSTALL group in order to patch Oracle homes owned by different owners. The ORA_INSTALL group is the primary group of the user who owns the GI home or the group owner of the Oracle central inventory.

(In this readme, the downloaded patch location directory is referred as <UNZIPPED_PATCH_LOCATION>.)

$ cd <UNZIPPED_PATCH_LOCATION>

Unzip the patch as grid home owner in a shared location. As the Grid home owner execute:

$ unzip %zipName%

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

$ cd /u01/oracle/patches

Unzip the patch as grid home owner in a shared location. As the Grid home owner execute:

$ unzip %zipName%

$ cd /u01/oracle/patches/%BUGNO%

(In this readme, <UNZIPPED_PATCH_LOCATION>/%BUGNO% location is referred as <UNZIPPED_PATCH_LOCATION>/%BUGNO%.)



In case the directory where the patch has been unzipped does not have read permissions for the group ORA_INSTALL execute the following to correct the permission

For example, for 'oracle' user, as root execute the following :

     # chown -R oracle:oinstall /u01/oracle/patches/%BUGNO%

2.1.5 One-off Patch Conflict Detection and Resolution

Determine whether any currently installed one-off patches conflict with the PSU patch as follows:
In the unzipped directory as in Section 2.1.4.

The below command will check for conflicts in both 12.1 GI home and 12.1 DB homes, as root user:

In case you are applying the patch

$GRID_HOME/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% - analyze

In case you are rolling back the patch

$GRID_HOME/OPatch/opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% - analyze

Note that Oracle proactively provides PSU one-off patches for common conflicts.
Use 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.
When all the one-off patches that you have requested are available at My Oracle Support, proceed with Section 2.3, "Patch Installation".

2.2 OPatch Automation for GI

The Opatch utility has automated the patch application for the Oracle Grid Infrastructure (GI) home and the Oracle RAC database homes. It operates by querying existing configurations and automating the steps required for patching each Oracle RAC database home of same version and the GI home.

The utility must be executed by an operating system (OS) user with root privileges (usually the user root), and 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.

Depending on command line options specified, one invocation of opatchauto can patch the GI home, Oracle RAC database homes, or both GI and Oracle RAC database homes of the same Oracle release version as the patch. You can also roll back the patch with the same selectivity.

Add the directory containing the opatch to the $PATH environment variable. For example:

$ export PATH=$PATH:<GI_HOME>/OPatch

To patch GI home and all Oracle RAC database homes of the same version:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -ocmrf <ocm response file>

To patch only the GI home:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME> -ocmrf <ocm response file>

To patch one or more Oracle RAC database homes:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <oracle_home1_path>,<oracle_home2_path> -ocmrf <ocm response file>

To roll back the patch from the GI home and each Oracle RAC database home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO%

To roll back the patch from the GI home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <path to GI home>

To roll back the patch from the Oracle RAC database home:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <oracle_home1_path>,<oracle_home2_path>

For more information about opatchauto, see My Oracle Support Note 293369.1 OPatch documentation list.

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

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

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 12g Release 1

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:

# <GI_HOME>/OPatch/opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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. Use instructions in Section 2.6 for unmounting ACFS file systems.

3. On the 1st node, apply the patch to the GI Home using the opatchauto command.

As root user, execute the following command:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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. See Section 2.7 for instructions.

6. On the 1st node, apply the patch to the Database home using the opatchauto 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:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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. Use instructions in Section 2.6 for unmounting ACFS file systems.

9. On the 2nd node, apply the patch to GI Home using the opatchauto command.

As root user, execute the following command:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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.

a. On the 2nd node, running the opatchauto command in Step 9 will restart the stack.

11. On the 2nd node, remount ACFS file systems. See Section 2.7 for instructions.

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

13. 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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

As root user, execute the following command:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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 opatchauto command will restart the stack on the local node and restart the Databases on the local node.

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. The same steps can be used even if the GI home is non-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 GI System being patched.

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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

# <GI_HOME>/bin/crsctl stop crs

 
4. Patch the GI home.

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

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME> -nonrolling

this command will take care of stopping and starting GI stack on the local node.

5. Repeat Step 3 and step 4 for all remaining nodes of the cluster.

6. Mount ACFS file systems. See Section 2.7.

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

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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.

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

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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.

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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 using instructions in Section 2.6.

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

Execute the following command on that node in the cluster.

As root user execute:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME> -ocmrf <ocm response file>

5. Remount ACFS file systems on that node. See Section 2.7 for instructions.

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 database -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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -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:

a. As root user, run:

# <GI_HOME>/crs/install/rootcrs.sh -prepatch -nonrolling

# <GI_HOME>/crs/install/rootcrs.sh -postpatch -nonrolling

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

7. Mount ACFS file systems. See Section 2.7.

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:

# opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -ocmrf <ocm response file>

To patch the ACFS software in an Oracle Restart environment:

1. Unmount all ACFS file systems. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

4. Remount ACFS file systems. See Section 2.7 for instructions.

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 apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%ACFS TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%DBWLM TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%RDBMS PSU TRACKING BUG%

Case 6: Patching a Flex Cluster

Follow these instructions if the configuration is a Flex Cluster

First node must be a HUB node.The last node can be either hub/leaf node.

Case 6.1: Patching a Flex cluster with 2 or more HUB nodes

1. Make sure GI Stack is up on the first hub node and at least one other hub node.

2. Make sure stack is up on all the leaf nodes

3. On the local node, unmount the ACFS file systems. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

5.    As root user, execute the following command:

    # opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -ocmrf <ocm response file>

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

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

7. The opatchauto command will restart the stack on the local node and restart the Databases on the local node.

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

Case 6.2: Patching a Flex cluster with Only one HUB nodes

This configuration can be patched only in NON-Rolling fashion.

1. Make sure GI Stack is down on all the leaf nodes

2. On the local node, unmount the ACFS file systems. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

4.    As root user, execute the following command:

    # opatchauto apply <UNZIPPED_PATCH_LOCATION>/%BUGNO% -ocmrf <ocm response file>

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

6. The opatchauto command will restart the stack on the local node and restart the Databases on the local node.

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

2.4 Patch Post-Installation Instructions

After installing the patch, perform the following actions:

1. Remount ACFS file systems. See Section 2.7 for instructions.

2.5 Patch Deinstallation

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

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 %VERSION% and the %VERSION% 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.

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO%

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 anunpatched ACFS\ADVM\OKS driver.

Case D1.1.AB: 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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO%

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

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

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

Case D1.1.2B: 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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

5. On the 1st node, remount ACFS file systems. See Section 2.7 for instructions.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <DATABASE_HOME>

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. Use instructions in Section 2.6 for unmounting ACFS file systems.

9. On the 2nd node, roll back the patch to GI Home using the opatch auto command.

As root user, execute the following command:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

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. See Section 2.7 for instructions.

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 7 through 13 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. Use instructions in Section 2.6 for un-mounting ACFS file systems.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

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

As root user execute:

a. As root user, run:

# <GI_HOME>/crs/install/rootcrs.sh -prepatch -nonrolling

# <GI_HOME>/crs/install/rootcrs.sh -postpatch -nonrolling

7. Mount ACFS file systems. See Section 2.7.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <ORACLE_HOME>

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <Comma separated Oracle home paths>

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.

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <Comma separated Oracle home paths>

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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

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

As root user execute:

a. As root user, run:

# <GI_HOME>/crs/install/rootcrs.sh -postpatch -nonrolling

7. Mount ACFS file systems. See Section 2.7.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

Execute the following command on each node in the cluster.

As root user execute:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <GI_HOME>

5. Remount ACFS file systems on that node. See Section 2.7 for instructions.

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:

# opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO% -oh <Oracle-Restart-home>

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. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

3. Remount ACFS file systems. See Section 2.7 for instructions.

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 nrollback -local -id %BUGNO% -oh <GI_HOME>

Case D6: Rolling Back the Patch from a Flex Cluster

Follow these instructions if the configuration is a Flex Cluster

First node must be a HUB node.The last node can be either hub/leaf node.

Case D6.1: Rolling Back the Patch from a Flex cluster with 2 or more HUB nodes

1. Make sure GI Stack is up on the first hub node and at least one other hub node.

2. Make sure stack is up on all the leaf nodes

3. On the local node, unmount the ACFS file systems. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

5.    As root user, execute the following command:

    # opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO%

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

7. The opatchauto command will restart the stack on the local node and restart the Databases on the local node.

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

Case D6.2: Rolling Back the Patch from a Flex cluster with Only one HUB nodes

This configuration can be patched only in NON-Rolling fashion.

1. Make sure GI Stack is down on all the leaf nodes

2. On the local node, unmount the ACFS file systems. Use instructions in Section 2.6 for unmounting ACFS file systems.

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

4.    As root user, execute the following command:

    # opatchauto rollback <UNZIPPED_PATCH_LOCATION>/%BUGNO%

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

6. The opatchauto command will restart the stack on the local node and restart the Databases on the local node.

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

2.6 Unmounting ACFS File Systems

ACFS file systems can be used by Oracle RAC for hosting software files for the database. It can also be used as a general purpose file system for non-database files. The ACFS file system is managed and administered by the Oracle GRID Infrastructure. So ACFS file systems will be impacted when shutting down the GI stack for patching GI homes.

Shut down the processes using the software files on ACFS and then unmount the ACFS file system.

Note:

Make sure to stop the non-Oracle processes that use ACFS file systems.

If the ACFS file system is used by Oracle database software, then perform Steps 1 and 2.

1. Execute the following command to find the names of the CRS managed ACFS file system resource.

# crsctl stat res -w "TYPE = ora.acfs.type" -p | grep VOLUME

2. Execute the following command to stop the CRS managed ACFS file system resource with the resource name found from Step 1.

As root user execute:

# srvctl stop filesystem -d <volume device path> -n <node to stop file system on>

If the ACFS file system is not used for Oracle Database software and is registered in the ACFS registry, perform the following steps.

1. Execute the following command to find all ACFS file system mount points.

As the root user execute:

# /sbin/acfsutil registry

2. Unmount ACFS file systems found in Step 1.

As the root user execute:

# /bin/umount <mount-point>

Note:

On Solaris operating system use: /sbin/umount.

On AIX operating system, use: /etc/umount.

3. Verify that the ACFS file systems are unmounted. Execute the following command to verify.

As the root user execute:

# /sbin/acfsutil info fs

The previous command should return the following message if there is no ACFS file systems mounted.

"acfsutil info fs: ACFS-03036: no mounted ACFS file systems"

2.7 Mounting ACFS File Systems

If the ACFS file system is used by Oracle database software, then perform Steps 1 and 2.

1. Execute the following command to find the names of the CRS managed ACFS file system resource.

As root user execute:

# crsctl stat res -w "TYPE = ora.acfs.type" -p | grep VOLUME

2. Execute the following command to start and mount the CRS managed ACFS file system resource with the resource name found from Step 1.

As root user execute:

# srvctl start filesystem -d <volume device path> -n <node to start file system on>

If the ACFS file system is not used for Oracle Database software and is registered in the ACFS registry, these file systems should get automatically mounted when the CRS stack comes up. Perform Steps 1 and 2 if it is not already mounted.

1. Execute the following command to find all ACFS file system mount points.

As the root user execute:

# /sbin/acfsutil registry

2. Mount ACFS file systems found in Step 1.

As the root user execute:

# /bin/mount <mount-point>

Note:

On Solaris operating system use: /sbin/mount.

On AIX operating system, use: /etc/mount.

3 Known Issues

For information about OPatch issues, see My Oracle Support Note 293369.1 OPatch documentation list.

For issues documented after the release of this PSUs, see My Oracle Support Note Note 1339140.1 11.2.0.3.X Grid Infrastructure Bundle/PSU Known Issues.

4 References

The following documents are references for this patch.

Note 293369.1 - OPatch documentation list
Note 360870.1 - Impact of Java Security Vulnerabilities on Oracle Products
Note 468959.1 - Enterprise Manager Grid Control Known Issues
Note 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

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 Section 2.6) 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.sh -prepatch

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

# <GI_HOME>/crs/install/roothas.sh -prepatch

3. Patch GI home.

As the GI home owner execute:

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%ACFS TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%DBWLM TRACKING BUG%

$ <GI_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%RDBMS PSU TRACKING BUG%

4. Patch DB home.

As the database home owner execute:

$ <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>

$ <ORACLE_HOME>/OPatch/opatch apply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%

$ <ORACLE_HOME>/OPatch/opatch apply -oh <ORACLE_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%RDBMS PSU TRACKING BUG%

$ <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>

5. 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.sh -postpatch

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

# <GI_HOME>/crs/install/roothas.sh -postpatch

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

8. For each database instance running on the Oracle home being patched, run the datapatch utility as described in next table.

Table 3: Steps to Run the datapatch Utility for Single Tenant Versus Multitenant (CDB/PDB)

Steps	Single Tenant (non-CDB/PDB)	Steps	Multitenant (CDB/PDB)
1	% sqlplus /nolog	1	% sqlplus /nolog
2	SQL> Connect / as sysdba	2	SQL> Connect / as sysdba
3	SQL> startup	3	SQL> startup
4	SQL> quit	4	SQL> alter pluggable database all open;^Foot¹
5	% cd $ORACLE_HOME/OPatch	5	SQL> quit
6	% ./datapatch -verbose	6	% cd $ORACLE_HOME/OPatch
		7	% ./datapatch -verbose

It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable databasePDB_NAME open ) could be substituted to only open certain PDBs in the multitenant database. Doing so will result in the Post Install step only being run on the CDB and opened PDB's. To update a pluggable database at a later date (skipped or newly plugged in), open the database using the alter pluggable database command mentioned previously and rerun the datapatch utility.

The datapatch utility will then run the necessary rollback scripts. An entry will be added to the dba_registry_sqlpatch view reflecting the patch rollback.

Check the following log files in $ORACLE_HOME/sqlpatch/patch ID/ for errors:

patch ID_apply_<database SID>_<CDB name>_<timestamp>.log

where database SID is the database SID, CDB name is the name of the multitenant container database, and timestamp is of the form YYYYMMMDD_HH_MM_SS.

In addition, you can check the log files 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.

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 Section 2.6) 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.sh -prepatch -rollback

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

# <GI_HOME>/crs/install/roothas.sh -prepatch

3. Roll back from GI home.

As the GI home owner execute:

$ <GI_HOME>/OPatch/opatch nrollback -local -id %OCW TRACKING BUG%,¬FS TRACKING BUG%,%RDBMS PSU TRACKING BUG%,ÛWLM TRACKING BUG% -oh <GI_HOME>

4. Roll back from DB home.

As the database home owner execute:

$ <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%/custom/scripts/prepatch.sh -dbhome <ORACLE_HOME>

$ <ORACLE_HOME>/OPatch/opatch nrollback -local -id %OCW TRACKING BUG%,%RDBMS PSU TRACKING BUG% -oh <ORACLE_HOME> 

$ <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%/custom/scripts/postpatch.sh -dbhome <ORACLE_HOME>

5. 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.sh -postpatch -rollback

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

# <GI_HOME>/crs/install/roothas.sh -postpatch

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

8. For each database instance running on the Oracle home being patched, run the datapatch utility as described in next table.

Table 3 Steps to Run the datapatch Utility for Single Tenant Versus Multitenant (CDB/PDB)

Steps	Single Tenant (non-CDB/PDB)	Steps	Multitenant (CDB/PDB)
1	% sqlplus /nolog	1	% sqlplus /nolog
2	SQL> Connect / as sysdba	2	SQL> Connect / as sysdba
3	SQL> startup	3	SQL> startup
4	SQL> quit	4	SQL> alter pluggable database all open;^Foot¹
5	% cd $ORACLE_HOME/OPatch	5	SQL> quit
6	% ./datapatch -verbose	6	% cd $ORACLE_HOME/OPatch
		7	% ./datapatch -verbose

It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable databasePDB_NAME open ) could be substituted to only open certain PDBs in the multitenant database. Doing so will result in the Post Install step only being run on the CDB and opened PDB's. To update a pluggable database at a later date (skipped or newly plugged in), open the database using the alter pluggable databasecommand mentioned previously and rerun the datapatch utility.

The datapatch utility will then run the necessary rollback scripts. An entry will be added to the dba_registry_sqlpatch view reflecting the patch rollback.

Check the following log files in $ORACLE_HOME/sqlpatch/patch ID/ for errors:

patch ID_apply_<database SID>_<CDB name>_<timestamp>.log

where database SID is the database SID, CDB name is the name of the multitenant container database, and timestamp is of the form YYYYMMMDD_HH_MM_SS.

Patching an Oracle RAC Home Installation Manually

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

1. Apply the DB patch.

As the database home owner execute:

$ <ORACLE_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%OCW TRACKING BUG%

$ <ORACLE_HOME>/OPatch/opatch apply -oh <GI_HOME> -local <UNZIPPED_PATCH_LOCATION>/%BUGNO%/%RDBMS PSU TRACKING BUG%

Rolling Back the Patch from an Oracle RAC Home Installation Manually

1. Roll back the DB patch from the database home.

As the database home owner execute:

$ <ORACLE_HOME>/OPatch/opatch nrollback -local -id %OCW TRACKING BUG%,%RDBMS PSU TRACKING BUG% -oh <ORACLE_HOME>

6 Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at https://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 https://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visithttps://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

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.

REFERENCES

NOTE:1594183.1 - Example: Applying a 12c GI PSU With opatchauto in GI Cluster or Standalone Environment
NOTE:1594184.1 - Example: Manually Apply a 12c GI PSU/Interim or DB Interim Patch in Cluster Environment
NOTE:1595408.1 - Example: Manually Apply a 12c GI PSU/Interim or DB Interim Patch in Standalone Environment