Starting with Oracle Database 19c, properties for Oracle Data Guard configuration are stored in Oracle Database, instead of an external configuration file.

Oracle Data Guard property names, storage locations, and behaviors are changed in Oracle Database 19c.

Starting with Oracle Grid Infrastructure 19c, the desupport for direct placement of OCR and voting files on shared file systems is rescinded for Oracle Standalone Clusters.

In Oracle Grid Infrastructure 12c Release 2 (12.2), Oracle announced that it would no longer support the placement of the Oracle Grid Infrastructure Oracle Cluster Registry (OCR) and voting files directly on a shared file system. This desupport is now rescinded. Starting with Oracle Grid Infrastructure 19c (19.3), with Oracle Standalone Clusters, you can again place OCR and voting disk files directly on shared file systems. However, for Oracle Domain Services Clusters, you must continue to place OCR and voting files in quorum failure groups managed by Oracle Automatic Storage Management (Oracle ASM).

Starting with Oracle Grid Infrastructure 19c, the Grid Infrastructure Management Repository (GIMR) is optional for new installations of Oracle Standalone Cluster. Oracle Domain Services Clusters still require the installation of a GIMR as a service component.

The Oracle Standalone Cluster locally hosts the GIMR on an Oracle ASM disk group or a shared file system; this GIMR is a multitenant database with a single pluggable database (PDB). The global GIMR runs in an Oracle Domain Services Cluster. Oracle Domain Services Cluster locally hosts the GIMR in a separate Oracle ASM disk group. Client clusters, such as Oracle Member Cluster for Database, use the remote GIMR located on the Oracle Domain Services Cluster. For two-node or four-node clusters, hosting the GIMR for a cluster on a remote cluster reduces the overhead of running an extra infrastructure repository on a cluster. The GIMR for an Oracle Domain Services Cluster is a multitenant database with one PDB, and additional PDB for each member cluster that is added.

Starting with Oracle Database 19c Release Update (RU) 19.7, you can install Oracle Database Standard Edition 2 in high availability mode.

Standard Edition High Availability provides cluster-based failover for Standard Edition Oracle Databases using Oracle Clusterware.

Oracle Standard Edition High Availability benefits from the cluster capabilities and storage solutions that are already part of Oracle Grid Infrastructure, such as Oracle Clusterware, Oracle Automatic Storage Management (Oracle ASM) and Oracle ASM Cluster File System (Oracle ACFS).

Using integrated, shared, and concurrently mounted storage, such as Oracle ASM and Oracle ACFS for database files as well as for unstructured data, enables Oracle Grid Infrastructure to restart an Oracle Database on a failover node much faster than any cluster solution that relies on failing over and remounting volumes and file systems.

To manage the implementation of Oracle Database bug fixes that cause a SQL execution plan change, use DBMS_OPTIM_BUNDLE.

After you upgrade your database, the bug fix patches that can cause execution plan changes included in the Release Updates are installed disabled by default. These bug fixes will not be activated until you enable the fixes. You can either enable these fixes manually, or use the DBMS_OPTIM_BUNDLE package.

Oracle strongly recommends that you enable these disabled patches that you want to use in your production system, and test the use of these patches thoroughly as part of your upgrade test plan.

For more information about using DBMS_OPTIM_BUNDLE to enable patches that were disabled because they can change execution plans, see Oracle Database PL/SQL Packages and Types Reference, and My Oracle Support note 2147007.1.

Starting in Oracle Database 19c, several Oracle Data Guard broker properties associated with initialization parameters are deprecated. Their functionality is replaced with the new EDIT … SET PARAMETER command in DGMGRL.

The following Oracle Data Guard broker properties are deprecated in Oracle Database 19c:

• ArchiveLagTarget

• DataGuardSyncLatency

• LogArchiveMaxProcesses

• LogArchiveMinSucceedDest

• LogArchiveTrace

• StandbyFileManagement

• DbFileNameConvert

• LogArchiveFormat

• LogFileNameConvert

Using the current EDIT ... SET PROPERTY command with these properties continues to work. However, the update is automatically made with the new command, and the parameter data is now no longer be stored in the broker metadata file.

The InconsistentProperties property is also deprecated. This parameter now always has no value, because there can no longer be inconsistent values.

Using the new EDIT ... SET PARAMETER commands removes the possibility of inconsistent configuration data between the broker and a database. When you use the new EDIT...SET PARAMETER commands, you can change these parameters either by using either the new broker command, or by using the standard SQL*Plus ALTER SYSTEM command. However, when you use the broker command, you can be attached to any database in the configuration, and perform parameter changes to any other database in the configuration.

Starting in Oracle Database 19c, Logical Standby properties of Oracle Data Guard broker are deprecated.

The following Oracle Data Guard broker Properties that affect Logical Standby are deprecated:

• LsbyMaxEventsRecorded

• LsbyMaxServers

• LsbyMaxSga

• LsbyPreserveCommitOrder

• LsbyRecordAppliedDdl

• LsbyRecordSkippedDdl

• LsbyRecordSkipErrors

• LsbyParameter

Using the EDIT ... SET PROPERTY command continues to work. However, the data about the setting is no longer stored in the broker metadata file.  Instead, Oracle recommends that you use the SQL*Plus package DBMS_LOGSTDBY to change the Logical Standby properties. The Logical Standby properties for Oracle Data Guard broker can be desupported in a future release.

Directly using the SQL*Plus package DBMS_LOGSTDBY removes the possibility of inconsistent configuration data between the broker and a Logical Standby database, and provides one interface to manage a Logical Standby.

Using the Oracle ASM command-line utility ASMCMD command option pwcreate password to create ASM passwords is deprecated in Oracle Grid Infrastructure 19c (19.1).

The option to supply the password on the command line is still enabled in Oracle Database 19c. However, to enhance security, Oracle is deprecating this method of creating a new Oracle ASM password. It can be desupported in a future release. The pwcreate option of ASMCMD enables you to specify a password on the command line. However, if you run the command asmcmd pwcreate, and you do not provide the password on the command line, then you are now prompted for the password.

The addnode script is deprecated in Oracle Grid Infrastructure 19c. The functionality of adding nodes to clusters is available in the installer wizard.

The addnode script can be removed in a future release. Instead of using the addnode script (addnode.sh or addnode.bat), add nodes by using the installer wizard. The installer wizard provides many enhancements over the addnode script. Using the installer wizard simplifies management by consolidating all software lifecycle operations into a single tool.

The clone.pl script is deprecated in Oracle Database 19c. The functionality of performing a software-only installation, using the gold image, is available in the installer wizard.

The clone.pl script can be removed in a future release. Instead of using the clone.pl script, Oracle recommends that you install the extracted gold image as a home, using the installer wizard.

Oracle Fail Safe is deprecated as of Oracle Database 19c. It can be desupported and unavailable in a future release.

Oracle recommends that you evaluate other single-node failover options, such as Oracle RAC One Node.

To enhance security, starting with Oracle Database 19c, the ability to specify passwords from the Global Data Services Control Utility (GDSCTL) command-line when called from the operating system prompt is deprecated.

This deprecation applies only to password changes where GDSCTL is called from a user command-line prompt. For example, the following command is deprecated.

$ gdsctl add database -connect inst1 -pwd gsm_password

Specifying the password from the GDSCTL utility itself is still valid. For example, the following command is valid:

GDSCTL> add database -connect inst1 -pwd gsm_password

This deprecation addresses the security vulnerability when specifying passwords in GDSCTL commands called from the operating system prompt. Only enter the Global Data Services password only when GDSCTL prompts for it.

Flash-based Enterprise Manager Express is deprecated in Oracle Database 19c. Starting with Oracle Database 19c, Enterprise Manager Express uses Java JET technology for the user interface.

In accordance with industry standards, Oracle is deprecating Flash-based Oracle Enterprise Manager Express (Oracle EM Express). Starting with Oracle Database 19c, Oracle EM Express, the default management option for Oracle Database, is based on Java JET technology. In this initial release, there are some options available in Flash-based Oracle EM Express that are not available in the JET version. If necessary, use the following command to revert to Flash Oracle EM Express:

SQL> @?/rdbms/admin/execemx emx

To return to JET Oracle EM Express, use the following command:

SQL> @?/rdbms/admin/execemx omx

