Oracle 11g Linux Patch 34085652: OJVM PATCH SET UPDATE 11.2.0.4.220719 官方补丁说明
Patch 34085652 – Oracle JavaVM Component 11.2.0.4.220719 Database PSU
This document describes how you can install Patch 34085652 – Oracle JavaVM Component 11.2.0.4.220719 Database PSU on your Oracle Database 11g Release 2 (11.2.0.4.0).
From January 2019 onward, the OJVM now only supports JDK7 for security compliance. Ensure that, if there are applications with an OJVM dependency, that they are compatible with JDK7.
This patch is not Oracle RAC Rolling installable. However, starting with the Jan2017 OJVM PSU patchset for 11.2.0.4, the OJVM PSU may be installed in a “Conditional Rolling Install” fashion for the following use cases:
- No OJVM usage
- OJVM used by non-critical jobs and programs
- OJVM used by critical functions isolated as services
- OJVM used extensively, not isolated, and downtime is tolerated
- OJVM used by critical functions and minimal downtime is required
See My Oracle Support Document 2217053.1 for more details.
This patch is Database Vault installable. Review My Oracle Support Document 1195205.1 for details on how to apply this patch to a Database Vault environment.
This patch is not Data Guard Standby First Installable.
This patch requires any one of the following Oct2014 or greater to be already installed prior to installing this patch:
- Database PSU 11.2.0.4.4 (Oct2014)
- Database SPU 11.2.0.4 (CPUOct2014)
- Database patch for Exadata 11.2.0.4.12 (Oct2014)
This document is accurate at the time of release. For any changes and additional information regarding this patch, see these related documents that are available at My Oracle Support (http://support.oracle.com/
):
- Document 2867905.1 Oracle JavaVM Component 11.2.0.4.220719 Database PSU Known Issues
This document includes the following sections:
- Patch Information
- Prerequisites
- Installation
- Postinstallation
- Post Installation Instructions for Databases Created or Upgraded after Installation of OJVM PSU in the Oracle Home
- Deinstallation
- Post Deinstallation
- Known Issues
- Upgrade Mode for Oracle RAC Database
- Documentation Accessibility
1.1 Patch Information
From CPUJan2016 onwards, the 5th digit of the version number will be changed to reflect the release date in the format YYMMDD. See My Oracle Support Document 2061926.1 for more information.
This patch is cumulative and includes the Database 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-1 Installation Types and Security Content
1.2 Prerequisites
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.
- Read My Oracle Support Document 1929745.1 Oracle Recommended Patches — “Oracle JavaVM Component Database PSU and Update” (OJVM PSU and OJVM Update) Patches.
- Ensure that the Oracle Database on which you are installing the patch or from which you are rolling back the patch is Oracle Database 11g Release 2 (11.2.0.4.0).
- Ensure that one of the following Oct2014 (or greater) patches is already installed prior to installing this patch:
- Database PSU 11.2.0.4.4 (Oct2014) (Patch number: 19121551)
- Database SPU 11.2.0.4 (CPUOct2014)
- Database patch for Exadata 11.2.0.4.12 (Oct2014)
- You must use the OPatch utility version 11.2.0.3.34 or later to apply this patch. Oracle recommends that you use the latest released OPatch version for 11.2, which is available for download from My Oracle Support patch 6880880 by selecting the 11.2.0.0.0 release.For information about OPatch documentation, including any known issues, see My Oracle Support Document 293369.1 OPatch documentation list.
- Ensure that you set the
ORACLE_HOME
environment variable to the Oracle home of the Oracle Database. - Ensure that the
$PATH
definition has the following executables:make
,ar
,ld
andnm
. The location of these executables depends on your operating system. On many operating systems, they are located in/usr/ccs/bin
. - 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
- (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> p34085652_112040_<PLATFORM_NAME>.zip - (Only for Installation) Determine whether any currently installed interim patches conflict with this patch 34085652 as shown as follows:$ cd <PATCH_TOP_DIR>/34085652 $ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ The report will indicate the patches that conflict with this patch and the patches for which the current 34085652 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 theORACLE_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 Services.
- Conflicts with a patch already applied to the
- 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.For an Oracle RAC environment, shut down all the services (database) 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.
1.3 Installation
To install the patch, follow these steps.
- 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>/34085652
- Install the patch by running the following command:$ opatch apply
- Verify whether the patch has been successfully installed by running the following command:$ opatch lsinventory 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. - Start the services from the Oracle home after all the nodes are patched.
- If there are errors, see Known Issues.
1.4 Postinstallation
Beginning with the Jan2017 OJVM PSU patchset for 11.2.0.4 and for 12.1.0.2, Oracle Development is relaxing the requirement to restart the database in upgrade mode. Prior to the Jan2017 OJVM PSU patchsets, the installation of the OJVM PSU patchset into the $ORACLE_HOME
binaries was required to be followed by a postinstallation of the OJVM PSU patchset into each associated database while in restricted startup upgrade mode.
Beginning with the Jan2017 OJVM PSU patchset for 11.2.0.4 and for 12.1.0.2, Oracle Development is defining a few very specific situations and prerequisites where the OJVM PSU patchset can be postinstalled into each database while the database remains in unrestricted startup mode. If your business needs are compatible with the legacy requirement to restart each database into restricted startup upgrade mode, then Oracle recommends that you continue to postinstall the OJVM PSU patchset into each database while it is in restricted startup upgrade mode. In this case, you should skip the next two paragraphs, and continue to Loading Modified SQL Files Into the Database.
The very specific situations and prerequisites where the OJVM PSU patchset can be postinstalled into each database in unrestricted “startup” mode are defined and detailed in My Oracle Support Document 2217053.1, RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU” (OJVM PSU) Patches. At a high level, the ability to use unrestricted startup mode involves a two-part decision tree for OJVM PSU for each database; is OJVM installed and is OJVM used? The Appendix to My Oracle Support Document 2217053.1 provides detailed procedures for each specific situation where it is possible to use unrestricted startup mode.
There are pros and cons to each of the very specific situations and prerequisites are discussed in My Oracle Support Document 2217053.1. Therefore, Oracle recommends that the legacy requirement to restart each database into restricted startup upgrade mode be observed when possible.
1.4.1 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.
- Install the SQL portion of the patch by running the following command for a single instance environment.cd $ORACLE_HOME/sqlpatch/34085652 sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> startup upgrade SQL> @postinstall.sql SQL> shutdown SQL> startup For an Oracle RAC environment, reload the packages on one of the nodes using the following commands. Make sure no other instance of the database is up on the remote nodes.cd $ORACLE_HOME/sqlpatch/34085652 sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP SQL> alter system set cluster_database=false scope=spfile; SQL> SHUTDOWN SQL> STARTUP UPGRADE SQL> @postinstall.sql SQL> alter system set cluster_database=true scope=spfile; SQL> SHUTDOWN SQL> STARTUP
- 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 - If there are errors, see Known Issues.
1.5 Post Installation Instructions for Databases Created or Upgraded after Installation of OJVM PSU in the Oracle Home
You must execute the steps in Postinstallation for any new database or upgraded database.
1.6 Deinstallation
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 any one of the nodes:
- Deinstall the patch by running the following command:$ opatch rollback -id 34085652 If rollback fails for make target
jox_refresh_knlopt
when deinstalling the patch from the database home, see Issue #1 in Known Issues for more information. - Start the services from the Oracle home.
- 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
1.7 Post Deinstallation
Beginning with the Jan2017 OJVM PSU patchset for 11.2.0.4 and for 12.1.0.2, Oracle Development is relaxing the requirement to restart the database in upgrade mode. Prior to the Jan2017 OJVM PSU patchsets, the deinstallation of the OJVM PSU patchset from the $ORACLE_HOME
binaries was required to be followed by a post deinstallation of the OJVM PSU patchset from each associated database while in restricted “startup upgrade” mode.
Beginning with the Jan2017 OJVM PSU patchset for 11.2.0.4 and for 12.1.0.2, Oracle Development is defining a few very specific situations and prerequisites where the OJVM PSU patchset can be post deinstalled from each database while the database remains in unrestricted startup mode. If your business needs are compatible with the legacy requirement to restart each database into restricted startup upgrade mode, then Oracle recommends that you continue to post deinstall the OJVM PSU patchset from each database while it is in restricted startup upgrade mode. In this case, you should skip the next two paragraphs, and continue to Loading Modified SQL Files Into the Database.
The very specific situations and prerequisites where the OJVM PSU patchset can be post deinstalled from each database in unrestricted startup mode are defined and detailed in My Oracle Support Document 2217053.1, RAC Rolling Install Process for the “Oracle JavaVM Component Database PSU” (OJVM PSU) Patches. At a high level, the ability to use unrestricted startup mode involves a two-part decision tree for OJVM PSU for each database; is OJVM installed and is OJVM used? The Appendix to My Oracle Support Document 2217053.1 provides detailed procedures for each specific situation where it is possible to use unrestricted startup mode.
There are pros and cons to each of the very specific situations and prerequisites are discussed in My Oracle Support Document 2217053.1. Therefore, Oracle recommends that the legacy requirement to restart each database into restricted startup upgrade mode be observed when possible.
1.7.1 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.
- Install the SQL portion of the patch by running the following command for a single instance environment.cd $ORACLE_HOME/sqlpatch/34085652 sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> startup upgrade SQL> @postdeinstall.sql SQL> shutdown SQL> startup For an Oracle RAC environment, reload the packages on one of the nodes using the following commands. Make sure no other instance of the database is up on the remote nodes.cd $ORACLE_HOME/sqlpatch/34085652 sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP SQL> alter system set cluster_database=false scope=spfile; SQL> SHUTDOWN SQL> STARTUP UPGRADE SQL> @postdeinstall.sql SQL> alter system set cluster_database=true scope=spfile; SQL> SHUTDOWN SQL> STARTUP
- 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 - If there are errors, see Known Issues.
1.8 Known Issues
For information about OPatch issues, see My Oracle Support Document 293369.1 OPatch documentation list.
For issues documented after the release of this patch, see My Oracle Support Document 2867905.1 Oracle JavaVM Component 11.2.0.4.220719 Database PSU Known Issues.
The known issues are as follows.Issue 1
Relink fails for make target jox_refresh_knlopt
when applying or rolling back this patch to or from a database home.
See My Oracle Support Document 1933203.1 Relink Fails for make target ‘jox_refresh_knlopt’ with “Oracle JavaVM Component Database PSU” Patch for more information.Issue 2
There could be errors seen if postinstallation or postdeinstallation steps have not been run correctly. This happens when the Java system classes.bin
in the database does not match that of the oracle executable.
To recover from this issue, complete the postinstallation (see Postinstallation) or postdeinstallation (see Post Deinstallation), which will load updated classes.bin
into memory and resolves the inconsistency.Issue 3
If Oracle Database Vault is enabled, the following error can occur during the execution of the Post Installation or Deinstallation steps:
initjvmaux.drop_sros(); EXECUTE IMMEDIATE 'create or replace java system'; ... ORA-01031: insufficient privileges ORA-06512: at "SYS.INITJVMAUX", line 535 ORA-06512: at line 3
To recover from this issue, see the following My Oracle Support Document 1935120.1 ORA-01031 during Post Install / De-install for Database PSU or OJVM PSUIssue 4
Problem: While applying Patch 34085652, the following failed messages appear:
Workaround: Change the permission of
README.txt
to644
.See the following My Oracle Support Document 2154538.1 Error When Applying OJVM Patch - Cannot copy file from 'README.txt' for more information.Issue 5
Un-supported APIs: The following JDK7 APIs are not supported with this PSU update.
sun.nio.fs.UnixNativeDispatcher.futimes
sun.nio.fs.UnixNativeDispatcher.fdopendir
sun.nio.fs.UnixNativeDispatcher.fstatat0
sun.nio.fs.UnixNativeDispatcher.openat0
sun.nio.fs.UnixNativeDispatcher.open0
sun.nio.fs.UnixNativeDispatcher.unlinkat0
sun.nio.fs.LinuxWatchService.inotifyInit
sun.nio.fs.LinuxWatchService.inotifyAddWatch
sun.nio.fs.LinuxWatchService.inotifyRmWatch
sun.nio.fs.LinuxWatchService.eventOffsets
sun.nio.fs.LinuxWatchService.eventSizeIssue 6Problem:Client tools loadjava, dropjava, ojvmjava, ojvmtc fail after the update.
Workaround:The Oracle JVM client tools shipped with Database 11.2.0.4 work with JDK5 that is installed in ORACLE_HOME. With this update, these client tools are updated to work with JDK7. Oracle recommends that the client JDK, installed in ORACLE_HOME, be updated to JDK7 - see My Oracle Support Document 2366614.1. If there is a requirement to have the client tools continue to work with JDK5, then follow the steps below.
cd $ORACLE_HOME/javavm/install/sbs perl sbs_installer.plIf this OJVM PSU is being rolled back, then follow the steps below to restore the changes.
cd $ORACLE_HOME/javavm/install/sbs perl roll_back.plProblem: Exception in thread "main"java.lang.UnsupportedClassVersionError: Bad version number in ".classfile" error encountered when Java is subsequently used after the successful installation of this patch.
Workaround: The Oracle JVM client tools shipped with Database 11.2.0.4 work with JDK5 that is installed in ORACLE_HOME. With this update, these client tools are updated to work with JDK7.
In order to avoid this error, then follow the steps below. These steps may be performed either after the subject patch is installed, or before the subject patch is installed.
After the subject patch is installed:
cd $ORACLE_HOME/javavm/install/sbs perl sbs_installer.plOR
Before the subject patch is installed:
<patch staging area>/28790660/files/javavm/install/sbs/sbs_installer.plIn the same way, if this OJVM PSU is being rolled back, then follow the steps below to restore the changes.
cd $ORACLE_HOME/javavm/install/sbs perl roll_back.plOR
<patch staging area>/28790660/files/javavm/install/sbs/roll_back.pl1.9 Upgrade Mode for Oracle RAC Database
Perform the steps in the following sections to upgrade an Oracle RAC database:
1.9.1 Starting the Oracle RAC Database in Upgrade Mode
Perform the folowing steps to start the Oracle RAC database in upgrade mode.
- Connect to SQL*Plus as
sysdba
on any of the nodes. - Execute the following command:SQL> alter system set cluster_database=false scope=spfile;
- Stop the database using the
srvctl
command:$ srvctl stop database -d <dbname> - Connect to SQL*Plus on one of the nodes as
sysdba
. - Start the database in upgrade mode:SQL> startup upgrade
1.9.2 Restoring an Oracle RAC Database to Normal Mode
Perform the following steps to start the Oracle RAC database in upgrade mode:
- Connect to SQL*Plus as
sysdba
on the node where the instance was started in upgrade mode. - Execute the following command:SQL> alter system set cluster_database=true scope=spfile;
- Shut down the database:SQL> shutdown
- Start the database using the
srvctl
command:$ srvctl start database -d <dbname>
1.10 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 that have purchased support 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.