Oracle® Database

3.1.1 Applying Database PSU Along Side the Oracle JavaVM Component 12.1.0.2.x Database PSU Patch

From October 2014 onwards, the Oracle JavaVM Component 12.1.0.2.x Database PSU patch is also available as a separate patch. This patch is not Oracle RAC Rolling Installable. For customers wanting to install both patches together during a single downtime window, follow the various Patching Options listed in the My Oracle Support Document 1929745.1 - Oracle Recommended Patches -- "Oracle JavaVM Component Database PSU" (OJVM PSU) Patches.

3.1.2 Environments with Grid Infrastructure

If you are installing the PSU to an environment that has a Grid Infrastructure home, note the following:

• Grid Infrastructure PSU 12.1.0.2.5 Patch 21523234 should be applied to the Grid Infrastructure home and Database home using the readme instructions provided with the patch.

3.1.3 Environment Checks

1. Ensure that the $PATH definition has the following executables: make, ar, ld, and nm.

   The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin, in which case you can set your PATH definition as follows:

   export PATH=$PATH:/usr/ccs/bin
   

3.1.4 One-off Patch Conflict Detection and Resolution

For an introduction to the PSU one-off patch concepts, see "Patch Set Updates Patch Conflict Resolution" in My Oracle Support Document 854428.1 Patch Set Updates for Oracle Products.

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

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

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

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

Or, use the following steps to manually discover conflicts and resolutions:

1. Determine whether any currently installed one-off patches conflict with the PSU patch as follows:

   unzip p21359755_12102_<platform>.zip
   cd 21359755
   opatch prereq CheckConflictAgainstOHWithDetail -ph ./
   

2. The report will indicate the patches that conflict with PSU 21359755 and the patches for which PSU 21359755 is a superset.

   Note that Oracle proactively provides PSU 12.1.0.2.5 one-off patches for common conflicts.

3. Use My Oracle Support Document 1321267.1 Database 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.

4. When all the one-off patches that you have requested are available at My Oracle Support, proceed with Section 3.2, "Patch Installation Instructions".

3.3.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 3.1.4, "One-off Patch Conflict Detection and Resolution".

3.3.2 Loading Modified SQL Files into the Database

The following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.

Datapatch is run to complete the post-install SQL deployment for the PSU. For further details about Datapatch, including Known Issues and workarounds to common problems, see: Database 12c Post Patch SQL Automation (Doc ID 1585822.1).

1. For each separate database running on the same shared Oracle home being patched, run the datapatch utility as described in Table 2.

   Table 2 Steps to Run the Datapatch Utility for Standalone DB Versus Single/Multitenant (CDB/PDB) DB

   Steps	Standalone DB	Steps	Single/Multitenant (CDB/PDB) DB
   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 1
   5	% cd $ORACLE_HOME/OPatch	5	SQL> quit
   6	% ./datapatch -verbose	6	% cd $ORACLE_HOME/OPatch
   		7	% ./datapatch -verbose

   
   

   ^Footnote 1 It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable database PDB_NAME open ) could be substituted to only open certain PDBs in the single/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. See My Oracle Support Document 1935365.1 Multitenant Unplug/Plug Best Practices for more information about the procedure for unplugging/plugging with different patch releases (in both directions).

   The datapatch utility will then run the necessary apply scripts to load the modified SQL files into the database. An entry will be added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify the Status for the APPLY is "SUCCESS". For any other status, refer to the following My Oracle Support note for additional information and actions: Document 1609718.1 Datapatch Known Issues.

2. Check the following log files in $ORACLE_BASE/cfgtoollogs/sqlpatch/21359755/<unique patch ID> for errors:

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

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

4.2.1 Run the datapatch Utility

Datapatch is run to complete the post-deinstall SQL deployment for the PSU. For further details about Datapatch, including Known Issues and workarounds to common problems, see: Database 12c Post Patch SQL Automation (Doc ID 1585822.1).

Follow these steps:

1. For each separate database running on the same shared Oracle home being patched, run the datapatch utility as described in Table 3. If this is Oracle RAC, run datapatch on only one instance.

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

   Steps	Standalone DB	Steps	Single/Multitenant (CDB/PDB) DB
   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 1
   5	% cd $ORACLE_HOME/OPatch	5	SQL> quit
   6	% ./datapatch -verbose	6	% cd $ORACLE_HOME/OPatch
   		7	% ./datapatch -verbose

   
   

   ^Footnote 1 It is recommended the Post Install step be run on all pluggable databases; however, the following command (SQL> alter pluggable database PDB_NAME open ) could be substituted to only open certain PDBs in the single/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. See My Oracle Support Document 1935365.1 Multitenant Unplug/Plug Best Practices for more information about the procedure for unplugging/plugging with different patch releases (in both directions).

   The datapatch utility will then run the necessary rollback scripts. An entry will be added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify the Status for the ROLLBACK is "SUCCESS". For any other status, refer to the following My Oracle Support note for additional information and actions: Document 1609718.1 Datapatch Known Issues.

2. Check the following log files in $ORACLE_BASE/cfgtoollogs/sqlpatch/21359755/<unique patch ID> for errors:

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

4.2.2 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;
RMAN> UPGRADE CATALOG;