This chapter describes important last-minute features and changes not included in Oracle Database Documentation Library for this release of Oracle Database 12c Release 1 (12.1.0.2).
This chapter contains the following sections:
Section 2.1, "Compatibility, Upgrading, Downgrading, and Installation"
Section 2.2, "Features Not Available or Restricted in This Release of Oracle Database 12.1.0.2"
Section 2.3, "Deprecated and Desupported Features for Oracle Database"
Section 2.4, "Data Analytics Accelerators on SPARC for Oracle Database Overview"
Section 2.5, "Database Security"
Section 2.6, "Multitenant Container Database"
Section 2.7, "Application Continuity"
Section 2.8, "Oracle Application Express"
Section 2.9, "Oracle Automatic Storage Management (Oracle ASM)"
Section 2.10, "Oracle Database Vault"
Section 2.11, "Oracle Enterprise Manager Database Express (EM Express)"
Section 2.12, "Oracle Grid Infrastructure for a Cluster"
Section 2.13, "Oracle Multimedia"
Section 2.14, "Oracle ODBC Driver"
Section 2.15, "Oracle SQL Developer"
Section 2.16, "Oracle Spatial and Graph"
For late-breaking updates and best practices about pre-upgrade, post-upgrade, compatibility, and interoperability discussions, see Note 1462240.1 on My Oracle Support (at https://support.oracle.com) that links to the "Upgrade Companion" web site.
Caution:
After installation is complete, do not manually remove or runcron jobs that remove /tmp/.oracle or /var/tmp/.oracle directories or their files while Oracle software is running. If you remove these files, then Oracle software can encounter intermittent hangs. Oracle Grid Infrastructure for a cluster installations fail with the following error:
CRS-0184: Cannot communicate with the CRS daemon.
Pre-upgrade fails when upgrading from 12.1.0.1 SE or SE1 to 12.1.0.2 SE2 (reference Bug 21390522).
Workaround: Apply the one-off patch for bug 18718327 prior to upgrade.
Oracle Label Security (OLS) upgrade and downgrade scripts are not shipped in 12.1.0.1 SE or SE1 database (reference Bug 21497495). As a result, OLS packages are not correctly recompiled while executing catrelod.sql after the downgrade process back to 12.1.0.1 SE or SE1. The OLS packages still refer to objects introduced as part of the upgrade to 12.1.0.2 SE2.
This can result in the ORA-06508 error when executing utlrp.sql after catrelod.sql in 12.1.0.1 SE or SE1.
Workaround: Apply patch 21076681 to the 12.1.0.1 SE or SE Oracle home prior to downgrading back from 12.1.0.2 SE2.
During upgrade of Oracle Database from release 12.1.0.1 to release 12.1.0.2 using Oracle Database Upgrade Assistant (DBUA), the following error is returned (reference Bug 21449004):
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
If you upgrade from release 12.1.0.1 SE or SE1 to release 12.1.0.2 SE2 and then downgrade from 12.1.0.2 SE2 back to 12.1.0.1 SE or SE1, Oracle Multimedia may become invalid (reference Bug 21445944).
Workaround: Invoke md/admin/loce121.sql from the 12.1.0.2 ORACLE_HOME as part of the downgrade process before executing the reload scripts.
Release 12.1.0.1 Patch Set Update PSU4 is required in order to downgrade a multitenant container database (CDB) or pluggable database (PDB). Patch Set Updates are available for download on My Oracle Support (MOS) at https://support.oracle.com/. See MOS Note 756671.1 to obtain the latest Patch Set Update and any required set of additional fixes (reference Bug 18826367).
A problem can be encountered after upgrading a multitenant container database (CDB) from 12.1.0.1 to 12.1.0.2, if there exists a common user in the CDB that was altered to have a default tablespace in ROOT, and if there is no tablespace with that name in a given pluggable database (for example, P1) (reference Bug 19174942). When a new pluggable database (for example, P2) is cloned from the pluggable database (PDB) P1, it causes PDB P2 to open with a warning and in restricted mode, which is not expected behavior. There is at least one row when issuing the following query on the PDB_PLUG_IN_VIOLATIONS view in ROOT:
SELECT MESSAGE, ACTION FROM PDB_PLUG_IN_VIOLATIONS WHERE NAME = 'P2' AND TYPE = 'ERROR' AND STATUS = 'PENDING' AND CAUSE = 'Sync Failure';
Determine the default tablespace for each common user by querying the DBA_USERS view in ROOT, and ensure that each of the tablespaces exists in the PDB. If a particular tablespace does not exist in the PDB, execute the following steps:
Open the PDB.
Determine the default tablespace for the common user in the PDB by querying the DBA_USERS view in the PDB (this is needed later in Step 5).
Create the missing tablespaces in the PDB.
Close and reopen the PDB.
In the PDB, issue the ALTER USER command to change the default tablespace of the common user in the PDB back to the original tablespace as noted in Step 2.
Drop the tablespaces from the PDB.
Oracle Enterprise Manager rolling upgrade requires that the RDBMS pre-upgrade tool checks be performed on the physical standby database, which is upgraded before the primary database (reference Bug 19195895). However, these tool checks are prevented on a physical standby database that is opened in read-only mode.
Prior to running the upgrade, download the latest 12.1.0.2 pre-upgrade tool in MOS Note 884522.1 from My Oracle Support (MOS) at https://support.oracle.com/.
As part of release 12.1.0.2, versioning of data types that could be attributes of Oracle object types have been introduced. Because of this feature, cross-version replication between release 12.1.0.1 and release 12.1.0.2 databases might be affected resulting in the ORA-26656 error.
If any user-defined object types contain attributes of DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, BINARY_FLOAT, BINARY_DOUBLE, NCHAR, NVARCHAR2, NCLOB, ANYDATA, etc., you must apply the mandatory Patch Set Update for Bug 18038108 to all release 12.1.0.1 instances.
After release 12.1.0.2 is downgraded to release 12.1.0.1 and the utlrp.sql script is executed, it is possible for the MDSYS.SDO_COORD_OPS_TRIGGER trigger to be invalid (reference Bug 18900492). This has no known side effects. The MDSYS.SDO_COORD_OPS_TRIGGER trigger becomes valid on the first use of the trigger. Or, you can execute the ALTER TRIGGER MDSYS.SDO_COORD_OPS_TRIGGER COMPILE statement as DBA to make it valid.
If you upgrade an Oracle ASM instance from release 11.1.0.7 to release 12.1.0.x, then downgrade to release 11.1.0.7, and then try to upgrade to release 12.1.0.x again, Oracle ASM may not get upgraded (reference Bug 14756008). Follow the manual steps to upgrade the Oracle ASM instance found in the Oracle Grid Infrastructure Installation Guide for Linux.
When a node crash occurs during an upgrade, a -force upgrade can be performed to upgrade a partial cluster minus the unavailable node (reference Bug 12933798).
After performing a -force upgrade, the node list of the Grid home in inventory is not in sync with the actual Oracle Grid Infrastructure deployment. The node list still contains the unavailable node. Because the node list in inventory is incorrect, the next upgrade or node addition, and any other Oracle Grid Infrastructure deployment, fails.
After performing a -force upgrade, manually invoke the following command as a CRS user:
$GRID_HOME/oui/bin/runInstaller -updateNodeList "CLUSTER_NODES={comma_separated_alive_node_list}" ORACLE_HOME=$GRID_HOME CRS=true
When downgrading from release Oracle Database 12c to 11.2.0.2, you must apply patch 11811073 for release 11.2.0.2 which provides an updated version of catrelod.sql. This patch can be applied to the 11.2.0.2 home anytime before attempting to reload the PL/SQL packages from the 11.2.0.2 home by running the catrelod.sql.
When downgrading from release Oracle Database 12c to 11.2.0.3 or 11.2.0.2 and if SQLJ types are present, the following ORA-00600 error may occur when running utlrp.sql to recompile invalid objects after catrelod.sql is run (reference Bug 16230705):
ORA-00600: internal error code, arguments: [16211]
You must apply the fix in the original release (11.2.0.2 or 11.2.0.3) before executing utlrp.sql (after @catrelod.sql) in order to avoid this error.
The following is a list of components that are not available or are restricted in this release of Oracle Database 12c Release 1 (12.1.0.2):
Interval partitioning is not supported with XMLIndex. XMLIndex only supports range, list and hash partitioning schemes.
Only rolling upgrades to Oracle Grid Infrastructure release 12.1.0.2 are supported when upgrading Oracle Grid Infrastructure clusters that are operating in Oracle Flex Cluster mode. The Oracle Clusterware stack on all nodes in the cluster (Hub Node and Leaf Node) needs to be up and running prior to the upgrade. For environments operating in Standard cluster mode, rolling and non-rolling upgrades are supported.
Database Resident Connection Pooling (DRCP) is not supported with Transaction Guard.
XStream does not support LONG columns in databases with varying width multibyte character sets.
Java Database Connectivity (JDBC) thin driver Database Change Notification (DCN) is not supported by PDB.
Oracle Automatic Storage Management Cluster File System (Oracle ACFS) does not currently support Hybrid Columnar Compression (HCC).
The following is a list of features that are not available or are restricted for a multitenant container database (CDB) in this release of Oracle Database 12c Release 1 (12.1.0.2):
DBVERIFY
Data Recovery Advisor
Flashback Pluggable Database
Flashback Transaction Query
Flashback Transaction Backout
Database Change Notification
Continuous Query Notification (CQN)
Client Side Cache
Heat map
Automatic Data Optimization
Oracle Streams
When using or refreshing certain materialized views, you must ensure that your NLS parameters are the same as when you created the materialized view. Materialized views that fall under this restriction contain Expressions that may return different values, depending on NLS parameter settings.
Oracle recommends writing such expressions in the NLS-independent way. For example, one of the following:
(date > DATE '2003-01-02') (rate <= 2.150)
Write the expression as a equijoin where one side of the join is character data. The result of this equijoin depends on collation which can change on a session by session basis, giving an incorrect result in the case of query rewrite or an inconsistent materialized view after a refresh operation.
Expressions generate internal conversion to character data in the select list of a materialized view, or inside an aggregate of a materialized aggregate view.
This restriction does not apply to expressions that involve only numeric data. For example, a+b where a and b are numeric values.
Oracle Database 12c Release 1 (12.1) introduces behavior changes for your database in addition to new features. Changes in behavior include deprecated and desupported initialization parameters, options, syntax, and the deprecation and desupport of features and components. For more information, see the Oracle Database Upgrade Guide.
Oracle JPublisher is deprecated in Oracle Database 12c Release 1, as of October 2014, and all JPublisher features are desupported and unavailable in Oracle Database 12c Release 2. Oracle recommends that you use the alternatives listed here:
To continue to use Web service callouts, Oracle recommends that you use the OJVM Web Services Callout utility, which is a replacement for the Web Services Callout utility.
To create Java client applications for PL/SQL programs and SQL objects, Oracle recommends that developers use other JDK development tools that assist you to create java STRUCT classes, and other prestructured options.
See Also:
My Oracle Support Note 1937939.1 for more information about JPublisher deprecation and desupport:https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1937939.1
Also, see JDK Tools and Utilities on Oracle Technology Network:
SQLJ usage inside the database server is deprecated in this release. The capability of translating and running SQLJ applications inside the database will not be available in later releases. SQLJ can only be used as a client tool to translate the applications that can connect to Oracle Database and run as a client. SQLJ cannot be used inside stored procedures, functions, or triggers.
Starting with Oracle Database 12c, Oracle Database and related technologies, such as Oracle Clusterware, no longer support the direct use of raw (block) storage devices (reference Bug 13503952). This means that files must be moved to Oracle ASM or a supported shared file system (cluster file system or Network File System (NFS)) prior to upgrading to Oracle Clusterware release 12c.
The microprocessors for the SPARC M7, T7 and S7 series servers include Data Analytics Accelerator (DAX) coprocessors. These coprocessors perform query-related operations directly through the hardware, which improves Oracle Database performance. With the minimum versions of Oracle Database Enterprise Edition and Oracle Solaris listed below, you can use DAX hardware acceleration for Oracle Database 12c in-memory database operations.
The minimum requirements for using DAX are as follows:
Solaris version: System specific, but generally includes Solaris 11.3 or later. Refer to the Server Product Notes for a given system for specific minimum requirements including any required Solaris 11.3 SRU.
SPARC M7/T7 minimum required Oracle version and patches:
Oracle Database 12c 12.1.0.2
Patch 21744410: DATABASE PATCH FOR ENGINEERED SYSTEMS AND DB IN-MEMORY 12.1.0.2.13 (OCT2015), or later
Patch 21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
SPARC M7/T7 recommended Oracle version and patches:
Oracle Database 12c 12.1.0.2
Patch 23273686: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160719 (JUL2016)
Patch 21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
Patch 21888938: CPUSPEEDNW IS UNDER REPORTED ON SPARC
SPARC S7 minimum required Oracle version and patches:
Oracle Database 12c 12.1.0.2
Patch 23273686: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160719 (JUL2016)
Patch 24353230: MERGE REQUEST ON TOP OF DATABASE BP 12.1.0.2.160719 FOR BUGS 22091036 23235386
Patch 23265829: CPU EFFECTIVE MULTIPLIER CHANGE TO 0.5 DEFAULT
Patch 21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
Patch 21888938: CPUSPEEDNW IS UNDER REPORTED ON SPARC
Finally, enable the in-memory feature for your application.
Note the following changes in Database Security.
Oracle provides a patch that will strengthen native network encryption security for both Oracle Database servers and clients.
The Oracle patch will update encryption and checksumming algorithms and deprecate weak encryption and checksumming algorithms.
This patch, which you can download from My Oracle Support note 2118136.2, strengthens the connection between servers and clients, fixing a vulnerability in native network encryption and checksumming algorithms. It adds two parameters that make it easy to disable older, less secure encryption and checksumming algorithms. Oracle strongly recommends that you apply this patch to your Oracle Database server and clients.
This patch applies to Oracle Database releases 11.2 and later. You can apply this patch in the following environments: standalone, multitenant, primary-standby, Oracle Real Application Clusters (Oracle RAC), and environments that use database links.
The supported algorithms that have been improved are as follows:
Encryption algorithms: AES128, AES192 and AES256
Checksumming algorithms: SHA1, SHA256, SHA384, and SHA512
Weak algorithms that are deprecated and should not be used after you apply the patch are as follows:
Encryption algorithms: DES, DES40, 3DES112, 3DES168, RC4_40, RC4_56, RC4_128, and RC4_256
Checksumming algorithm: MD5
The general procedure that you will follow is to first replace references to desupported algorithms in your Oracle Database environment with supported algorithms, patch the server, patch the client, and finally, set sqlnet.ora parameters to re-enable a proper connection between the server and clients.
The patch affects the following areas including, but not limited to, the following:
JDBC network encryption-related configuration settings
Encryption and integrity parameters that you have configured using Oracle Net Manager
Secure Sockets Layer (SSL) SSL_CIPHER_SUITE parameter settings
SecureFiles LOB encrypted columns
Database Resident Connection Pooling (DRCP) configurations
Encryption settings used for the configuration of Oracle Call Interface (Oracle OCI), ODP.NET
See Also:
Oracle Database JDBC Developer's Guide
Oracle Database Security Guide, section titled "Configuring Encryption and Integrity Parameters Using Oracle Net Manager"
In addition to applying a patch to the Oracle Database server and client, you must set the server and client sqlnet.ora parameters.
Ensure that you perform the following steps in the order shown:
Back up the servers and clients to which you will install the patch.
Log in to My Oracle Support and then download patch described in My Oracle Support note 2118136.2.
My Oracle Support is located at the following URL:
https://support.oracle.com
Patch the server.
Follow the instructions in My Oracle Support note 2118136.2 to apply the patch to the server. You will apply the same patch to the client in a later step.
Patch the clients.
Determine which clients you need to patch.
Follow the instructions in My Oracle Support note 2118136.2 to apply the patch to each client.
In each client sqlnet.ora file, remove all deprecated algorithms if they are defined.
You can bypass this step if the following parameters are not defined or have no algorithms listed:
SQLNET.ENCRYPTION_TYPES_CLIENT
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
In the server sqlnet.ora file, remove all deprecated algorithms if they are defined.
You can bypass this step if the following parameters are not defined or have no algorithms listed.
SQLNET.ENCRYPTION_TYPES_SERVER
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER
For maximum security on the server, set the following sqlnet.ora parameters:
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA512)
SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS = FALSE
For maximum security on the client, set the following sqlnet.ora parameters:
SQLNET.ENCRYPTION_CLIENT = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256)
SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA512)
SQLNET.ALLOW_WEAK_CRYPTO = FALSE
In each client sqlnet.ora file, after you have removed all the deprecated algorithms from the server and the clients per steps 5 and 6, set the parameter SQLNET.ALLOW_WEAK_CRYPTO = FALSE so that the clients can be prevented from communicating with unpatched servers.
If the SQLNET.ALLOW_WEAK_CRYPTO parameter is set to FALSE, then a client attempting to use a weak algorithm will produce an ORA-12269: client uses weak encryption/crypto-checksumming version error at the server. A client connecting to a server (or proxy) that is using weak algorithms will receive an ORA-12268: server uses weak encryption/crypto-checksumming version error.
In the server sqlnet.ora file, after you have updated all the clients with SQLNET.ALLOW_WEAK_CRYPTO = FALSE per step 9, set the parameter SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS = FALSE. This parameter prevents a patched server from communicating with unpatched clients.
If the SQLNET.ALLOW_WEAK_CRYPTO parameter is set to FALSE, then a client attempting to use a weak algorithm will produce an ORA-12269: client uses weak encryption/crypto-checksumming version error at the server. A client connecting to a server (or proxy) that is using weak algorithms will receive an ORA-12268: server uses weak encryption/crypto-checksumming version error.
If you use the database links, then the first database server acts as a client and connects to the second server. Therefore, ensure that all servers are fully patched and unsupported algorithms are removed before you set SQLNET.ALLOW_WEAK_CRYPTO to FALSE.
Oracle offers two ways to encrypt data over the network, native network encryption and Transport Layer Security (TLS).
There are advantages and disadvantages to both methods.
There are advantages and disadvantages for native network encryption:
Advantages
It is configured with parameters in the sqlnet.ora configuration file.
In most cases, no client configuration changes are required.
No certificates are required.
Clients that do not support native network encryption can fall back to unencrypted connections while incompatibility is mitigated.
Disadvantages
It uses a non-standard, Oracle proprietary implementation.
It provides no non-repudiation of the server connection (that is, no protection against a third-party attack).
There are advantages and disadvantages for Transport Layer Security:
Advantages
It is an industry standard for encrypting data in motion.
It provides non-repudiation for server connections to prevent third-party attacks.
It can be used for database user authentication.
Disadvantages
It requires client and server changes.
Certificates are required for the server and are optional for the client. However, the client must have the trusted root certificate for the certificate authority that issued the server's certificate.
Certificates eventually expire.
In Oracle Database Release 11g, if you set the DBMS_CRYPTO.CHAIN_OFB block cipher chaining modifier to configure ciphertext encryption to use output feedback (OFB) mode, then due to Oracle Bug 13001552, the result is that the configuration used electronic codebook (ECB) mode erroneously. This bug has been fixed in Oracle Database Release 12c. Therefore, after an upgrade from Oracle Database Release 11g to Release 12c, the ciphertexts that were encrypted using OFB mode in Release 11g will no longer decrypt properly in the corrected OFB mode in Oracle Database Release 12c.
As a workaround, decrypt the cyphertexts using the DBMS_CRYPTO.CHAIN_ECB block cipher chaining modifier.
If you are preparing to upgrade from Oracle Database Release 11g to Release 12c, then edit any scripts that you may have in which OFB mode is specified so that the decrypt operations use ECB mode. This way, the scripts will work in both Release 11g and Release 12c, ensuring business continuity.
In release 12.1.0.2, a new parameter HTTPS_SSL_VERSION is introduced and is exclusive to release 12.1.0.2. This parameter defaults to 1.1 or 1.2, meaning TLSv1.1 or TLSv1.2. As a result, you can now control the Secure Sockets Layer (SSL) version used by HTTPS separately. In particular, set the SSL_VERSION and HTTPS_SSL_VERSION parameters in the same sqlnet.ora file to control the SSL version used by HTTPS. You can set this parameter to any valid SSL_VERSION values.
Note:
This affects the security in the connection between the Oracle Clusterware and the mid-tier or JDBC client.JDBC or Oracle Universal Connection Pool's (UCP) Oracle RAC features like Fast Connection Failover (FCF) subscribe to notifications from the Oracle Notification Service (ONS) running on the Oracle RAC nodes. The connections between the ONS server in the database tier and the notification client in the mid-tier are usually not authenticated. It is possible to configure and use SSL certificates to setup the authentication but the steps are not clearly documented.
The workaround is as follows:
Create an Oracle Wallet to store the SSL certificate using the orapki interface:
cd $ORA_CRS_HOME/opmn/conf
mkdir sslwallet
orapki wallet create -wallet sslwallet -auto_login
When prompted, provide ONS_Wallet as the password.
orapki wallet add -wallet sslwallet -dn "CN=ons_test,C=US" -keysize 1024 -self_signed -validity 9999 -pwd ONS_Wallet
orapki wallet export -wallet sslwallet -dn "CN=ons_test,C=US" -cert sslwallet/cert.txt -pwd ONS_Wallet
Copy the wallet created in Step c to all other cluster nodes at the same location.
Stop the ONS server on all nodes in the cluster:
srvctl stop nodeapps
Update the ONS configuration file on all nodes in the database tier to specify the location of the wallet created in Step 1:
Open the file ORA_CRS_HOME/opmn/conf/ons.config
Add the walletfile parameter to the ons.config file:
walletfile=ORA_CRS_HOME/opmn/conf/sslwallet
Restart the ONS servers with the srvctl:
srvctl start nodeapps
If you are running a client-side ONS daemon on the mid-tier, there are two possible configurations:
ONS started from OPMN (like in Oracle AS 10.1.3.x) which uses opmn.xml for its configuration.
ONS started standalone (like using onsctl), which uses ons.config for its configuration.
For case (1), refer to the OPMN Administrator's Guide for the Oracle Application Server release. This involves modifying the opmn.xml file to specify the wallet location.
For case (2), refer to the section titled Configuration of ONS in Appendix B of the Oracle Database JDBC Developer's Guide. The client-side ONS daemon can potentially run of different machines. Copy the wallet created in Step 1 to those client-side machines and specify the path on that client-side machine in the ons.config file or in the opmn.xml file.
If you are running remote ONS configuration without a client-side ONS daemon, refer to the "Remote ONS Subscription" subsection of the "Configuring ONS for Fast Connection Failover" subsection of the "Using Fast Connection Failover" section of the "Fast Connection Failover" chapter in the Oracle Database JDBC Developer's Guide. Copy the wallet created in Step 1 to those client-side machines and specify the path on that client-side machine in the ons.config file or in the opmn.xml file.
Alternatively, you can specify the following string as the setONSConfiguration argument:
propertiesfile=location_of_a_Java_properties_file
The Java properties file should contain one or more of the ONS Java properties listed below, but at least the oracle.ons.nodes property. The values for these Java properties would be similar to those specified in the "Remote ONS Subscription" subsection previously noted in this step:
oracle.ons.nodes oracle.ons.walletfile oracle.ons.walletpassword
An additional access control list (ACL) privilege called JDWP is required to connect a database session to a JDWP debugger running at a host and port. The privilege can be granted by the database administrator using the following call:
begin
dbms_network_acl_admin.append_host_ace(
host => '<debugger-host>',
lower_port => <JDWP-port>,
upper_port => <JDWP-port>,
ace => xs$ace_type(privilege_list => xs$name_list('jdwp'),
principal_name => '<debugging-user>',
principal_type => xs_acl.ptype_db));
end;
The host parameter can be a host name, an IP address, a domain name, or an IP subnet. The lower_port and upper_port values can be omitted to allow the connection at any port number. For additional details, refer to the Oracle Database Security Guide.
Note the following when working with multitenant container databases (CDBs):
Flashback Data Archive (FDA) is supported for multitenant container databases (CDBs) in this release.
If a statement cache at the application server level is enabled (for example, the WebLogic or third-party application server statement cache), this must be disabled when the replay is used. Instead, configure the JDBC statement cache, which performs better because it is optimized for JDBC and Oracle and because it supports Application Continuity. Use oracle.jdbc.implicitstatementcachesize=nnn.
To learn more about Oracle Application Express, refer to the Oracle Application Express Release Notes and the Oracle Application Express Installation Guide.
When using Security-Enhanced Linux (SELinux) in enforcing mode with Oracle ACFS, ensure that the Oracle ACFS file systems are mounted with an SELinux default context. Refer to your Linux vendor documentation for information about the context mount option.
While downgrading an Oracle Database 12c database with Oracle Database Vault installed to 11.2.0.3, the following error is seen (reference Bug 14217829):
ERROR at line 1: ORA-31011: XML parsing failed ORA-19202: Error occurred in XML processing LPX-00222: error received from SAX callback function ORA-00001: unique constraint (DVSYS.REALM_T$_UK1) violated ORA-06512: at "DVSYS.DBMS_MACADM", line 114 ORA-06512: at line 2
This error is expected and can be ignored. It does not affect Oracle Database Vault functionality in any way.
The following browsers have been certified for use with Oracle Enterprise Manager Database Express (EM Express), database release 12.1.0.2:
Note:
For these browsers, the minimum Transport Layer Security (TLS) version required to access EM Express is TLS 1.1.Note the following when working with Oracle Clusterware and Oracle Automatic Storage Management (Oracle ASM), which are installed with an Oracle Grid Infrastructure for a cluster installation.
Some non-Oracle Grid Infrastructure usage of mount points prevents unmounts and volume disables in the kernel (reference Bug 8651848). Examples include:
Network File System (NFS)
Samba/Common Internet File System (CIFS)
If this reflects your situation, ensure that you discontinue usage of these features before trying to initiate a stack shutdown, file system unmount, or volume disable.
Additionally, certain user space processes and system processes may use the file system or volume device in a way that prevents the Oracle Grid Infrastructure stack from shutting down during a patch or upgrade.
If this occurs, use the lsof and fuser commands (Linux and UNIX) or the handle and wmic commands (Windows) to identify processes which are active on the Oracle ACFS file systems and Oracle ADVM volumes. To ensure that these processes are no longer active, dismount all Oracle ACFS file systems or Oracle ADVM volumes and issue an Oracle Clusterware shutdown. Otherwise, errors may be issued during Oracle Clusterware shutdown relating to activity on Oracle ACFS file systems or Oracle ADVM volumes which will stop the successful shutdown of Oracle Clusterware.
For additional information, refer to the Oracle Multimedia Readme file located at:
ORACLE_HOME/ord/im/admin/README.txt
For additional information about Oracle ODBC Driver, see the Oracle ODBC Driver Release Notes.
The Oracle SQL Developer readme file is located at:
ORACLE_HOME/sqldeveloper/readme.html
Note the following when working with Oracle Spatial and Graph RDF Semantic Graph.
For Release 12.1.0.2, to use Oracle Spatial and Graph RDF Semantic Graph with new Oracle Database installations and databases that have been upgraded to Release 12.1.0.2.0, if you have not already enabled the Oracle Spatial and Graph GeoRaster feature, you must connect as the SYS user with SYSDBA privileges (SYS AS SYSDBA) and execute the mdsys.enableGeoRaster procedure. This procedure creates a system trigger that is required for RDF Semantic Graph operations.
For more information, see "Enabling RDF Semantic Graph Support" in Oracle Spatial and Graph RDF Semantic Graph Developer's Guide.
Note the following when working with Oracle Text. You should also check entries for the Oracle Text Application Developer's Guide in the Documentation Addendum.
An Oracle Text knowledge base is a hierarchical tree of concepts used for theme indexing, ABOUT queries, and deriving themes for document services. The following Oracle Text services require that a knowledge base be installed:
Index creation using a BASIC_LEXER preference where INDEX_THEMES=YES
SYNCing of an index where INDEX_THEMES=YES
CTX_DOC.THEMEs
CTX_DOC.POLICY_THEMEs
CTX_DOC.GIST
CTX_DOC.POLICY_GIST
CTX_QUERY.HFEEDBACK
CTX_QUERY.EXPLAIN, if using ABOUT or THEMES with TRANSFORM
CTX_DOC.SNIPPET (if using the ABOUT operator)
CTX_DOC.POLICY_SNIPPET (if using the ABOUT operator)
CONTAINS queries that use ABOUT or THEMES with TRANSFORM
The Knowledge Base Extension Compiler, ctxkbtc
Clustering and classification services, if themes are specified
If you plan to use any of these Oracle Text features, then you should install the supplied knowledge bases, English and French, from the Oracle Database Examples media, available for download on OTN.
Note that you can extend the supplied knowledge bases, or create your own knowledge bases, possibly in languages other than English and French. For more information about creating and extending knowledge bases, refer to the Oracle Text Reference.
For information about how to install products from the Oracle Database Examples media, refer to the Oracle Database Examples Installation Guide that is specific to your platform.
Note the following Oracle Text limitations for Oracle Database 12c:
BIG_IO and SEPARATE_OFFSETS preferences are not supported in the following scenarios:
If the database session is restricted (for example, ALTER SYSTEM ENABLE RESTRICTED SESSION)
Running ALTER TABLE MODIFY PARTITION on an index created with these preferences
Trying to create an index with a quoted index name with mixed case characters
Using CTX_DDL.RECREATE_INDEX_ONLINE
STAGE_ITAB preference is not supported in the following scenarios:
Trying to issue ALTER INDEX REBUILD PARAMETERS ('resume')
Trying to create or alter an index to use SYNC ON COMMIT
Using CTX_DDL.RECREATE_INDEX_ONLINE
Using CTX_DDL.REMOVE_MDATA
Trying to alter an index with the clause MIGRATE FIELD SECTION
FORWARD_INDEX preference is not supported in the following scenarios:
Concurrently running CTX_DDL.SYNC_INDEX and CTX_DDL.OPTIMIZE_INDEX on an index with this preference
Having SDATA sections in the same index
Marking an Oracle Text index to be invisible is not supported.
The following features are not supported with Oracle XML DB:
Flashback Data Archive
Editioning Views
SecureFiles LOB Encryption
Oracle Label Security (OLS) with a hybrid structured and unstructured XMLIndex on the same XML document.
For tables created prior to 11.2.0.2, the view ALL|DBA|USER_XML_OUT_OF_LINE_TABLES may not return an out-of-line table in the case where xdb:defaultTable annotation was used but xdb:SQLInline was not specified for that table while registering the Oracle XML DB schema (reference Bug 7646934).
For additional information about Pro*C, see the Pro*C/C++ Release Notes.
For additional information about Pro*COBOL, see the Pro*COBOL Release Notes.
For additional information about SQL*Plus, see the SQL*Plus Release Notes.
This section lists known bugs for this release. A supplemental list of bugs may be found as part of the release documentation specific for your platform.
This section of the Readme contains the following sub-sections:
Section 2.22.1, "12.1.0.2 Standard Edition Release Known Bugs"
Section 2.22.2, "Database Upgrade Assistant (DBUA) Known Bugs"
Section 2.22.3, "Deinstallation Tool Known Bugs"
Section 2.22.4, "Multitenant Container Database (CDB) and Pluggable Database (PDB) Known Bugs"
Section 2.22.5, "Oracle ASM Cluster File System (Oracle ACFS) Known Bugs"
Section 2.22.6, "Oracle Automatic Storage Management (Oracle ASM) Known Bugs"
Section 2.22.7, "Oracle Clusterware Known Bugs"
Section 2.22.8, "Oracle Database Enterprise Edition Known Bugs"
Section 2.22.9, "Oracle Database In-Memory Known Bugs"
Section 2.22.10, "Oracle Database Quality of Service (QoS) Management Known Bugs"
Section 2.22.11, "Oracle Data Guard Logical Standby Database Known Bugs"
Section 2.22.12, "Oracle Grid Infrastructure Known Bugs"
Section 2.22.13, "Oracle Real Application Clusters (Oracle RAC) Known Bugs"
Section 2.22.14, "Oracle Text Known Bugs"
Section 2.22.15, "Oracle Universal Installer Known Bugs"
Section 2.22.16, "Oracle XML DB Known Bugs"
Section 2.22.17, "Vendor and Operating System Known Bugs"
The following section describes known bugs for the Oracle Database 12c Release 1 (12.1.0.2) Standard Edition release.
Starting in release 12.1.0.1, Oracle introduced XML search index for XQuery full text queries. One of the internal tables created for XML search index is created with medium compression which relies on the Oracle Advanced Compression option. On Oracle Database Standard Edition, where advanced compression is not available, the index creation raises the following error:
ORA-00439: feature not enabled: Advanced Compression
Workaround: Apply the patch containing the fix for this bug (21353871). The patch creates the internal table without compression if the Oracle Advanced Compression option is not available.
This sections describe known bugs for Database Upgrade Assistant (DBUA).
When trying to restore the database using the restore script, it is possible to run out of sessions and the restore script displays the ORA-00018 error.
Workaround: Increase the sessions initialization parameter to a higher value, run the utlrp.sql script, and execute the following command:
ALTER SYSTEM SET SESSIONS=<new_number> SCOPE=BOTH;
Depending on the upgrade options selected during the Oracle Database Upgrade Assistant (DBUA) interview process, DBUA may provide an option to users to recover the database in case of upgrade failure.
If the source database is owned by a different user than the current user invoking DBUA, the restore operation may fail as it may not be able to access the backup files owned by the source database user. This is typically the case while upgrading an Oracle Database Express Edition database, where the database is owned by the user oracle.
Workaround: Before confirming to restore the database, change the permissions of the backup location directory to allow user access to the current user.
This section describes known bugs for the deinstallation tool.
When running the deinstallation tool to deinstall the database, you will be prompted to expand the Oracle home and to select a component. If you select the top level component, Oracle Database Server, and do not select the Oracle home, OUI does not show the message to run the deinstall utility and proceeds with the deinstallation of the database.
Workaround: Run the deinstallation tool to deinstall the Oracle home.
This section describes known bugs for multitenant container database (CDB) and pluggable database (PDB).
When creating a multitenant container database (CDB) with many pluggable databases (PDB) with default process parameters, the ORA-12516 error is returned.
Workaround: Change the process number to 80*<number_of_CPU_cores> when using DBCA to create a multitenant container database.
This section describes known bugs for Oracle ASM Cluster File System (Oracle ACFS).
When creating a target working copy as part of the Rapid Home Provisioning move operation, the rhpctl move command does not have -ignoreprereq option needed to ignore the failures of the CVU pre-requisite checks for the target working copy creation.
Workaround: Create the target working copy first specifying the rhpctl add workingcopy command with the -ignoreprereq option and then perform the move operation to the created working copy.
When provisioning a working copy for Oracle Database 10g Release 2 (10.2.0.5), if -path is not specified on the command line, the command fails while attempting to create an Oracle home on Oracle ACFS storage.
Workaround: Specify the option -storagetype LOCAL on the rhpctl add workingcopy command to indicate that the local file system storage should be used instead of Oracle ACFS.
When upgrading 11.1 CRS to 12c Oracle Grid Infrastructure for a cluster and after Oracle ASM Configuration Assistant (ASMCA) upgrades Oracle ASM, some database instances may not be started. This problem is not reflected in the Oracle Universal Installer (OUI) as an error or warning.
Workaround: Manually check the database instance after upgrading to detect the state of the database instances. For example:
srvctl status database -db <db_name>
Then, manually start the database instance. For example:
srvctl start database -db <db_name>
In a cluster with a password-protected key store, when an Oracle ACFS file system using encryption is mounted through the Oracle ACFS mount registry, the administrator is not prompted to enter the key store password. Although the process of mounting the file system succeeds, not all information required for Oracle ACFS encryption to work correctly is made available to the file system. In this case, encryption is not operational on this file system and any encrypted files in the file system are not available for read or write.
Workaround: In a cluster with a password-protected key store, do not use the Oracle ACFS mount registry for mounting any file systems that are using encryption. If some file systems are already mounted through the Oracle ACFS mount registry, unmount them and remove any such file systems from the mount registry to avoid possible unavailability of encrypted data in the future. Then, remount these file systems without using the Oracle ACFS mount registry, providing the correct password when requested.
Removal of an Oracle ADVM volume should trigger removal of its corresponding CRS volume resource. In the rare event that this does not occur, the CRS resource can be removed using the following command:
srvctl remove volume
If you register an Oracle ACFS file system using acfsutil registry, and if you also have Network File System (NFS) export or database resources which have Cluster Ready Services (CRS) dependencies on this Oracle ACFS file system, and then if you subsequently modify the registered Oracle ACFS file system using acfsutil registry, the Oracle ACFS file system resource is modified despite the existence of the CRS dependencies. For example, if the Oracle ACFS file system resource is clusterwide and you modify it to be 'node local,' this could result in an unsupported configuration.
This section describes known bugs for Oracle Automatic Storage Management (Oracle ASM).
Oracle Automatic Storage Management (Oracle ASM) loses the rolling migration state if Cluster Ready Services (CRS) shuts down on all nodes.
Workaround: Consider the following scenario of 4 nodes (node1, node2, node3, and node4) that are at release 11.2.0.2 and being upgraded to Oracle Database release 12.1.0.2:
node1 and node2 are upgraded to 12.1.0.2 and running.
node3 and node4 are still at 11.2.0.2 and running.
Now consider that there is an outage where all CRS stacks are down which leaves the cluster in a heterogeneous state (that is, two nodes at 11.2.0.2 and two nodes at 12.1.0.2).
To proceed with the upgrade, only nodes at 11.2.0.2 (that is, node3 and node4 or both) should be started and the following command needs to be executed on the Oracle ASM instance on node3 and node4 before starting any 12.1.0.2 node:
ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'
Continue the upgrade procedure as already documented from this point forward.
Note that before executing the preceding step to bring the Oracle ASM cluster back into rolling migration, you cannot start two nodes of different versions in the cluster. If you do so, one of the Oracle ASM versions fail with either the ORA-15153 or ORA-15163 error message.
This section describes known bugs for Oracle Clusterware.
The Oracle Clusterware installation may list the prerequisite check Task DHCP Configuration check with a warning when a user selects the root automation option and later decides against it.
Workaround: This check failure can be ignored in this situation.
If you use a path to the -savedir option which is non-existent, or a path to which write permissions have not been granted to the user running the command cluvfy comp baseline -savedir, the command fails without reporting a proper error message.
Workaround: Specify a valid directory that can be written to by the user for the -savedir option.
If the Oracle Cluster Synchronization Services daemon (CSSD) restarts without the Oracle High Availability Services daemon (OHASD) Oracle Agent (oraagent) restarting, the ohasd ora.asm resource will continue to be in the INTERMEDIATE state.
Workaround: Run the following commands:
crsctl stop res ora.asm -init crsctl start res ora.asm -init
The Grid Infrastructure Management Repository is configured to use Huge Pages. Since this database comes up before all of the other customer's databases, it may cause one or more of the customer's databases System Global Areas (SGAs) to be mapped to regular pages (instead of Huge Pages). The size of the Grid Infrastructure Management Repository's SGA is 750 MB. Hence the Huge Pages setting needs to be increased to accommodate the sum of the SGA sizes of all the intended customer databases plus Grid Infrastructure Management Repository.
Workaround: Increase the allocated Huge Pages to accommodate the SGA of the Grid Infrastructure Management Repository.
The STATIC SCAN address may be lost after converting network nettype from autoconfig to mixed. If this happens, the srvctl config scan command will not show the STATIC address of SCAN.
Workaround: Restart SCAN after converting network nettype from autoconfig to mixed.
During an Oracle RAC installation with a database creation, an option to save the DBSNMP password into the CVUDB cluster wallet is not provided to the user. Therefore, the DBSNMP users password will not be saved. When the Cluster Verification Utility (CVU) resource runs again, it will try to perform database related checks but, because the wallet is not available, CVU will not be able to perform the checks. This results in an error begin written to the Oracle Clusterware alert log. Errors could also occur when the cluvfy commands that perform database related operations are executed.
Workaround: As either the Oracle RAC owner or as root, manually create the CVUDB wallet by running the following command:
crsctl add wallet -type CVUDB -name <dbsid> -user dbsnmp -passwd
Size changes to the Oracle Grid Infrastructure Management Repository prior to the upgrade are not persisted after the upgrade to release 12.1.0.2.
Workaround: Reassert the repository size changes using the oclumon manage -repos changerespossize command after the upgrade to release 12.1.0.2.
The problem could be one of two scenarios. In the first scenario, when more than one interface in the network has the same IP address, it creates routing conflicts. In the second scenario, when there are multiple entries (generally .BAK files) in the network scripts with the same IP address, this also creates routing conflicts.
Both of these scenarios are verified by the Cluster Verification Utility (CVU) and the CVU complains if one of the stated scenarios is true.
If the first scenario is the case, then it is actually an issue and CVU reporting this as verification failure is correct.
If the second scenario is the case, either there is a backup file created automatically or someone might have created a copy of an interface and not deleted the copy at a later time. In this case, CVU reports this as multiple interfaces having the same IP address.
Workaround for Scenario 1: Make sure no two interfaces have same IP address.
Workaround for Scenario 2: If there are .BAK files or duplicate entries under network scripts at /etc/sysconfig/network -scripts (for example, ifcfg-eth0 and ifcfg-eth0.BAK) and if they have same IP address, remove ifcfg-eth0.BAK or modify the IP address of ifcfg-eth0.BAK.
The database client may fail to connect to the database with dynamic IPv6 SCAN name after the network type is converted from autoconfig to mixed.
Workaround: Restart SCAN after converting the network type from autoconfig to mixed.
Oracle resources for release 10.2 and release 11.1 Oracle RAC databases may not operate properly after upgrading Oracle Clusterware to Release 12.1.
Workaround: After installing Oracle Clusterware 12g Release 1 (12.1), contact Oracle Support Services to obtain the patches for the following bugs:
8373758 - TB-CMP: 11107 SERVICE CAN'T BE BROUGHT UP BY 11107 SRVCTL WHEN WITH 11.2 CRS
8441769 - TB_UD: INCORRECT SERVICE INFO REGISTER TO DB, UPGRADE CRS_HOME 11.1.0.7 -> 11.2
8406545 - TB-CMP: RESTART OF 11.2 HAS STACK FAILED TO BRING UP 11.1 ORACLE RAC INSTANCE
8262786 - TB-CMP: FAIL TO START 11106 DB INSTANCE WITH 11.2 CRS
Note:
Apply the patches to the Oracle Database home.Interrupting or killing the installation script on the first cluster node may result in the following errors when the script is run again on the first node or is subsequently run on other cluster nodes:
CLSRSC-46: Error: '$ORA_CRS_HOME/gpnp/wallets/pa/cwallet.sso' does not exist CLSRSC-153: Could not set permissions on '$ORA_CRS_HOME/gpnp/wallets/pa/cwallet.sso' CLSRSC-148: Errors occurred while setting GPnP wallets ownership/permissions
These errors are caused by a missing copy of a non-essential file which is not detected when the existing configuration revalidated on subsequent runs.
Workaround: These errors may be safely ignored, the script will continue to run, and the product installation will not be affected.
However, if a clean run is desired, delete the files in following directories on all cluster nodes before the script restarts on the first node:
rm $ORA_CRS_HOME/gpnp/profiles/peer/* rm $ORA_CRS_HOME/gpnp/wallets/peer/*
This section describes known bugs for Oracle Database Enterprise Edition.
If you are running with Oracle Direct NFS (dNFS) enabled, then you can use network file system (NFS) protocol devices for backup files or for Oracle Data Pump files. Since these files are not used by the database all of the time, you can run NFS administration changes to unmount the NFS volume and remount it on the same mount point. Without this fix, you may see stale or bad file handle errors because dNFS uses the cached file handles from the system global area (SGA). The UNMOUNTVOLUME procedure allows you to clean up the cached file handles in SGA.
The UNMOUNTVOLUME procedure cleans up the cached NFS file handles in SGA and should be used when any NFS mount changes are being made using the operating system and when the operating system UNMOUNT and MOUNT commands are being invoked. The UNMOUNTVOLUME procedure is the equivalent of the operating system UNMOUNT command for the dNFS client.
Workaround: Without this fix, you have to shutdown and restart the database to clean up the cached file handles that are saved in the SGA.
Database directory names should not contain error message prefix codes (for example, TNS or ORA) because this causes a problem for Oracle Enterprise Manager.
The Oracle OLAP option is only available with Oracle Database Enterprise Edition. An error occurs if you attempt to use Oracle OLAP with Oracle Database Standard Edition (SE). For example, if you try to export using Oracle OLAP with SE, you see the following errors:
EXP-00008: ORACLE error 29280 encountered ORA-29280: invalid directory path ORA-06512: at "SYS.UTL_FILE", line 41 ORA-06512: at "SYS.UTL_FILE", line 478 ORA-06512: at "SYS.DBMS_AW_EXP", line 89 ORA-06512: at "SYS.DBMS_AW_EXP", line 1177 ORA-06512: at line 1 EXP-00085: The previous problem occurred when calling SYS.DBMS_AW_EXP.instance_extended_info_exp for object 85676
Workaround: Use Oracle OLAP with Oracle Database Enterprise Edition.
If a query uses the PARTITION clause in the FROM clause to access table partitions, query rewrite does not occur.
Workaround: Users should convert the PARTITION clause into an equivalent selection predicate in the WHERE clause.
If fine-grained auditing is enabled on a table in the query, then Query Rewrite will not occur for this query.
In a cluster that has IPv4 and IPv6 addresses for the host name, the automatic execution of the root script using the root password fails on all nodes other than the node where the installer is running. This applies to both installation and upgrade.
Workaround: If the installation or upgrade fails in such an environment, the workaround is to run the root.sh or the rootupgrade.sh script manually on all of the cluster nodes.
It is possible that you may see inconsistencies with DBMS_QOPATCH directory objects and inventory in ORACLE_HOME after you have applied a patch out-of-place. You can check this by selecting the OPATCH_SCRIPT_DIR, OPATCH_LOG_DIR, or OPATCH_INST_DIR from DBA_DIRECTORIES (for example, SELECT DIRECTORY_NAME,DIRECTORY_PATH DBA_DIRECTORIES WHERE DIRECTORY_NAME='OPATCH_SCRIPT_DIR') and see if these are pointing to the correct ORACLE_HOME location where you applying or querying the patch details.
Workaround: Manually correct the directory objects or execute DBMS_QOPATCH.REPLACE_LOGSCRPT_DIRS() manually. Once the directory objects are corrected, run the failing query or data patch again.
After plugging a release 12.1.0.1 pluggable database (PDB) into a release 12.1.0.2 multitenant container database (CDB), users may encounter issues when trying to use some common types with system-generated names. Those common types are created by registering some Oracle XML DB schema with object-relational storage. Since those type names are system generated, their names in release 12.1.0.1 could be different from those in release 12.1.0.2 and, therefore, they may not have matching common types in release 12.1.0.2 CDB root.
Workaround: Execute the following steps:
Query view PDB_PLUG_IN_VIOLATIONS in the target CDB root for any action containing GetTypeDDL which indicates that the upgraded PDB has the issue stated in the preceding paragraph.
Execute set serveroutput on and exec xdb.DBMS_XMLSTORAGE_MANAGE.GetTypeDDL in the target PDB to generate a user-named SQL script (for example, script1.sql).
Run script1.sql in the original source 12.1.0.1 CDB to get the type creation script for all those common types and generate another user-name SQL script (for example, script2.sql).
Run script2.sql in the target PDB to create all those types locally.
For pluggable database (PDB) maintenance operations, parallel tasks need to be allocated on all active instances to perform the operation on each instance regardless of the setting of the PARALLEL_MAX_SERVERS initialization parameter. If an instance had PARALLEL_MAX_SERVERS=0 set, the parallel task was not allocated on the instance and the operation was not performed there.
Workaround: Do not set the value of the PARALLEL_MAX_SERVERS initialization parameter to 0. Not setting the PARALLEL_MAX_SERVERS initialization parameter at all is sufficient.
An ORA-00600 internal error appears during a shutdown of the database after you have selected from the V$ENCRYPTION_KEYS or V$CLIENT_SECRETS Transparent Data Encryption (TDE) view when using TDE in an hardware security module (HSM) configuration.
Workaround: This problem occurs when you try to clean up the system global area (SGA) cache for V$ENCRYPTION_KEYS or V$CLIENT_SECRETS views after the database shutdown has been initiated. Closing the wallet also cleans up the SGA cache for these views.
Before shutting down the database, explicitly close the keystore by executing the following syntax:
ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "user_id:password" [CONTAINER = ALL | CURRENT];
If LOB operations are issued in distributed transactions or if the underlying LOB is stored as a SecureFile, the ORA-00600 error is returned.
Workaround: Turn off the SecureFile space cache by setting _kdli_space_cache_limit=0 in the initialization parameter file and bounce the instances.
Note:
Setting_kdli_space_cache_limit=0 in the initialization parameter file can degrade performance.Tables containing TIMESTAMP WITH LOCAL TIME ZONE data cannot be moved between databases using transportable tablespace technology when the time zones of the source and target databases are different. Each affected table will be flagged during import with the following error:
ORA-39360, Table "<owner>"."<table name>" skipped due to transportable import and TSLTZ issues.
Workaround: Convert the target database to the same time zone as the source database or move the affected tables with the conventional Data Pump Export and Import.
During transportable imports, tablespaces are temporarily made read/write and then set back to read-only. This is new behavior introduced as of Oracle Database 12c Release 1 (12.1.0.2) to improve performance. However, this behavior also causes the SCNs of the data files of the import job to change, which can cause issues during future transportable imports of those files.
For example, if a transportable tablespace import fails at any point after the tablespaces have been made read/write (even if they are now read-only again), then the data files become corrupt. They cannot be recovered.
Workaround: Since transportable jobs are not restartable, the failed job needs to be restarted from the beginning. The corrupt data files must be deleted and fresh versions must be copied to the target destination.
When transportable jobs are performed, it is best practice to keep a copy of the data files on the source system until the import job has successfully completed on the target system. If the import job should fail for some reason, you will still have uncorrupted copies of the data files.
When converting a cluster from classic Oracle ASM to Oracle Flex ASM, one or more occurrences of the following error message sequences are observed in the output of the script that is executed as root by the user:
CRS-2672: Attempting to start 'ora.proxy_advm' on '<node-name>'^M CRS-5017: The resource action "ora.proxy_advm start" encountered the following error: ^M ORA-03113: end-of-file on communication channel^M Process ID: 0^M Session ID: 0 Serial number: 0^M
For details, refer to (:CLSN00107:) in <CRS-Home>/log/<node-name>/agent/crsd/oraagent_crsusr/oraagent_crsusr.log.
Workaround: These errors may be ignored. At the end of the conversion, the ora.proxy_advm correctly goes to an ONLINE state on all of the nodes.
Concurrent UNION ALL is automatically invoked for qualifying statements only when the UNION ALL statement is in a subsequent SELECT statement. For example, the following command will enable execution of all branches concurrently:
SELECT * FROM (SELECT FROM ... UNION ALL ... UNION ALL)
However, the exact same UNION ALL statement not executed as a subsequent SELECT statement will not.
Workaround: Either embed the UNION ALL construct as a subsequent SELECT statement or use the following statement to disable legacy code constraints:
ALTER SESSION SET "_fix_control"='6748058:0';
If you have an AL32UTF8 or UTF8 database, and if SQL*Loader is used with external tables as the load method and the table name contains non-ASCII characters, SQL*Loader may fail and report one of the following errors:
SQL*Loader-350: Syntax error at line n. Illegal combination of non-alphanumeric characters
Where n represents the line in the SQL*Loader control file. Or,
SQL*Loader-810: error creating external table: "*" ORA-03001: unimplemented feature
Where "*" represents the external table name generated by SQL*Loader.
This can occur either with a control file if external_table=execute is specified or when using express mode if the default load method of external tables is used or is forced using the external_table=execute command line parameter.
Workaround: The load may work correctly using the SQL*Loader conventional path load method if quotation marks surround the table name.
Starting Oracle Database 12c Release 1 (12.1), temporary LOBs sized up to 256K live in program global area (PGA) memory. This can lead to increased PGA memory consumption. Some workloads may encounter the ORA-4030 error depending on the number of temporary LOBs created.
Workaround: Set event 32761, level 16 to turn off in-memory temporary LOBs. Setting this event spills temporary LOBs to temporary segments on disk. Even though this brings the memory consumption to pre-12.1 levels, users will not see the performance benefits of in-memory temporary LOBs.
This section describes known bugs for Oracle Database In-Memory.
The default value for the INMEMORY_MAX_POPULATE_SERVERS parameter is derived from the PGA_AGGREGATE_LIMIT parameter at instance startup. The estimation of the PGA_AGGREGATE_LIMIT can be off at instance startup before knowing the physical memory. When calculating the number of In-Memory population servers, only 50% of PGA_AGGREGATE_LIMIT is used. Each population server requires 500 MB of PGA memory, so the PGA_AGGREGATE_LIMIT parameter (defaults to 2 * PGA_AGGREGATE_TARGET) is divided by 1 GB to determine the number of population servers, which may not be enough to populate the In-Memory column store in a timely fashion.
Workaround: Specify the value of the PGA_AGGREGATE_LIMIT or PGA_AGGREGATE_TARGET parameter to a proper value which can be supported by your system in the initialization parameter file. For example, PGA_AGGREGATE_LIMIT can be set to a value equal to or greater than 1 GB * #POPULATE_SERVERS.
It is possible for queries that require a median function to return wrong results when executed against the In-Memory column store.
Workaround: Disable the use of the In-Memory column store at a session level by setting the INMEMORY_QUERY parameter to DISABLE or use the NO_INMEMORY hint to disable the In-Memory column store at the statement level.
In a multitenant environment, only one chunk of memory and one set of background processes are allocated for the multitenant container database (CDB). All of the pluggable databases (PDBs) in that CDB share the memory and, therefore, share the In-Memory (IM) column store. The GV$INMEMORY_AREA view indicates how much memory is used and available in the IM column store across the PDBs. The GV$INMEMORY_AREA view incorrectly indicates that space used by one PDB is used by all of the PDBs.
Workaround: To calculate the total amount of space used in the IM column store in a multitenant environment, look at the value for only one PDB in the GV$INMEMORY_AREA view, rather than adding all of the values per PDB.
This section describes known bugs for Oracle Database Quality of Service (QoS) Management.
Resource Manager changed the way CPU resources are managed for CDB or PDB database deployments in a manner that was incompatible with Oracle Database QoS Management 11.2 plan and models. These changes resulted in the need for two plans and different resource modeling with associated workload validation. These models need to be developed, tested, and calibrated on production Resource Manager code. Therefore, in this initial release, Oracle Database QoS Management is only able to measure and monitor CDB or PDB database deployments and cannot make recommendations to help CDB or PDB performance classes that are violating their performance objectives.
This bug applies to recommendations for CPU resources managed by Oracle Database QoS Management. If the number of configured CPUs for all instances on a server is less than the number of physical CPUs for that server, then the nonallocated, or "free", CPUs are not detected by Oracle Database QoS Management and no recommendation is made to increase the number of configured CPUs. Only those "slices" that host databases are considered as donors for the target slice. Adding one of the non-allocated CPUs should be the first-ranked Move CPU action.
Workaround: Make sure the sum of CPU counts configured for each database instance on each server is the same as the number of physical CPUs.
This section describes known bugs for Oracle Data Guard logical standby database.
Piecewise LOB updates on typed index-organized tables (IOT) are not replicated on a logical standby database. SQL Apply will stop with ORA-1403 when it encounters such a change in the redo stream.
Workaround: Use the DBMS_LOGSTDBY.SKIP procedure at the logical standby to skip the table from being replicated.
SQL Apply does not support replication of a table with SYS.ANYDATA column, if the SYS.ANYDATA column contains multibyte characters.
For Oracle Text, indexes created with the FILTER BY or ORDER BY clause of the SQL CREATE INDEX statement, DML statements on the columns specified in the FILTER BY or ORDER BY clause are not replicated at the logical standby. However, the indexes may not be properly maintained at the logical standby.
Workaround: Synchronize the indexes manually at the logical standby database.
This section describes known bugs for Oracle Grid Infrastructure.
There is no way to specify Rapid Home Provisioning managed storage type in the add workingcopy command using the -storagetype option.
Workaround: In order to use Rapid Home Provisioning managed storage type for both Grid Home Server and Grid Home Client, execute one of the following while executing the rhpctl add workingcopy command:
To provision a working copy for the Grid Home Server, the rhpctl add workingcopy command should be specified without the -storagetype option.
To provision a working copy for the Grid Home Client, the rhpctl add workingcopy command should be specified without the -storagetype and -path options.
There are some prerequisite steps to be followed in order to provision a release 10.2.0.5 database with Rapid Home Provisioning.
Workaround: Ensure the following prior to provisioning a release 10.2.0.5 database with Rapid Home Provisioning:
The cluster nodes where the release 10.2.0.5 database needs to be provisioned must be pinned. Use the crsctl pin css command to pin the cluster nodes.
Set SQLNET.ALLOWED_LOGON_VERSION=8 in the
$crs home/network/admin/sqlnet.ora file.
When provisioning an 11.2.0.2 version working copy with Rapid Home Provisioning in a role-separated environment, the operation might fail during the clone stage due to insufficient permissions to access the file install.platform in the central inventory location.
Workaround: Rerun the orainstRoot.sh script as root user from the central inventory location on all the cluster nodes and retry the provisioning operation.
The Rapid Home Provisioning runtime environment needs to be reset due to potential catastrophic failure situations such as loss of the disk group associated with gold images and working copies.
Workaround: Follow these steps:
Stop the Rapid Home Provisioning Server using the following command:
$ srvctl stop rhpserver
Execute the srvctl status mgmtdb command and note the node on which the management database is running.
Login to the node reported in Step 2 as the Oracle Grid Infrastructure user.
Setup the environment variable using the following commands:
$ setenv ORACLE_HOME <GI_home> $ setenv ORACLE_SID -MGMTDB
Connect to the management database using the following command:
$ <GI_home>/bin/sqlplus / as sysdba
Execute the following SQL statements:
SQL> DROP USER ghsuser CASCADE; SQL> CREATE USER ghsuser IDENTIFIED BY "ghsuser" DEFAULT TABLESPACE sysgridhomedata QUOTA UNLIMITED ON sysgridhomedata ACCOUNT LOCK PASSWORD EXPIRE; SQL> GRANT CREATE SESSION, ALTER SESSION, RESOURCE to GHSUSER;
Execute the following command:
$ mgmtca setpassword -user gridhome
Note:
The above actions remove the metadata of the Rapid Home Provisioning Server for all images, working copies, clients, users, etc. Be absolutely sure this is the intended objective before proceeding with above actions.When installing Oracle Grid Infrastructure Release 12c, Oracle ASM device check may report a prerequisite warning error message PRVG-5150. The error message suggests read access for the file /etc/multipath.conf which does not exist on Windows platforms.
Workaround: Ignore the error message and do not select the read access option for the file /etc/multipath.conf.
The password to SYS and SYSTEM schemas are not known for a database that has been provisioned by the Rapid Home Provisioning feature.
Workaround: When creating a database, the Rapid Home Provisioning feature uses random passwords for both the SYS and SYSTEM schemas in the database. These passwords cannot be retrieved. The user with the DBA or operator role should connect to the database locally on the node where it is running and reset the passwords to these two accounts to the desired values.
This section describes known bugs for Oracle Real Application Clusters (Oracle RAC).
In 12.1, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter has been updated to 11. This means that database clients using pre-11g JDBC thin drivers cannot authenticate to 12.1 database servers unless the SQLNET.ALLOWED_LOGON_VERSION parameter is set to the old default of 8.
This will cause a 10.2.0.5 Oracle RAC database creation using DBCA to fail with the ORA-28040: No matching authentication protocol error in 12.1 Oracle ASM and Oracle Grid Infrastructure environments.
Workaround: Set SQLNET.ALLOWED_LOGON_VERSION=8 in the $crs_home/network/admin/sqlnet.ora file.
Use the workaround before running 10.2.0.5 DBCA to create a database using 12.1 Oracle ASM and Oracle Grid Infrastructure.
If you are using Oracle Grid Infrastructure and you want to create an Oracle RAC release 11.1.0.7 database, then you may need to increase the DBCA default for session processes. For Oracle Database 12c, DBCA sets the default value for processes to 300. In earlier releases, DBCA set the default value to 150.
Workaround: If you see the error message ORA-00018:maximum number of session exceeded, then change the default value for session processes in DBCA to 300. DBCA will then successfully create the release 11.1.0.7 database to use with Oracle Grid Infrastructure release 12.1.
For installer invocation, DBCA in silent mode will display the following message and execution will stop after a validation warning. The default DBCA behavior is to stop after the following warning:
There are not enough servers available to allocate to this server pool, Database instances may not come up on specified cardinality. Do you want to continue?
If you click Yes, the DBCA fails.
Workaround: Before starting the installer, ensure that there are a sufficient number of servers in the free server pool. The number of free servers should be more than or equal to the cardinality specified in the installer for configuring the policy-managed Real Application Clusters database. The status and membership details of server pools can be checked using the following command:
Grid_home/bin/crsctl status serverpool
This section describes known bugs for Oracle Text.
The operations using CTX_ENTITY fail with the following error when the database runs out of system global area (SGA) memory:
DRG-13710: Syntax Error in Dictionary ORA-20000: Oracle Text error: DRG-50611: Third party lexer internal error: ANL code internal error
You can see ORA-04031 in the alert log.
Workaround: Increase SGA memory or flush shared pool using ALTER SYSTEM FLUSH SHARED_POOL.
This section describes known bugs for Oracle Universal Installer (OUI).
You should also review Section 3.1, "Compatibility, Upgrading, Downgrading, and Installation" for other issues related to installation and upgrades.
GSM in-place upgrade fails with the INS-32025 error. The chosen installation conflicts with software already installed in the given Oracle home.
Workaround: Perform the following steps to upgrade GSM software from version 12.1.0.1 to 12.1.0.2:
Stop all the processes and services being started by the existing 12.1.0.1 GSM.
Set environment variables ORACLE_HOME and ORACLE_BASE to the existing 12.1.0.1 GSM home and base, respectively.
Execute: cd $ORACLE_HOME
Execute: mv jdk jdk.bkp
Execute: mv QOpatch/qopiprep.bat QOpatch/qopiprep.bat.bkp
Invoke the 12.1.0.2 GSM installer to upgrade software in the existing GSM home.
When deinstalling Oracle Grid Infrastructure for standalone server home with Oracle Management Server configuration, the emConfig.txt file in ORACLE_BASE/admin/emca may not get deleted.
Workaround: To remove the emConfig.txt, execute the following command:
rm -rf $ORACLE_BASE/admin/emca/emConfig.txt
During the last ORACLE_HOME deinstallation, to remove ORACLE_BASE, execute the following command after the deinstallation tool exits:
rm -rf $ORACLE_BASE
When using automation scripts to install Oracle Grid Infrastructure and to create the first Oracle ASM Dynamic Volume Manager (Oracle ADVM) volume, the Oracle ADVM proxy may not start in time to service the volume creation request on the first node.
Workaround: Before creating the first volume, execute the following commands:
srvctl add asm -proxy srvctl start asm -proxy
When performing an Oracle RAC installation, runInstaller may occasionally fail when performing an AttachHome operation because of a connectivity problem with the indicated node. In this case, you receive a message indicating the node that failed and a reference to the central inventory log that contains more detailed information.
Workaround: To correct the issue, execute the following command:
<oracle_home>/oui/bin/runInstaller -attachHome -noClusterEnabled ORACLE_HOME=<oracle_home> ORACLE_HOME_NAME=<oracle_home_name> CLUSTER_NODES=<node_1, node_2, ...> -force "INVENTORY_LOCATION=<central_inventory_location>" LOCAL_NODE=<node_on_which_the_command_is_targeted_to_run>
Oracle Database installer does not check if the password specified for ASMSNMP on the Specify Management Options screen is correct or not. If you proceed with the configuration and specify an incorrect password, then Oracle Enterprise Manager Cloud Control cannot discover details and monitor the Oracle ASM instance.
Workaround #1: Ensure that the correct password (the same password that was specified earlier during the Oracle Grid Infrastructure for a cluster installation) is specified in Specify Management Options screen of Oracle Database installer.
Workaround #2: On the Oracle Enterprise Manager Cloud Control portal, navigate to the Oracle ASM credentials screen and update the correct password for ASMSNMP. Once the correct password is saved on Oracle Enterprise Manager Cloud Control, the Oracle ASM monitoring starts working.
The installer fails with the following error when the server pool name specified for the policy-managed database already exists on the cluster:
[INS-20802] Oracle Database Configuration Assistant failed.
Workaround: Specify a unique name for the server pool when configuring a new policy-managed database on a cluster using the installer.
When installing 12.1.0.2 Oracle Grid Infrastructure for a cluster, the Oracle Universal Installer (OUI) does not verify and report if Oracle ASM disks with insufficient permission on remote nodes are selected due to the root.sh script failing on the nodes where the Oracle ASM disks have insufficient permission.
Workaround: Ensure that the Oracle ASM disks with insufficient permission on remote nodes are not selected. The Cluster Verification Utility tool (CVU) can be used to verify that disks on remote nodes have sufficient permission.
If the central inventory location is different on different nodes of a cluster, addnode.sh does not update the inventory correctly on remote nodes of the cluster.
Workaround: Adding nodes to a cluster requires the central inventory location to be the same on all the nodes of the cluster. Please ensure that this is the case prior to running addnode.sh.
If you install a 32-bit Oracle database and a 64-bit Oracle database in the same ORACLE_BASE, it may lead to unexpected results when using the deinstallation tool to remove one of the databases. The deinstallation tool removes all of the Oracle homes under the ORACLE_BASE if these Oracle homes do not use the same central inventory.
Workaround: Avoid using multiple central inventories. Do not use the same ORACLE_BASE for 32-bit and 64-bit database installations or always perform the deinstallation from a 64 bit home.
The Oracle Universal Installer (OUI) runInstaller script that resides in the Oracle home (ORACLE_HOME/oui/bin/runInstaller) cannot be used to install the Oracle Database 12c releases, Oracle Grid Infrastructure for a cluster, and Oracle Database Client.
Workaround: Use Oracle Universal Installer on the respective Oracle Database 12c product media to install each product.
This section describes known bugs for Oracle XML DB.
Simplified JSON syntax does not support large (over 4K) VARCHAR data type.
Workaround: Use JSON_VALUE or JSON_QUERY with the RETURNING clause.
Using Transportable Tablespaces (TTS) to export or import tables with Binary XML data is not supported.
Workaround: Use the Oracle Data Pump conventional path to move data.
During an upgrade to release 12.1, a client application that is linked against the libclntsh.so.11.1 file might fail to run on Oracle Solaris, HP-UX Itanium or IBM AIX platforms with an error message similar to the following:
referenced symbol count is undefined
Workaround: Relink the client application against the new libclntsh.so.12.1 file.
Prior to Oracle Database 12c Release 1 (12.1), when inserting an XML element without a name space into an XML document, the newly inserted element is assigned to the name space of the parent element if the default name space is defined in the parent element, which is not correct.
In Oracle Database 12c, the new element will be inserted with xmlns="".
Supplemental logging is unsupported for an XMLQuery update with variables bound to a REF cursor.
Workaround: Before updating XMLType columns or attributes that need replicating, store the evaluation of REF cursors in non-cursor variables, and then update the columns or attributes with these variables instead of the REF cursors.
An Oracle RAC system allows multiple concurrent database instances to share a single physical database. However, dispatches for Oracle XML DB in an Oracle RAC database do not listen on the virtual IPs.
Workaround: To enable Oracle XML DB to use TCP(S) on an Oracle RAC system, you must configure the TCP(S) dispatchers for each database instance of the cluster as follows (where SID is the SID of the instance and HOST is the host name for the physical database):
SID.dispatchers="(address=(protocol=tcps)(host=HOST-vip)(service=SIDxdb))"
For non-secure dispatchers (TCP, not TCPS), use tcp in the command instead of tcps.
This section describes vendor and operating system known bugs.
A connect using SCAN and EZCONNECT on one client machine can be requested to use a specific SCAN listener. Therefore, load balancing by round-robin DNS is not possible.
Workaround: Connect to a database using the following configuration specifying LOAD_BALANCE=on in tnsnames.ora:
ORCL =
(DESCRIPTION =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST = stscan1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = srv.world)
)
)