The Oracle Data Vault role DV_REALM_OWNER role is deprecated with no replacement.

The DV_REALM_OWNER role is used for realm management to manage database objects in multiple schemas that define a realm. Oracle has deprecated the use of this role. It can be removed in a future release.

In addition, the following DV_REALM_OWNER privileges are revoked from the DV_REALM_OWNER role: CREATE ROLE, ALTER ANY ROLE, DROP ANY ROLE, GRANT ANY ROLE, GRANT ANY PRIVILEGE, and GRANT ANY OBJECT PRIVILEGE. If needed, you can choose to grant these privileges to the DV_REALM_OWNER role. For example:

SQL> GRANT CREATE ROLE ON tablename TO DV_REALM_OWNER;

The Oracle Data Vault role DV_REALM_RESOURCE is deprecated with no replacement.

The DV_REALM_RESOURCE role is used for the management of realm resources. Oracle has deprecated the use of this role. It can be removed in a future release.

The Oracle Data Vault role DV_PUBLIC role is deprecated with no replacement.

The DV_PUBLIC role is still created during installation, but it is not granted any roles or privileges. All privileges that were granted to DV_PUBLIC in previous releases are now granted directly to the PUBLIC role. This role is obsolete, and can be removed in a future release.

Starting with Oracle Database 19c (19.3), the Oracle ACFS replication protocol repv1 is deprecated.

The initial ACFS replication protocol repv1 was released with Oracle Database 11g Release 2 (11.2). Oracle Database 12c Release 2 introduced a new ACFS replication protocol, Oracle ACFS snapshot-based replication (repv2). Oracle continued to use the same management interface. Starting with Oracle Database 19c, the earlier ACFS replication protocol (repv1) is deprecated. Update to snapshot-based replication.

Starting with Oracle Database 19c (19.3), Oracle ACFS Encryption is deprecated with no replacement on Oracle Solaris and Microsoft Windows.

Oracle ACFS Encryption on Oracle Solaris and Microsoft Windows is based on RSA technology. Retirement of RSA technology has been announced. Oracle ACFS Encryption continues to be supported on Linux, and is unaffected by this deprecation, because Linux uses an alternative technology.

Starting with Oracle Grid Infrastructure 19c (19.5), Oracle ASM Cluster File System (ACFS) is deprecated on Microsoft Windows.

Deprecating certain clustering features with limited adoption allows Oracle to focus on improving core scaling, availability, and manageability across all features and functionality. ACFS file systems on Microsoft Windows are deprecated, and can be desupported in a future release. Depending on the use case, to replace current ACFS file systems, Oracle recommends that you move to Oracle Automatic Storage Management (Oracle ASM), Oracle Database File System (DBFS), or Microsoft Windows shares.

Starting with Oracle Grid Infrastructure 19c (19.5), Oracle ASM Cluster File System (ACFS) Security (Vault) and ACFS Auditing are deprecated

Deprecating certain clustering features with limited adoption allows Oracle to focus on improving core scaling, availability, and manageability across all features and functionality. Oracle ACFS Security (Vault) and ACFS Auditing are deprecated, and can be desupported in a future release.

Starting with Oracle Grid Infrastructure 19c (19.5), Oracle ASM Cluster File System (ACFS) on Member Clusters (ACFS Remote) is deprecated.

Oracle ASM Cluster File System (ACFS) on Member Clusters (ACFS Remote) is deprecated, and can be removed in a future release. Deprecating certain clustering features with limited adoption allows Oracle to focus on improving core scaling, availability, and manageability across all features and functionality.

Starting with Oracle Grid Infrastructure 19c (19.5), Member Clusters, which are part of the Oracle Cluster Domain architecture, are deprecated.

Deprecating certain clustering features with limited adoption allows Oracle to focus on improving core scaling, availability, and manageability across all features and functionality. Oracle Cluster Domains consist of a Domain Services Cluster (DSC) and Member Clusters. The deprecation of Member Clusters affects the clustering used with the DSC, but not its ability to host services for other production clusters. Oracle recommends that you align your next software or hardware upgrade with the transition off Cluster Domain - Member Clusters.

Starting with Oracle Clusterware 19c (19.5), the integration of vendor or third party clusterware with Oracle Clusterware is deprecated.

The integration of vendor clusterware with Oracle Clusterware is deprecated, and can be desupported in a future release. Deprecating certain clustering features with limited adoption allows Oracle to focus on improving core scaling, availability, and manageability across all features and functionality. In the absence of an integration between different cluster solutions, the system is subject to the dueling cluster solutions issue: Independent cluster solutions can make individual decisions about which corrective actions must be taken in case of certain failures. To avoid conflicts, only one cluster solution should be active at any point in time. For this reason, Oracle recommends that you align your next software or hardware upgrade with the transition off of vendor cluster solutions.

Direct management of virtual machine (VM) resources using Oracle Clusterware is deprecated in Oracle Grid Infrastructure 19c, and can be removed in a future release.

Oracle continues to support the use of Oracle Clusterware to monitor and manage the availability of remotely deployed Oracle VMs. However, this support will be removed in an upcoming release.

The Oracle Database initialization parameter CLUSTER_DATABASE_INSTANCES is deprecated in Oracle Database 19c (19.1)

The init.ora parameter CLUSTER_DATABASE_INSTANCES specifies the number of configured Oracle Real Application Clusters (Oracle RAC) instances. Starting with Oracle Database 19c and later releases, the number of configurable Oracle RAC instances is derived automatically from the Oracle Clusterware resource definitions. There is no replacement for this parameter, because there is no longer a reason to have this parameter.

The SQLNET.ENCRYPTION_WALLET_LOCATION sqlnet.ora parameter is deprecated in Oracle Database 19c.

The SQLNET.ENCRYPTION_WALLET_LOCATION parameter defines the location of the software keystores for Transparent Data Encryption (TDE). To configure the software keystore location, instead of setting SQLNET.ENCRYPTION_WALLET_LOCATION, Oracle recommends that you set the WALLET_ROOT initialization parameter, and the TDE_CONFIGURATION dynamic initialization parameter.

Oracle recommends that you use the WALLET_ROOT instance initialization parameter as soon as possible, because the value is read once at instance startup time, so all sessions and server background processes share the same path after startup. If the SQLNET.ENCRYPTION_WALLET_LOCATION parameter is used, then it can lead to confusing misconfigurations, because different sessions can have different SQLNET parameter values. Another reason to use WALLET_ROOT is that it is the directory within which you can locate the wallets of other features, such as Oracle Enterprise User Security, and Transport Layer Security. This location can become the principal location for all server-side wallets.

Starting with Oracle Database 19c, customer use of the SERVICE_NAMES parameter is deprecated. It can be desupported in a future release.

The use of the SERVICE_NAMES parameter is no longer actively supported. It must not be used for high availability (HA) deployments. It is not supported to use service names parameter for any HA operations. This restriction includes FAN, load balancing, FAILOVER_TYPE, FAILOVER_RESTORE, SESSION_STATE_CONSISTENCY, and any other uses.

To manage your services, Oracle recommends that you use the SRVCTL or GDSCTL command line utilities, or the DBMS_SERVICE package.

The Oracle Data Provider for .NET PromotableTransaction setting is desupported because it is no longer necessary. All compatible database server versions support transaction promotion.

The Oracle Data Provider for .NET registry, configuration, and property setting PromotableTransaction indicates whether the application must keep transactions as local, or if it can begin all single connection transactions as local, and then promote the transaction to distributed when a second connection enlists. This is the concept of promotable transactions.

The PromotableTransaction setting is desupported in Oracle Data Provider for .NET 18c, because all database versions compatible with this provider version support promotable transactions. Developers no longer need to use this setting if they employ promotable transactions. Existing applications remain unaffected, whether they use promotable transactions or not.

Oracle Multimedia is desupported in Oracle Database 19c, and the implementation is removed.

As an alternative for image processing and conversion, Oracle recommends that you store multimedia content in SecureFiles LOBs, and use third party products, such as APEX Media Extension (AME). The ORDIM component remains in the registry and still has a VALID status. Oracle Multimedia objects and packages remain in the database. However, these objects and packages no longer function, and raise exceptions if there is an attempt made to use them. Oracle Locator is not affected by the desupport of Oracle Multimedia.

