Oracle® Database

This patch is cumulative and includes the Database CPU program security content.

Beginning with 19.24 Jul2024, the OJVMRU patch contains the OJVM DST Time Zone patches. Applying this OJVM Release Update does not change the OJVM DST version in any of your databases. The OJVM DST patches are only copied into $ORACLE_HOME/javavm/lib and $ORACLE_HOME/javavm/admin directories and no OJVM DST upgrade is performed. You can decide to upgrade the OJVM DST version in your database to a newer OJVM DST version independently of applying the OJVMRU at any time. Be aware that this incurs downtime.

This OJVMRU contains the OJVM DST V43 and the prior versions.

If you plan to adjust the OJVM DST version in your databases, Oracle recommends adjusting it to the latest available OJVM DST version. Then follow the instructions in the Oracle 19c Oracle Database Upgrade Guide.

For more information on various DST patch releases, refer to My Oracle Support document 412160.1 Primary Note DST FAQ: Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches.

Before you install or deinstall the patch, ensure that you meet the following requirements. For an Oracle RAC environment, meet these prerequisites on each of the nodes.

1. Read My Oracle Support Document 1929745.1 Oracle Recommended Patches -- "Oracle JavaVM Component Database PSU and Update" (OJVM PSU and OJVM Update) Patches.

2. Ensure that the Oracle Database on which you are installing the patch or from which you are rolling back the patch is Oracle Database Release 19c.

3. You must use the OPatch utility version 12.2.0.1.42 or later to apply this patch. Oracle recommends that you use the latest released OPatch version for 12.2, which is available for download from My Oracle Support patch 6880880 by selecting 'Opatch 12.2.0.1.0' release.

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

4. Ensure that you set the ORACLE_HOME environment variable to the Oracle home of the Oracle Database.

5. [Unix-specific] 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.

6. Ensure that you verify the Oracle Inventory because OPatch accesses it to install the patches. To verify the inventory, run the following command. If the command displays some errors, then contact Oracle Support and resolve the issue.

   $ opatch lsinventory
   

7. (Only for Installation) Maintain a location for storing the contents of the patch ZIP file. In the rest of the document, this location (absolute path) is referred to as PATCH_TOP_DIR. Extract the contents of the patch ZIP file to the location (PATCH_TOP_DIR) you have created above. To do so, run the following command:

   $ unzip -d <PATCH_TOP_DIR> p36414915_190000_<PLATFORM_NAME>.zip
   

8. (Only for Installation) Determine whether any currently installed interim patches conflict with the patch as shown below:

   $ cd <PATCH_TOP_DIR>/36414915
   $ opatch prereq CheckConflictAgainstOHWithDetail -ph ./
   

   The report will indicate the patches that conflict with this patch and the patches for which the current patch is a superset.

   Note:

   When OPatch starts, it validates the patch and ensures that there are no conflicts with the software already installed in the ORACLE_HOME. OPatch categorizes conflicts into the following types:

   • Conflicts with a patch already applied to the ORACLE_HOME, that is a subset of the patch you are trying to apply - In this case, continue with the patch installation because the new patch contains all the fixes from the existing patch in the ORACLE_HOME. The subset patch will automatically be rolled back prior to the installation of the new patch.

   • Conflicts with a patch already applied to the ORACLE_HOME - In this case, stop the patch installation and contact Oracle Support.

9. Ensure that you shut down all the services running from the Oracle home.

   For a Non Oracle RAC environment, shut down all databases and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator's Guide.

   If you can apply this patch to an Oracle RAC environment using an out-of-place approach, follow the instructions described for an Oracle RAC Rolling installation in Note 2217053.1. Shutdown of database services may not be required for this case. Otherwise for an Oracle RAC environment, shut down all the services (database, ASM, listeners, nodeapps, and CRS daemons) running from the Oracle home on all the nodes you want to patch. After all nodes are patched, start all services. OPatch is used on only one node at a time.

To install the patch, follow these steps.

1. Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands:

   $ cd <PATCH_TOP_DIR>/36414915
   

2. Install the patch by running the following command:

   $ opatch apply
   

   If apply fails for make target jox_refresh_knlopt when applying the patch to the database home, see Issue #1 in Known Issues for more information.

3. Verify whether the patch has been successfully installed by running the following command:

   $ opatch lsinventory
   

4. Start the services from the Oracle home.

5. If there are errors, see Known Issues.

Perform the following postinstallation steps described in Loading Modified SQL Files Into the Database.

