This chapter contains descriptions of all of the features that are new to Oracle Database 19c Release 19.3.
AutoUpgrade and Database Utilities
Focus area to include database upgrade, all types of database migration, and utilities such as SQL*Loader and external tables
Oracle Data Pump loads partitioned table data in one operation
Oracle Data Pump can optionally import the table data in all partitions of a table as one operation instead of a separate operation for each partition.
GROUP_PARTITION_TABLE_DATA, a new value for the Import DATA_OPTIONS command line parameter, changes Oracle Data Pump default behavior by importing table data in all partitions of a table as one operation. This parameter is useful when you do not want the default Import behavior that imports each table partition as a separate operation. Import chooses the default, for instance, when there is a possibility that a table could move to a different partition as part of loading a table. The default is also used when the table was not created by the Import operation.
AutoUpgrade for Oracle Database
AutoUpgrade enables you to upgrade one or many Oracle Database instances at the command-line, using a single command, and a single configuration file.
AutoUpgrade runs preupgrade tasks, performs automated fix-ups where needed, processes the database upgrade, and finishes the upgrade by completing post-upgrade tasks. It includes automatic retry and fallback, the option to schedule upgrades for future points in time, and the ability to set, change, or remove initialization parameters as desired.
AutoUpgrade significantly reduces the manual effort associated with database upgrades. It enables a single DBA to upgrade multiple databases at the same time. It can even take care of routine upgrades for databases that are not actively managed by skilled DBAs. By reducing the effort needed for upgrades, and by implementing recommended practices automatically during the upgrade process, AutoUpgrade makes the database upgrade process easier to complete, and reduces risk.
RAC and Grid
Colocation Tag for Client Routing
The COLOCATION_TAG parameter is an alphanumeric string that you can use with the CONNECT_DATA parameter of the TNS connect string. When you set the COLOCATION_TAG parameter, it attempts to route clients with the same COLOCATION_TAG to the same database instance.
Colocation of sessions on the same instance can help decrease inter-instance communication and thereby increase performance for workload that benefits from being executed in the same instance.
Optional Install for the Grid Infrastructure Management Repository
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 data contained in the GIMR is the basis for preventative diagnostics based on applied Machine Learning and can help to increase the availability of Oracle Real Application Clusters (Oracle RAC) databases. Having an optional installation for the GIMR allows for more flexible storage space management and faster deployment, especially during the installation of test and development systems.
Resupport of Direct File Placement for OCR and Voting Disks
Starting with Oracle Grid Infrastructure 19c, the desupport for direct OCR and voting disk file placement on shared file systems is rescinded for Oracle Standalone Clusters. For Oracle Domain Services Clusters, the requirement to place OCR and voting files in Oracle Automatic Storage Management (Oracle ASM) on top of files hosted on shared file systems and used as Oracle ASM disks remains.
In Oracle Grid Infrastructure 12c Release 2 (12.2), Oracle announced that it would no longer support the placement of the Oracle Cluster Registry (OCR) and voting files for Oracle Grid Infrastructure 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.
Dynamic Services Fallback Option
For a dynamic database service that is placed using "preferred" and "available" settings users can now specify that this service should fall back to a "preferred" instance when it becomes available and once it was failed over to an available instance with the last preferred instance going down.
The Dynamic Services Fallback Option allows for more control in placing dynamic database services and ensures that a given service is available on a preferred instance as long as possible.