The continuous_mine option for the dbms_logmnr.start_logmnr package is desupported in Oracle Database 19c, and is no longer available.

The continuous_mine functionality of the LogMiner package is obsolete. It was deprecated in Oracle Database 12c Release 2 (12.2). There is no replacement functionality.

The Extended Datatype Support (EDS) feature is desupported in Oracle Database 19c. All Data types that the EDS feature supported are now supported natively by both Logical Standby and Oracle GoldenGate.

The Extended Datatype Support (EDS) feature provides a mechanism for logical standbys to support certain Oracle data types that lack native redo-based support. For example, EDS was used to replicate tables with a SDO_GEOMETRY column. However, starting with Oracle Database 12c Release 2 (12.2), there are no EDS-supported Oracle data types that are not supported natively, either by Logical standby, or by Oracle GoldenGate. This feature is desupported with Oracle Database 19c (19.1).

Starting in Oracle Database 19c, the Oracle Data Guard broker MAX_CONNECTIONS attribute is desupported.

The Oracle Data Guard broker MaxConnections property ( pertaining to the MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n parameter) is desupported in Oracle Database 19c. It is removed. Using commands to set this property from DGMGRL returns errors.

Leaf nodes are no longer supported in the Oracle Flex Cluster Architecture in Oracle Grid Infrastructure 19c.

In Oracle Grid Infrastructure 19c (19.1) and later releases, all nodes in an Oracle Flex Cluster function as hub nodes. The capabilities offered by Leaf nodes in the original implementation of the Oracle Flex Cluster architecture can as easily be served by hub nodes. Therefore, leaf nodes are no longer supported.

Starting in Oracle Database 19c (19.1), Oracle Streams is desupported. Oracle GoldenGate is the replication solution for Oracle Database.

Note that Oracle Database Advanced Queuing is not deprecated, and is fully supported in Oracle Database 19c. Oracle Streams did not support features added in Oracle Database 12c (12.1) and later releases, including the multitenant architecture, LONG VARCHAR, and other new features. Oracle Streams replication functionality is superseded by GoldenGate.

Starting in Oracle Database 19c, the SQL*Plus table PRODUCT_USER_PROFILE (PUP table) is desupported.

The SQL*Plus product-level security feature is unavailable in Oracle Database 19c. Oracle recommends that you protect data by using Oracle Database settings, so that you ensure consistent security across all client applications.

Starting with Oracle Database 19c, Oracle Real Application Clusters (Oracle RAC) is not supported in Oracle Database Standard Edition 2 (SE2).

Upgrading Oracle Database Standard Edition databases that use Oracle Real Application Clusters (Oracle RAC) functionality from earlier releases to Oracle Database 19c is not possible. To upgrade those databases to Oracle Database 19c, either remove the Oracle RAC functionality before starting the upgrade, or upgrade from Oracle Database Standard Edition to Oracle Database Enterprise Edition. For more information about each step, including how to reconfigure your system after an upgrade, see My Oracle Support Note 2504078.1: "Desupport of Oracle Real Application Clusters (RAC) with Oracle Database Standard Edition 19c."

The ability to create flat file dictionary dumps of pluggable databases (PDBs) is desupported in Oracle Database 19c.

In previous releases, using a flat file dictionary was one means of mining the redo logs for the changes associated with a specific PDB whose data dictionary was contained within the flat file. This feature is now desupported. With Oracle Database 19c and later releases, Oracle recommends that you call DBMS_LOGMNR.START_LOGMNR, and supply the system change number (SCN) or time range that you want to mine. The SCN or time range options of START_LOGMNR are enhanced to support mining of individual PDBs.

The Oracle Exadata Database Machine initialization parameter EXAFUSION_ENABLED is desupported in Oracle Database 19c.

The Exafusion feature was introduced for Oracle Database 12c Release 1 (12.1.0.2), but disabled by default. It was only available for the Linux operating system, and only available with Oracle Exadata Database Machine. You could enable this feature by setting the EXAFUSION_ENABLED initialization parameter to 1. With Oracle Database 12c Release 2 (12.2), the feature became enabled by default on Oracle Exadata Database Machine running on Oracle Linux. You could disable this feature by changing the EXAFUSION_ENABLED parameter setting to 0. However, with Oracle Database 18c and later releases, the Exafusion feature cannot be disabled. For this reason, the EXAFUSION_ENABLED parameter is desupported in Oracle Database 19c, because the parameter no longer serves a function.

The MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n parameters for Oracle Data Guard Redo Transport is obsolete. It is desupported in Oracle Database 19c.

The MAX_CONNECTIONS attribute can interfere with the new Redo Transport Streaming mechanism introduced in Oracle Database 11g, and increase the time necessary to resolve gaps. To prevent these types of errors, Oracle has desupported and removed this attribute.

The initialization parameter O7_DICTIONARY_ACCESSIBILITY is desupported in Oracle Database 19c.

The O7_DICTIONARY_ACCESSIBILITY parameter controlled restrictions on System Privileges from accessing SYS owned objects. It was retained to enable certain backward compatibility for earlier release applications. Desupporting obsolete features enables Oracle to focus on security across all features and functionality. Oracle recommends that you manage system privileges in accordance with standard security best practices.

OPTIMIZE_PROGRESS_TABLE for Oracle GoldenGate Integrated Replicat, XStream In, and Logical Standby, is desupported in Oracle Database 19c.

The apply parameter OPTIMIZE_PROGRESS_TABLE for Oracle GoldenGate Integrated Replicat, XStream In, and Logical Standby, is desupported in Oracle Database 19c. Before you upgrade to Oracle Database 19, you must turn off this parameter. If OPTIMIZE_PROGRESS_TABLE is set to ON, then stop apply gracefully, turn off the parameter, and restart apply. For GoldenGate Apply and XStream, this parameter is set to OFF by default.

Starting with Oracle Database 18c, installation and configuration of Oracle Database software is simplified with image-based installation.

Starting with Oracle Database 18c, the Oracle Database software is available as an image file for download and installation. You must extract the image software into the directory where you want your Oracle home to be located, and then run the runInstaller script to start the Oracle Database installation. For details, refer to your operating system platform Oracle Database Installation Guide.

If you use JSON keys, then you can take advantage of increased efficiency of searching JSON documents generated from HASH MAP-like structures by using longer key names.

The upper limit is increased for JSON key names that can be indexed by the JSON Search index. The JSON key name upper limit in Oracle Database 12c Release 2 (12.2.0.2) and later releases is 255 bytes. In previous releases, JSON search indexes that were created did not index key names greater than 64 bytes.

Starting with Oracle Database 18c, existing services are no longer migrated by the installation. Use Database Upgrade Assistant (DBUA) to migrate services.

If you have an existing Oracle Database with services that you want to migrate, then to migrate those services, you must install the new release Oracle Database software in the Oracle home, and then start DBUA.

On Windows, to migrate the Microsoft Transaction Service to the new Oracle home, you must also run the command %ORACLE_HOME%\bin\oramtsctl.exe -new

Starting with Oracle Database 18c, you can install a single-instance Oracle Database or an Oracle Database Instant Client software using RPM packages.

An RPM-based installation performs preinstallation checks, extracts the database software, reassigns ownership of the extracted software to the preconfigured user and groups, maintains the Oracle inventory, and executes all root operations required to configure the Oracle Database software for a single-instance Oracle Database creation and configuration.

The RPM–based installation process detects when the minimum requirements for an installation are not met and prompts you to finish these minimum preinstallation requirements.

An RPM-based installation performs a software-only Oracle Database installation and creates an Oracle home. After the Oracle home is created, you can then use Oracle Database Configuration Assistant (Oracle DBCA) to create an Oracle Database.

The RPM-based installation process provides you with the option to create a database with the default settings using the /etc/init.d/oracledb_ORCLCDB-19c service configuration script.

Starting with Oracle Database Release 18c, the indexed token maximum size is increased to 255 characters for single-byte character sets.