To perform the postinstallation, follow these steps:

1. The following steps load modified SQL files into the database.

   Datapatch is run to complete the post-install SQL deployment for the Update. For further details about Datapatch, including Known Issues and workarounds to common problems, see: Datapatch: Database 12c or later 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 1.

      Table 1 Steps to Run the datapatch Utility for Non-CDB Database Versus Single or Multitenant (CDB or PDB) Database

      Steps	Non-CDB Database	Steps	Single or Multitenant (CDB or PDB) Database
      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 that the post-installation step be run on all pluggable databases. However, the command, SQL> ALTER PLUGGABLE DATABASE <pdb_name> OPEN, could be substituted to only open certain pluggable databases (PDBs) in the single or multitenant database. Doing so results in the post-installation step only being run on the multitenant container database (CDB) and opened PDBs. 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 or plugging with different patch releases (in both directions).

      The Datapatch utility runs the necessary apply scripts to load the modified SQL files into the database. An entry is added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify that the Status for APPLY is SUCCESS. For any other Status, refer to My Oracle Support Document 2335899.2 Troubleshooting Assistant: 12c Datapatch Issues.

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

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

2. After installing the SQL portion of the patch, some packages could become INVALID. This will get recompiled upon access or you can run utlrp.sql to get them back into a VALID state.

   cd $ORACLE_HOME/rdbms/admin
   sqlplus /nolog
   SQL> CONNECT / AS SYSDBA
   SQL> @utlrp.sql
   

3. If there are errors, see Known Issues.

You must execute the steps in Postinstallation for any new database. There are no actions required for databases that have been upgraded.

Ensure to follow the Prerequisites as described in Prerequisites. To deinstall the patch, follow these steps. For an Oracle RAC environment, perform these steps on each node of the cluster, one at a time:

1. Deinstall the patch by running the following command:

   $ opatch rollback -id 36414915
   

2. Start the services from the Oracle home.

3. Ensure that you verify the Oracle Inventory and compare the output with the one run before the patch installation 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
   

Perform the following post deinstallation steps described in Loading Modified SQL Files Into the Database.

The following steps load modified SQL files into the database.

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 Non-CDB Database Versus Single or Multitenant (CDB or PDB) Database

   Steps	Non-CDB Database	Steps	Single or Multitenant (CDB or PDB) Database
   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 that the post-installation step be run on all pluggable databases. However, the command, SQL> ALTER PLUGGABLE DATABASE <pdb_name> OPEN, could be substituted to only open certain pluggable databases (PDBs) in the single or multitenant database. Doing so results in the post-installation step only being run on the multitenant container database (CDB) and opened PDBs. 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 or plugging with different patch releases (in both directions).

   The Datapatch utility runs the necessary rollback scripts. An entry is added to the dba_registry_sqlpatch view reflecting the patch application. In the dba_registry_sqlpatch view, verify that the Status for ROLLBACK is SUCCESS. For any other Status, refer to My Oracle Support Document 2335899.2 Troubleshooting Assistant: 12c Datapatch Issues.

2. Check the following log files in $ORACLE_HOME/sqlpatch/ 36414915/ for errors:

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

3. After installing the SQL portion of the patch, some packages could become INVALID. This will get recompiled upon access or you can run utlrp.sql to get them back into a VALID state.

   cd $ORACLE_HOME/rdbms/admin
   sqlplus /nolog
   SQL> CONNECT / AS SYSDBA
   SQL> @utlrp.sql
   

4. If there are errors, see Known Issues.

For information about OPatch issues, see My Oracle Support Document 293369.1 Primary Note For OPatch.

For issues documented after the release of this patch, see My Oracle Support Document 19202407.9 Oracle Database 19c Release Update July 2024 Known Issues.

Other issues are as follows.

Issue 1

Problem: An ORA-04068 error may appear in the Database alert log file when datapatch is run.

During a successful run of the datapatch tool with no errors indicated, an ORA-04068 error may appear in the Database alert log file:

ORA-04068: existing state of packages has been discarded

Workaround: This is a retryable error in datapatch itself. If a patch installation receives it, then datapatch will automatically retry the operation once, before reporting it as a failure. The fact that datapatch did not report the retry and ran successfully with no errors confirms that the patch was successfully installed, and that another Oracle background process received the error. The ORA-04068 error should be ignored as long as datapatch runs successfully with no errors indicated (possibly after an automatic retry).