Before Oracle Database Release 18c, all Oracle Text index types except SDATA sections stored tokens in a table column of type VARCHAR2 (64 BYTE). Starting with Oracle Database Release 18c, all Oracle Text index types except CTXCAT and CTXRULE indexes store tokens in VARCHAR2 (255 BYTE) table column types. This change is an increase for the maximum size of an indexed token to 255 characters for single-byte character sets. The size increase is less with multibyte or variable-length character sets. Tokens longer than 255 bytes are truncated. Truncated tokens do not prevent searches on the whole token string. However, the system cannot distinguish between two tokens that have the same first 255 bytes.

SDATA sections store tokens in a table column of type VARCHAR2 (249 BYTE). CTXCAT and CTXRULE indexes store tokens in a table column of type VARCHAR2 (64 BYTE).

Starting in Oracle Database 18c, there are changes to the /USER/ALL/DBA_ARGUMENTS and /USER/ALL/DBA_IDENTIFIERS views, and to LIBRARY object creation in PDBs.

Review the changes that can affect your work.

Type Level2Record is RECORD (Field1 NUMBER);
Type Level1Collection is TABLE of Level2Record index by binary_integer;
Type Level0Record is RECORD (Field1 Level1Collection);
Procedure NestedTypesProc (Param1 Level0Record);

SQL> select argument_name,type_subname,position,sequence,data_level from user_arguments where object_name='NESTEDTYPESPROC';
ARGUMENT_NAME   TYPE_SUBNAME      POSITION   SEQUENCE  DATA_LEVEL 
--------------- ----------------- ---------- ---------- --------- 
PARAM1          LEVEL0RECORD             1          1           0
FIELD1          LEVEL1COLLECTION         1          2           1 
                LEVEL2RECORD             1          3           2
FIELD1                                   1          4           3

ARGUMENT_NAME   TYPE_SUBNAME      POSITION   SEQUENCE  DATA_LEVEL 
--------------- ----------------- ---------- ---------- --------- 
PARAM1          LEVEL0RECORD             1          1           0

You cannot use UTL_FILE with symbolic links. Use directory objects instead.

The UTL_FILE_DIR symbolic link path is desupported in Oracle Database 18c and later releases. After an upgrade if applications address the database using symbolic links through UTL_FILE, then these links fail. Oracle recommends that you use directory objects. If necessary, you can create real files that are the targets of file names in UTL_FILE.

This desupport can affect any feature from an earlier release using symbolic links, including (but not restricted to) Oracle Data Pump, BFILEs, and External Tables. If you attempt to use an affected feature after upgrade, where that feature used symbolic links, you encounter ORA-29283: invalid file operation: path traverses a symlink. Before upgrade, to help you to identify symbolic link that you need to correct, use the Preupgrade Information Tool (preupgrade.jar). Oracle recommends that you instead use directory objects in place of symbolic links.

create or replace directory TEMP as '/home/PLSQL/TEMP';

declare
f utl_file.file_type;
begin
f := utl_file.fopen('TEMP','la.c','r');
end;
/

ERROR at line 1: 
ORA-29283: invalid file operation 
ORA-06512: at "SYS.UTL_FILE", line 536 
ORA-29283: invalid file operation 
ORA-06512: at line 4

Using Database Configuration Assistant (DBCA) to register Oracle Database to Oracle Internet Directory (OID) is deprecated in Oracle Database 18c.

Instead of using DBCA to migrate or register listeners to a database home during an upgrade, use Net Configuration Assistant or Net Manager to create a LISTENER.ORA file for the new release Oracle home, and then start this listener. You can also use DBCA to de-register and register listeners again to OID.

By default, the format of timestamps is different in Oracle Database 12c release 2 (12.2) and later releases. To view alert logs, use the Oracle Database utility Automatic Diagnostic Repository Command Interpreter (ADRCI) utility.

If you use scripts to parse the alert log for timestamp dates, then be aware that the default value for timestamp formats is set by the init.ora parameter UNIFORM_LOG_TIMESTAMP_FORMAT. The default value for this parameter is TRUE. When TRUE, the timestamp format changes from a day-month-year-time format to a year-month-day-time format. For example: 2017-05-17T10:00:54.799968+00:00.

You can change to the timestamp format used in previous releases by changing the value of UNIFORM_LOG_TIMESTAMP_FORMAT to FALSE. You can also use scripts to parse log.xml instead of the alert log.

Oracle provides a dedicated command-line utility to find and analyze Oracle errors and tracefiles, called Automatic Diagnostic Repository Command Interpreter (ADRCI) Oracle recommends that you use the ADRCI utility for error management.

For example, you can use the ADRCI command show alert to view the alert log:

$ oracle@user> adrci
adrci> show alert -tail -f

ADRCI also enables you to use the show log command to pass predicates for a query. For example:

adrci> show log -p "message_text like '%tablespace%'"

Refer to Oracle Database Utilities for more information about how to use the ADRCI utility.

The MAX_CONNECTIONS attribute of the LOG_ARCHIVE_DEST_n parameter for Data Guard redo transport is deprecated in Oracle Database 18c.

Oracle Database 11g Release 1 (11.1) introduced the new streaming asynchronous model for redo transport. Using the MAX_CONNECTIONS attribute setting no longer provides any benefit when Oracle Data Guard is resolving gaps in the archive log files.

Extended Datatype Support (EDS) is deprecated in Oracle Database 18c .

The Extended Datatype Support (EDS) feature provides a mechanism for logical standbys to support certain Oracle data types that lack native redo-based support. For example, EDS was used to replicate tables with SDO_GEOMETRY column. However, starting with Oracle Database 12c Release 2 (12.2), there are no EDS-supported Oracle data types that are not supported natively by Logical data or GoldenGate. This feature is now obsolete.

Starting in Oracle Database 18c, the GET_* functions in DBMS_DATA_MINING are deprecated. Use the Oracle Data Mining (ODM) Model Details views instead.

In Oracle Database 12c Release 1, and earlier releases, the DBMS_DATA_MINING package supports a separate GET_MODEL_DETAILS function for each data mining algorithm. Global details are also available for Generalized Linear Models, Expectation Maximization, Singular Value Decomposition, and Association Rules. There are many DBMS_DATA_MINING Get_* functions. For example:

• GET_MODEL_DETAILS

• DBMS_DATA_MINING.GET_MODEL_TRANSFORMATIONS

For example, the Model detail view for Decision Tree describes the split information view, node statistics view, node description view, and the cost matrix view.

Starting with Oracle Database 18c, Oracle recommends that you replace the GET_MODEL_DETAILS_XML functions with the Oracle Data Mining Model Details views. The split information view DM$VPmodel_name describes the decision tree hierarchy, in which you append the name of the Oracle Data Mining model to the view prefix.

The PL/SQL package DBMS_XMLQUERY is deprecated in Oracle Database 18c. Use DBMS_XMLGEN instead.

DBMS_XMLQUERY provides database-to-XMLType functionality. Oracle recommends that you replace calls to DBMS_XMLQUERY with DBMS_XMLGEN. DBMS_XMLGEN is written in C, and compiled into the kernel, so it provides higher performance.

The PL/SQL package DBMS_XMLSAVE is deprecated in Oracle Database 18c. Use DBMS_XMLSTORE instead.

The DBMS_XMLSAVE package is part of the Oracle XML SQL Utility. It is used to insert, update, and delete data from XML documents in object-relational tables. Oracle recommends that you replace DBMS_XMLSAVE calls with DBMS_XMLSTORE. DBMS_XMLSTORE is written in C, and compiled into the kernel, so it provides higher performance.

For example: to replace DBMS_XMLSAVE, you can create a wrapper function or procedure that you used to call DBMS_XMLSAVE on an earlier release Oracle Database, and change the call to DBMS_XMLSTORE. Or you can create a synonym:

CREATE OR REPLACE PUBLIC SYNONYM DBMS_XMLSAVE FOR DBMS_XMLSTORE;
GRANT EXECUTE ON DBMS_XMLSAVE TO PUBLIC;

Starting in Oracle Database 18c, The LABELS column is deprecated in the ALL_SA_USER_LABELS and DBA_SA_USER_LABELS views.

The information in the LABELS and USER_LABELS columns is redundant. This information is displayed in other columns in these data dictionary views.

Starting with Oracle Database 18c , the option to specify a SQL NUMBER value (1 or 0) as the return value of a JSON value of true or false is deprecated.

Oracle Database 12c release 1 (12.1) provided support for JSON data, including the function of specifying NUMBER as the type of a column that is returned. The option to specify NUMBER is deprecated. Instead of specifying NUMBER as the output for JSON data for true/false queries, you can use the default SQL value returned for a JSON Boolean value, and specify the string as  'true' or 'false'. If you have an application that requires a numeric value, then you can return the Boolean JSON value as a SQL VARCHAR2 value, and then test that value and return a SQL NUMBER value as the result of that test.

Starting with Oracle Database 18c, the use of MAIL_FILTER in Oracle Text is deprecated. Before adding email to the database, filter e-mails to indexable plain text, or to HTML.

MAIL_FILTER is based on an obsolete email protocol, RFC-822. Modern email systems do not support RFC-822. There is no replacement.

Starting with Oracle Database 18c, the command options for asmcmd showversion are replaced with new asmcmd options.

In place of the command asmcmd showversion --softwarepatch, use the new option asmcmd showpatches -l. In place of the command asmcmd showversion --releasepatch, use the new option asmcmd showversion --active.

Starting with Oracle Database 18c, use of NEWS_SECTION_GROUP is deprecated in Oracle Text. Use external processing instead.

If you want to index USENET posts, then preprocess the posts to use BASIC_SECTION_GROUP or HTML_SECTION_GROUP within Oracle Text. USENET is rarely used commercially.

USENET currently is rarely used for serious purpose. Performing index processing using this section group type is obsolete.

Starting with Oracle Database 18c, the Oracle Net Services support for Sockets Direct Protocol (SDP) is deprecated.

Oracle recommends that you use TCP as an alternative.

Starting with Oracle Database 18c, Leaf nodes are deprecated as part of Oracle Flex Cluster architecture.

With continuous improvements in the Oracle Clusterware stack towards providing shorter reconfiguration times in case of a failure, Leaf nodes are no longer necessary for implementing clusters that meet customer needs, either for on-premises, or in the Cloud.

Starting in Oracle Database 18c, the  SQL*Plus table PRODUCT_USER_PROFILE (PUP) table is deprecated.

The only use for the PRODUCT_USER_PROFILE (PUP) table is to provide a mechanism to control product-level security for SQL*Plus. Starting with Oracle Database 18c, this mechanism is no longer relevant. This SQL*Plus product-level security feature will be unavailable in Oracle Database 19c. Oracle recommends that you protect data by using Oracle Database settings, so that you ensure consistent security across all client applications.

The Oracle Administration Assistant tool for Windows is desupported in Oracle Database 18c.

Oracle Administration Assistant for Windows is desupported in the current database release. Oracle Administration Assistant for Windows was a tool for creating database administrators, operators, users, and roles in Windows. Oracle Administration Assistant also enabled database services, startup and shutdown configurations, and Windows Registry parameter management. There is no replacement.

Several Oracle Multimedia DICOM features are desupported in Oracle Database 18c. Replace DICOM with Oracle SecureFiles and third-party DICOM products.

Digital Imaging and Communications in Medicine (DICOM) is a medical imaging technology that supports the connectivity of radiological devices. Oracle’s native DICOM feature is deprecated, and parts of it are desupported in this release. The desupport of Oracle Multimedia DICOM includes the following features:

• Oracle Multimedia DICOM protocol

• Oracle Multimedia DICOM mid-tier support

• Oracle Multimedia Oracle DICOM Component for WebCenter integration (DICOM/UCM)

The following Oracle Multimedia DICOM features continue to be deprecated:

• DICOM support in Oracle Multimedia ORDImage object

• Oracle Multimedia DICOM objects and packages

There is no replacement for Oracle Multimedia DICOM. Oracle recommends that you replace Oracle Multimedia DICOM by using Oracle SecureFiles with third-party products for DICOM functionality. For example: Use third-party DICOM features to carry out metadata management, DICOM image conversion, and so on.

Oracle Multimedia proxy classes and Oracle Multimedia servlet and JSP classes are desupported.

Oracle Multimedia Java client is desupported in Oracle Database 18c for the following classes:

• Oracle Multimedia proxy classes, including DICOM proxy classes

• Oracle Multimedia servlet/jsp classes

To develop Java applications that manage multimedia content within Oracle Databases, Oracle recommends that you embed PL/SQL blocks in Java.

Starting withOracle Database 18c, schema subprograms in DBMS_XMLSCHEMA, many DBMS_XDB subprograms, and many other Oracle XML DB schema features are desupported.

In Oracle Database 12c release 1 (12.1), the PL/SQL package DBMS_XDB_CONFIG was introduced. At the same time, all Oracle XML DB configuration functions, procedures, and constants that were moved from package DBMS_XDB to DBMS_XDB_CONFIG. were deprecated, and a series of other DBMS_XMLSCHEMA, DBMS_XDB subprograms, and other schema features were deprecated. These components are now desupported.

Oracle is desupporting the Oracle.ManagedDataAccessDTC.dll file in Oracle Database 18c.

Oracle provided a native managed distributed transaction support for Oracle Data Provider for .NET (ODP.NET), Managed Driver using Oracle.ManagedDataAccessDTC.dll. In .NET Framework 4.5.2, Microsoft introduced its own native managed distributed transaction implementation, which managed ODP.NET used. The new .NET Framework made the Oracle.ManagedDataAccessDTC.dll unnecessary. Moreover, Microsoft has desupported all .NET Framework 4 versions earlier than 4.5.2. In accordance with Microsoft policy, Oracle is desupporting the Oracle.ManagedDataAccessDTC.dll file.

The desupport includes removing the UseManagedDTC .NET configuration file parameter, and Oracle.ManagedDataAccessDTC.dll.

Starting with Oracle Database 18c, the Oracle Data Guard broker ALTER command in DGMGRL is desupported.

The ALTER command syntax in the Data Guard broker DGMGRL command-line interface was deprecated in Oracle Database 10g Release 1 and replaced with the EDIT CONFIGURATION, EDIT DATABASE, and EDIT INSTANCE syntax.

The crsuser utility and the CRSToken method to change the Windows service user is desupported in Oracle Database 18c.

In Oracle Grid Infrastructure releases before Release 12c (12.1), it was supported to use the crsuser utility with Oracle Real Application Clusters (Oracle RAC) to modify the database logon properties of the Oracle Database service from LocalSystem to a user ID.

Oracle introduced the Oracle Home User system privileges role for the DB home in Oracle Grid Infrastructure 12c Release 1 (12.1). This role makes the need for the crsuser functionality unnecessary. The crsuser facility was also previously used to create user-defined CRS resources that ran as a Windows user other than LocalSystem. However, Oracle Grid Infrastructure 12c Release 1 (12.1) and later releases provide that same functionality with crsctl add wallet -type OSUSER The crsuser feature no longer works. It is no longer developed or supported.

For more information about the crsctl add wallet -type OSUSER command, refer to Oracle Clusterware Administration and Deployment.

Support for the initialization parameter STANDBY_ARCHIVE_DEST is removed in Oracle Database 18c.

Oracle Database 11g Release 2 (11.2) included an increase to 31 of the parameters LOCAL and REMOTE archiving LOG_ARCHIVE_DEST_n. This increase, and the ALTERNATE attribute enhancements to provide high availability for local and remote archiving, provides you with more control over the results after an archiving destination fails. Because of these enhancements, STANDBY_ARCHIVE_DEST is not required or practical to use.

Starting in Oracle Database 18c, the UTL_FILE_DIR parameter is no longer supported. Instead, specify the name of a directory object.

The UTL_FILE_DIR initialization parameter is no longer listed in V$SYSTEM_PARAMETER and related views. If you attempt to set this parameter, then the attempt fails. If you attempt to specify an operating system file directly by using the LOCATION parameter of UTL_FILE.FOPEN, or by using the LOCATION parameter of FOPEN_NCHAR, then those attempts also fail. Specify the name of a directory object instead.

The security model for the use of a directory object for UTL_FILE and other Oracle Database subsystems is secure, because there is a clear privilege model. However, the use of an explicit operating system directory is insecure, because there is no associated privilege model. The notice of deprecation for the UTL_FILE_DIR initialization parameter was given in Oracle Database 12c Release 2 (12.2). With Oracle Database 18c, the parameter is now desupported.

Review this list of initialization parameter default setting changes for Oracle Database 12c release 2 (12.2).

Oracle Database 12c release 2 (12.2) includes several enhancements to DBUA, and some features have been removed or modified.

In response to customer requests, and to improve functionality, Database Upgrade Assistant (DBUA) includes new features and code enhancements. Also, some features in previous releases have been removed.

Starting with Oracle Database 12c release 2 (12.2), Oracle Data Guard Broker has more features to assist rolling upgrades.

Oracle Data Guard Broker now supports Oracle Active Data Guard rolling upgrade. Oracle Active Data Guard rolling upgrade was introduced in Oracle Database 12c release 1 (12.1). It simplifies the execution of the transient logical database rolling upgrade process by automating many manual steps in a simple PL/SQL package (DBMS_ROLLING). In addition to making database rolling upgrades simpler, the automated process is much more reliable. Oracle Data Guard broker can now direct Oracle Active Data Guard rolling upgrades from the DGMGRL command-line interface. Broker support also adds substantial simplification to the rolling upgrade process by transparently handling redo transport destination settings and other tasks.

In Oracle Database 12c release 2 (12.2) and later releases, when you perform a rolling upgrade using the DBMS_ROLLING PL/SQL package, you no longer have to disable the broker. In addition, the broker now reports when a rolling upgrade is in place, and tracks its status. The status information is displayed in the output of the DGMGRL commands SHOW CONFIGURATION and SHOW DATABASE.

Using Oracle Data Guard Broker to manage database rolling upgrades can simplify the upgrade process by minimizing your downtime and risk when introducing change to production environments.

Starting with Oracle Database 12c Release 2 (12.2.0.1), by default, permissions to read and write to the System Global Area (SGA) are limited to the Oracle software installation owner.

In previous releases, both the Oracle installation owner account and members of the OSDBA group had access to shared memory. The change in Oracle Database 12c Release 2 (12.2) and later releases to restrict access by default to the Oracle installation owner account provides greater security than previous configurations. However, this change may prevent DBAs who do not have access to the Oracle installation owner account from administering the database.

The Oracle Database initialization parameter ALLOW_GROUP_ACCESS_TO_SGA determines if the Oracle Database installation owner account (oracle in Oracle documentation examples) is the only user that can read and write to the database System Global Area (SGA), or if members of the OSDBA group can read the SGA. In Oracle Database 12c Release 2 (12.2) and later releases, the default value for this parameter is FALSE, so that only the Oracle Database installation owner has read and write permissions to the SGA. Group access to the SGA is removed by default. This change affects all Linux and UNIX platforms.

If members of the OSDBA group require read access to the SGA, then you can change the initialization parameter ALLOW_GROUP_ACCESS_TO_SGA setting from FALSE to TRUE. Oracle strongly recommends that you accept the default permissions that limit access to the SGA to the oracle user account.

Network access control lists (ACLs) are implemented as Real Application Security ACLs in 12c, and existing ACLs are migrated from XML DB ACLs and renamed during upgrade.

During Oracle Database upgrades to 12c Release 1 (12.1) and later releases, network access control in Oracle Database is implemented using Real Application Security access control lists (ACLs). Existing ACLs in XDB are migrated during upgrade. Existing APIs in the DBMS_NETWORK_ACL_ADMIN PL/SQL package and catalog views are deprecated. These deprecated views are replaced with new equivalents in Oracle Database 12c.

Starting with Oracle Database 12c Release 1 (12.1), you can grant network privileges by appending an access control entry (ACE) to a host ACL using DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE. If you append an ACE to a host that has no existing host ACL, then a new host ACL is created implicitly. If the host ACL exists, then the ACEs are appended to the existing ACL.

In Oracle Database 12c Release 2 and later releases, you can run the Parallel Upgrade Utility using command-line batch scripts.catupgrd.sql is no longer distributed.

In Oracle Database 12c Release 2 (12.2) and later releases, you can run the Parallel Upgrade Utility (catctl.pl) from the command line by entering the shell commands dbupgrade for Linux and Unix, and dbupgrade.com for Microsoft Windows. These shell scripts call the catctl.pl script from the upgrade binary home. You can either run these scripts with default values, or you can run them with the same input parameters that you use to run catctl.pl from the Perl prompt.

Oracle update batching settings are disabled in Oracle Database 12c release 2 (12.2). Use JDBC batching instead.

Oracle update batching was deprecated in Oracle Database 12c Release 1 (12.1). Starting in Oracle Database 12c Release 2 (12.2), Oracle update batching is a no operation code (no-op). This means that if you implement Oracle update batching in your application using the Oracle Database 12c Release 2 (12.2) JDBC driver, then the specified batch size is not set, and results in a batch size of 1. With this batch setting, your application processes one row at a time. Oracle strongly recommends that you use the standard JDBC batching if you are using the Oracle Database 12c Release 2 (12.2) JDBC driver.

Starting with Oracle Database 12c release 2 (12.2), you can run the Parallel Upgrade Utility with the -T option to set tables to READ ONLY.

When you run the Parallel Upgrade Utility with the -T option, any tablespaces that do not contain Oracle Maintained objects are set to READ ONLY. Setting these tables to READ ONLY can reduce the amount of data that you need to back up before upgrading the database.

If your database has user tables that depend on Oracle Maintained types (for example, AQ queue tables), then you must upgrade these tables manually after upgrade.

After the upgrade is complete, to upgrade tables dependent on Oracle-Maintained types, run the script utluptabdata.sql to carry out ALTER TABLE UPGRADE commands on tables in tablespaces set to READ ONLY during the upgrade.

Starting with Oracle Database 12c release 2, the ALTER TYPE statement behavior is also changed. If a dependent table is in an accessible tablespace, then it is automatically upgraded to the new version of the type. If the dependent table is in a READ ONLY tablespace, then it is not automatically upgraded. Run the utluptabdata.sql script to upgrade those tables set to READ ONLY tablespace states during the upgrade. You only need to run the utluptabdata.sql script when you run the Parallel Upgrade Utility with the -T option to run the upgrade.

The Oracle Database 12c release 2 (12.2) default authentication protocol is 12 (Exclusive Mode). This protocol requires case-sensitive passwords for authentication. Review your options if you have earlier release password versions.

Starting with Oracle Database 12c release 2 (12.2), the default value for the SQLNET.ORA parameter ALLOWED_LOGON_VERSION_SERVER is changed to 12. This parameter refers to the logon authentication protocol used for the server, not the Oracle Database release.

By default, Oracle no longer supports case-insensitive password-based authentication; only the new password versions (11G and 12C) are allowed. The case-insensitive 10G password version is no longer generated.

If the following conditions are true, then you may have accounts that are prevented from logging into the database after upgrading to 12.2:

• You are upgrading a server that has user accounts created in an earlier Oracle Database release.

• User accounts created in the earlier release use a case-insensitive password version from an earlier release authentication protocol, such as the 10G password version.

• Earlier release user accounts have not reset passwords.

• The server has been configured with SEC_CASE_SENSITIVE_LOGON set to FALSE, so that it can only authenticate users who have a 10G case-insensitive password version.

If you have accounts that require 10G password versions, then to prevent accounts using that password version from being locked out of the database, you can change from an Exclusive Mode to a more permissive authentication protocol.

Oracle Fleet Patching and Provisioning (Oracle FPP) is a software lifecycle management method for provisioning and maintaining Oracle homes. Oracle Fleet Patching and Provisioning enables mass deployment and maintenance of standard operating environments for databases, clusters, and user-defined software types.

Oracle Fleet Patching and Provisioning enables you to install clusters, and provision, patch, scale, and upgrade Oracle Grid Infrastructure, Oracle Restart, and Oracle Database homes. The supported versions are 11.2, 12.1, 12.2, 18c, and 19c. You can also provision applications and middleware using Oracle Fleet Patching and Provisioning.

Oracle Fleet Patching and Provisioning is a service in Oracle Grid Infrastructure that you can use in either of the following modes:

• Central Oracle Fleet Patching and Provisioning Server

  The Oracle Fleet Patching and Provisioning Server stores and manages standardized images, called gold images. Gold images can be deployed to any number of nodes across the data center. You can create new clusters and databases on the deployed homes and can use them to patch, upgrade, and scale existing installations.

  The Oracle Fleet Patching and Provisioning Server can manage the following types of installations:

  • Software homes on the cluster hosting the Oracle Fleet Patching and Provisioning Server itself.

  • Oracle Fleet Patching and Provisioning Clients running Oracle Grid Infrastructure 12c Release 2 (12.2), 18c, and 19c.

  • Installations running Oracle Grid Infrastructure 11g Release 2 (11.2) and 12c Release 1 (12.1).

  • Installations running without Oracle Grid Infrastructure.

  The Oracle Fleet Patching and Provisioning Server can provision new installations and can manage existing installations without requiring any changes to the existing installations. The Oracle Fleet Patching and Provisioning Server can automatically share gold images among peer servers to support enterprises with geographically distributed data centers.

• Oracle Fleet Patching and Provisioning Client

  The Oracle Fleet Patching and Provisioning Client can be managed from the Oracle Fleet Patching and Provisioning Server, or directly by executing commands on the client itself. The Oracle Fleet Patching and Provisioning Client is a service built into the Oracle Grid Infrastructure and is available in Oracle Grid Infrastructure 12c Release 2 (12.2) and later releases. The Oracle Fleet Patching and Provisioning Client can retrieve gold images from the Oracle Fleet Patching and Provisioning Server, upload new images based on the policy, and apply maintenance operations to itself.

Zero Data Loss Recovery Appliance release 12.1 does not support backups from protected database clients using Oracle Database 12c release 2 (12.2).

Zero Data Loss Recovery Appliance release 12.2 (Recovery Appliance) does support backups from protected release 12.2 database clients.

If you back up your database to Recovery Appliance, then Oracle recommends that you do not not upgrade your database to release 12.2 until your Recovery Appliance is upgraded to release 12.2.

To increase optimization and performance, the Oracle Database Client and server process memory requirements are greater than in previous releases.

Every release of Oracle Database includes new features and capabilities. To provide optimal performance for the increased capability of the database, there can be an increase in the Oracle Database Client and Oracle Database Server can increase from one release to the next. The memory requirement increase can vary from platform to platform.

As part of your upgrade plan, check to determine the memory requirements increase that can be present in a new Oracle Database release. For example, in comparison to Oracle Database 11g Release 2 (11.2), Oracle Database 12c on some platforms can have as much as a 5 MB memory increase for each client, and a 10 MB increase for each server.

Starting with Oracle Database 12c release 2 (12.2.0.1), the REPLACE clause of ALTER TYPE is deprecated.

As an alternative, Oracle recommends that you use the ALTER TYPE methods ADD and DROP, or use ALTER TYPE method ADD .

The postinstallation check script configToolAllCommands is deprecated in Oracle Database 12c release 1 (12.1).

The script configToolAllCommands runs in the response file mode to configure Oracle products after installation. It uses a separate password response file. Starting with Oracle Database 12c release 2 (12.2), configToolAllCommands is deprecated. It may be desupported in a future release.

You can now obtain postinstallation checks as part of the installation process. Oracle recommends that you run the Oracle Database or Oracle Grid Infrastructure installer with the option -executeConfigTools. You can use the same response file created during installation to complete postinstallation configuration.

The DBMS_DEBUG package is deprecated in Oracle Database 12c release 2 (12.2). Oracle recommends that you use DBMS_DEBUG_JDWP.

In earlier releases, PL/SQL included the DBMS_DEBUG package to enable internal and third-party tools to debug PL/SQL programs. The DBMS_DEBUG package provides APIs to set breakpoints, obtain values of variables, and so on. This functionality has been provided by the DBMS_DEBUG_JDWP package for several releases. DBMS_DEBUG_JDWP provides the equivalent PL/SQL debugging capabilities, and it enables seamless debugging of PL/SQL routines when it calls into or is called from server-side Java (OJVM) with Java stored procedures.

Intelligent Data Placement is deprecated in Oracle Database 12c release 2 (12.2).

Intelligent Data Placement enables you to specify disk regions on Oracle ASM disks for best performance. Using the disk region settings, you can ensure that frequently accessed data is placed on the outermost (hot) tracks which have greater speed and higher bandwidth. In addition, files with similar access patterns are located physically close, reducing latency. Intelligent Data Placement also enables the placement of primary and mirror extents into different hot or cold regions

This feature is deprecated in Oracle Database 12c release 2 (12.2).

Starting with Oracle Database 12c Release 2 (12.2.0.1), the LogMiner CONTINUOUS_MINE option is deprecated.

The LogMiner CONTINUOUS_MINE option is still supported for backward compatibility reasons. However, Oracle recommends that you discontinue using it. There is no replacement functionality.

The non-CDB architecture was deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c .

Oracle recommends use of the CDB architecture.

Oracle Administration Assistant for Windows is deprecated in Oracle Database 12c release 2 (12.2).

Oracle Administration Assistant for Windows is a tool for creating database administrators, operators, users, and roles in Windows. It also allows database service, startup and shutdown configuration, and Windows Registry parameter management.

Instead of using Oracle Administration Assistant for Windows, use native Windows administration tools.

The Oracle Data Provider for .NET PromotableTransaction setting is deprecated, because it is no longer necessary.

Promotable transactions themselves are not being deprecated. Only this specific setting is deprecated.

The Oracle Data Provider for .NET registry setting PromotableTransaction indicates whether the application must keep transactions as local, or if it can begin all single connection transactions as local, and then promote the transaction to distributed when a second connection enlists. This is the concept of promotable transactions.

The Promotable Transaction setting is deprecated in Oracle Database 12c release 2 (12.2). There is no reason not to use promotable transactions. Oracle recommends you accept the default value promotable.

Starting in Oracle Database 12c release 2 (12.2), the Java package oracle.jdbc.OracleConnection.unwrap() is deprecated.

The Java package oracle.jdbc.OracleConnection.unwrap() is deprecated in Oracle Database 12c release 2, and later releases. There is no replacement for this package.

Oracle recommends that you replace this JDBC method in your applications with standard Java methods.

Starting in Oracle Database 12c release 2 (12.2), the Java oracle.jdbc.rowset package is deprecated

Oracle recommends that you use the Standard JDBC RowSet package to replace this feature.

oracle.sql classes that extend oracle.sql.DatumWithConnection are deprecated in Oracle Database 12c release 2 (12.2), in favor of oracle.jdbc extension types.

In previous releases, Oracle Database included Oracle JDBC drivers that provided specific type extensions and performance extensions in both oracle.sql and oracle.jdbc Java packages. Starting with Oracle Database 12c release 2 (12.2), the oracle.sql classes that extend oracle.sql.DatumWithConnection are deprecated. The oracle.jdbc extensions continue to be supported.

For example, here is a partial list of deprecated oracle.sql classes:

• ARRAY

• BFILE

• BLOB

• CLOB

• OPAQUE

• REF

• STRUCT

Oracle recommends that you replace oracle.sql classes that extend oracle.sql.DatumWithConnection in your applications with standard Java types, or with oracle.jdbc extensions.

The Oracle Multimedia Java APIs are deprecated in Oracle Database 12c release 2.

The following Java APIs are deprecated in Oracle Database 12c Release 2 (12.2), and can be desupported in a future release:

• Oracle Multimedia Java API

• Oracle Multimedia Servlets and JSP Java API

• Oracle Multimedia DICOM Java API

• Oracle Multimedia Mid-Tier Java API

Starting in Oracle Database 12c release 2 (12.2), the Oracle Multimedia DICOM feature is deprecated.

There is no replacement for DICOM support in Oracle Database.

Starting in Oracle Database 12c release 2 (12.2), Oracle Multimedia SQL/MM Still Image standard support is deprecated.

For image processing operations, Oracle Multimedia developers can call the new ORD_IMAGE PL/SQL package, or call the ORDImage methods.

For image matching, Oracle Database developers can use open source packages, such as OpenCV.

Starting in Oracle Database 12c release 2, the Unicode Collation Algorithm (UCA) 6.1 collations are deprecated.

The Unicode Collation Algorithm (UCA) 6.1 collations (UCA0610_*) are deprecated. They can be desupported and unavailable in a future release. Oracle recommends that you use the latest supported version of UCA collations for sorting multilingual data.

Starting in Oracle Database 12c release 2, the initialization parameter UNIFIED_AUDIT_SGA_QUEUE_SIZE is deprecated.

The UNIFIED_AUDIT_SGA_QUEUE_SIZE parameter is deprecated, and the value for this parameter is no longer honored. However, the parameter is currently retained for backward compatibility.

See Oracle Database Security Guide for additional information about Unified Audit records.

The VERIFY_FUNCTION and VERIFY_FUNCTION_11G password verify functions are deprecated in this release, because they enforce the weaker password restrictions from earlier releases.

Oracle recommends that you use the functions ORA12C_VERIFY_FUNCTION and ORA12C_STRONG_VERIFY_FUNCTION. These functions enforce stronger, more up-to-date password verification restrictions.

The V$MANAGED_STANDBY view is deprecated in Oracle Database 12c release 2 (12.2.0.1). Oracle recommends that you use the new view V$DATAGUARD_PROCESS.

The V$DATAGUARD_PROCESS view includes much more information about processes used by Oracle Data Guard.

Starting with Oracle Database 12c release 2 (12.2) the options listed in this topic are deprecated.

The following options are deprecated:

• Oracle XQuery function ora:contains. Use XQuery Full Text instead.

• Oracle SQL function XMLRoot. Use SQL/XML function XMLSerialize() with a version number instead.

• Nested tables stored as index-ordered tables (IOTs). This includes both the use of option DBMS_XMLSCHEMA.REGISTER_NT_AS_IOT, and the use of clause NESTED TABLE N STORE AS ... (ORGANIZATION INDEX) when creating a table with nested-table column N. Instead, store nested-table columns using heap storage (the default behavior for PL/SQL procedure DBMS_XMLSCHEMA.registerSchema).

• PL/SQL procedure DBMS_XSLPROCESSOR.CLOB2FILE. Use DBMS_LOB.CLOB2FILE instead.

• PL/SQL function DBMS_XSLPROCESSOR.READ2CLOB. Use DBMS_LOB.LOADCLOBFROMFILE instead.

• Use of XLink with Oracle XML DB.

• Oracle XML DB Content Connector.

For more information, refer to Oracle XML DB Developer’s Guide.

Starting in Oracle Database 12c release 2 (12.2), the Advanced Replication feature of Oracle Database is desupported.

The Oracle Database Advanced Replication feature is desupported in its entirety. The desupport of this feature includes all functionality associated with this feature: multimaster replication, updateable materialized views, and deployment templates. Read-only materialized views are still supported with basic replication.

Oracle recommends that you replace your use of Advanced Replication with Oracle GoldenGate.

Placing OCR and Voting Disk files on shared file systems is desupported in favor of placing the files on Oracle ASM.

Starting with Oracle Grid Infrastructure 12c Release 2 (12.2), the placement of Oracle Clusterware files: the Oracle Cluster Registry (OCR), and the Voting Files, directly on a shared file system is desupported in favor of having Oracle Clusterware files managed by Oracle Automatic Storage Management (Oracle ASM). You cannot place Oracle Clusterware files directly on a shared file system. If you need to use a supported shared file system, either a Network File System, or a shared cluster file system instead of native disks devices, then you must create Oracle ASM disks on supported network file systems that you plan to use for hosting Oracle Clusterware files before installing Oracle Grid Infrastructure. You can then use the Oracle ASM disks in an Oracle ASM disk group to manage Oracle Clusterware files.

If your Oracle Database files are stored on a shared file system, then you can continue to use the same for database files, instead of moving them to Oracle ASM storage.

All Oracle JPublisher features are desupported and unavailable in Oracle Database 12c Release 2 (12.2.0.1).

Oracle recommends that you use the following alternatives:

• To continue to use Web service callouts, Oracle recommends that you use the Oracle JVM Web Services Callout utility, which is a replacement for the Web Services Callout utility.

• To replace other JPublisher automation capabilities, including mapping user-defined SQL types or SQL types, wrapping PL/SQL packages and similar capabilities, Oracle recommends that developers use explicit steps, such as precompiling code with SQLJ precompiler, building Java STRUCT classes, or using other prestructured options.

The preupgrd.sql and utluppkg.sql scripts are replaced by the Preupgrade Information Tool (preupgrade.jar).

Beginning with Oracle Database 12c release 2 (12.2), the Pre-Upgrade Information Tool scripts preupgrd.sql and utluppkg.sql are no longer supplied as part of the Oracle Database release. The Pre-Upgrade Information Tool preupgrade.jar replaces both of these files.

The preupgrade.jar Pre-Upgrade Information Tool is supplied with Oracle Database 12c release 2 (12.2). This script has the same capabilities as the scripts it replaces. It can run using the Java Development Kits (JDKs) installed with Oracle Database releases supported for direct upgrade to Oracle Database 12c release 2 (12.2).

Application programming interfaces (APIs) for Transaction Guard listed here are desupported in Oracle Database 12c release 2 (12.2).

The following Oracle Data Provider for .NET application programming interfaces for Transaction Guard are desupported in Oracle Database 12c Release 2 (12.2):

• OracleLogicalTransactionStatus class

• OracleConnection.GetLogicalTransactionStatus method

• OracleConnection.LogicalTransactionId property

• OracleConnection.OracleLogicalTransaction property

• OracleLogicalTransaction.DataSource property

• OracleLogicalTransaction.GetOutcome() method

• OracleLogicalTransaction.GetOutcome(string, string, string) method

• OracleLogicalTransaction.UserId property

The views listed in this topic are desupported in Oracle Database 12c release 2 (12.2).

Revise any of your SQL statements that use these views.

Starting with Oracle Database 12c release 2 (12.2), Oracle does not support running server-side SQLJ code.

Oracle supports using client-side SQLJ. However, Oracle does not support the use of server-side SQLJ, including running stored procedures, functions, and triggers in the database environment.

Starting in Oracle Database 12c release 2 (12.2), the XML DB features listed here are desupported.

The following features are desupported:

• Java classes in package oracle.xdb.dom

• Oracle XPath function ora:instanceof. Use XQuery operator instance of instead.

• Oracle XPath function ora:instanceof-only. Use XML Schema attribute xsi:type instead.

• Function-based indexes on XMLType. Use XMLIndex with a structured component instead.

• Oracle XQuery function ora:view. Use XQuery functions fn:collection instead.

• PL/SQL procedure DBMS_XDB_ADMIN.CreateRepositoryXMLIndex

• PL/SQL procedure DBMS_XDB_ADMIN.XMLIndexAddPath

• PL/SQL procedure DBMS_XDB_ADMIN.XMLIndexRemovePath

• PL/SQL procedure DBMS_XDB_ADMIN.DropRepositoryXMLIndex

• XML schema annotation (attribute) csx:encodingType

• XMLIndex index on CLOB portions of hybrid XMLType storage (index on CLOB data that is embedded within object-relational storage)

The CREATE_PLUGGABLE_DATABASE statement pdb_storage_clause MAX_SHARED_TEMP_SIZE parameter is desupported in Oracle Database 12c Release 2 (12.2). Use MAXSIZE instead.

The MAX_SHARED_TEMP_SIZE parameter of pdb_storage_clause was removed in Oracle Database 12c Release 2 (12.2), because it is unneeded. The MAXSIZE parameter limits the amount of storage that can be used by all tablespaces in the pluggable database (PDB) to the value specified with size_clause. This limit includes the size of data files and temporary files for tablespaces belonging to the PDB. Accordingly MAX_SHARED_TEMP_SIZE has no function.

In Oracle Database 12c release 1 (12.1) and later releases, Direct NFS (DNFS) is enabled by default with Oracle Real Application Clusters (Oracle RAC) installations.

By default, Direct NFS Client is installed in an enabled state for Oracle RAC installations. This is different from Oracle Database single-instance installations, in which you have to enable Direct NFS, and the Direct NFS Client is disabled by default as part of installation. If you upgrade an Oracle RAC Oracle Database release to Release 12.1 or later releases, and you do not have Direct NFS enabled on your source database, then you encounter the error message ORA-17500: ODM err:Operation not permitted.

For more information about this change, and to review options in preparation for your upgrade, refer to My Oracle Support notes 954425.1, and 1966267.1

The non-CDB architecture is deprecated in Oracle Database 12c. It can be desupported and unavailable in a release after Oracle Database 19c.

Oracle recommends use of the CDB architecture.