New Features in Oracle Database 19c Release 1 (19.1.0)

January 19, 2020  

Installation and Upgrades

• Simplified Image based installation of client as well
• RPM Based Installation  install Oracle 19c Database using RPM method with Vagrant Virtual box and via ansible playbook
• Docker Container for Oracle 19c
• Auto Upgrade Utility for Oracle Database
• DryRun mode for GridSetup in clusterware Installation

General

• Clear flashback logs periodically
• Multimodel partitioning with Hybrid partitioning allowing some partitions in the database and some as external partitions even in hdfs
• Passwords removed from schema accounts (default accounts)
• Schema-only accounts - Passwords Removed from Oracle Database Accounts
• Flush Metadata Cache for Passwords
• Hybrid Partitioned Tables - to integrate internal partitions and external partitions into a single partition table.  partitions to reside in both Oracle Database segments and in external files and sources
• New ALTER SYSTEM statement clause FLUSH PASSWORDFILE_METADATA_CACHE

Pluggable Databases

• Creation Duplicate of an Oracle Database, CreateDuplicateDB command, in DBCA Silent Mode
• Ability to Create a PDB by Cloning a Remote PDB Using DBCA in Silent Mode
• Ability to relocate a PDB to another CDB Using DBCA in Silent Mode
• ADDM Analysis at PDB Level

Data Pump

• Ability to Exclude ENCRYPTION Clause on Import - new transform parameter OMIT_ENCRYPTION_CLAUSE
• Oracle Data Pump Support for Resource Usage Limitations - new parameter MAX_DATAPUMP_PARALLEL_PER_JOB
• Oracle Data Pump Test Mode for Transportable Tablespace (TTS)
• Oracle Data Pump Prevents Inadvertent Use of Protected Roles -  new ENABLE_SECURE_ROLES parameter is available
• Oracle Data Pump Loads Partitioned Table Data One Operation - GROUP_PARTITION_TABLE_DATA, a new value for the Import DATA_OPTIONS command line parameter
• Oracle Data Pump Allows Tablespaces to Stay Read-Only During TTS Import
• Oracle Data Pump Import Supports More Object Store Credentials

Performance

• SQL Quarantine - Starting Oracle 19c, SQL Quarantine features helps to prevent reuse of same execution plan which was terminated by resource managers due to resource limits. This will help not to run the rouge queries again on the database if the resource manager is active. SQL Quarantine will need to setup configuration and define thresholds for specific execution plan for given sql_id or for all plans for sql_id. The thresholds are similar like resource manager threshold ex: cpu limit, elapsed_time limit etc. To define the thresholds you can use DBMS_SQLQ package.quarantine configuration for an execution plan for a SQL statement
• Automatic Indexing - Manage Auto Indexes with Advisory task like MOnitor, Capture, Identify, Verify, Decide -  to enable auto index mode is below, we have options "Implement", "Report-Only", "OFF".
  select * from dba_auto_index_config;
• SQL Statement Diagnosability with SQL Advisor repair and SQL Test case for procedures
• Automatic Database Diagnostic Monitor (ADDM) Support for Pluggable Databases (PDBs)
• Realtime statistics for DML Operations - Oracle Database 19c introduces real-time statistics, which extend online support to conventional DML statements
• Statistics Collection on custom frequency automatically - From 19c onwards,  High-frequency automatic optimizer statistics collection complements the standard statistics collection job
• Workload Capture and Replay in a PDB

Data Guard

• Replicate Restore Points from Primary to Standby
• Dynamically change Fast-Start Failover (FSFO) target standby database to another standby database in the target list without disabling FSFO.
• Automatic Flashback of Standby
• Re-creation of broker configuration
• Propagate Restore Points from Primary to Standby site
• DML redirect to standby/ADG for read-mostly applications
• Simplified Dataguard broker parameter configurations
• Flashback Standby Database when Primary Database is Flashed Back - Oracle 19c onwards, DBA can put the standby database in MOUNT mode without managed recovery and then flashback primary database; the standby will also be reverted, thus keeping it in sync with the primary.
• Observe Only Mode for Data Guard Broker Fast-Start-Fail-Over(FSFO)
• Oracle Data Guard Multi-Instance Redo Apply Works with the In-Memory Column Store
• Finer Granularity Supplemental Logging for logical standby databases

New initialization parameters in Oracle Database 19c

• "_optimizer_gather_stats_on_conventional_dml" and "_optimizer_use_stats_on_conventional_dml" which are true by default
• _optimizer_stats_on_conventional_dml_sample_rate (at 100%)
• DATA_GUARD_MAX_IO_TIME
• DATA_GUARD_MAX_LONGIO_TIME
• ADG_REDIRECT_DML    (TRUE or FALSE)
• MAX_DATAPUMP_JOBS_PER_PDB
• aws_pdb_autoflush_enabled   (TRUE or FALSE)

New tables/views in Oracle 19c Database

• dba_auto_index_config
• dba_sql_quarantine
• V$SQL_TESTCASES
• DBA_REGISTRY_BACKPORTS

New packages in 19c Database Release 1

• dbms_auto_index
• dbms_auto_index_internal
• DBMS_SQLQ

Dynamically Change Oracle Data Guard Broker Fast-Start Failover Target

The fast-start failover target standby database can be changed dynamically, to another standby database in the target list, without disabling fast-start failover.

In earlier releases of Oracle Database, you had to disable fast-start failover to move to a new target standby database. This exposes the broker configuration to a period where automatic failover cannot be used at all. You use the SET FAST_START FAILOVER TARGET command to dynamically change the fast-start failover target standby database.

Simplified Database Parameter Management in Oracle Data Guard Broker

The management of database parameters in an Oracle Data Guard broker configuration is simplified by allowing all parameter management through SQL*Plus. Inconsistencies between a database's Data Guard parameter settings and the Data Guard Broker's property settings are eliminated.

You can now manage all Oracle Data Guard-related parameter settings using the SQL*Plus ALTER SYSTEM command or in the Data Guard broker command-line interface (DGMGRL) with the new EDIT DATABASE ... SET PARAMETER command. Parameter changes made in DGMGRL are immediately executed on the target database.

Observe-only Mode for Oracle Data Guard Broker's Fast-Start Failover

The Observe-only mode allows you to test automatic fast-start failover without any impact to the production database in an Oracle Data Guard broker configuration.

When you configure fast-start failover, you can use the observe-only mode to create a test mode that checks when a failover or other interaction would have occurred during normal production processing. You can use the information from this test to tune the fast-start failover properties more precisely. You can also discover what circumstances in your environment will cause an automatic failover to occur.

Propagate Restore Points from Primary to Standby Site

Restore points created on the primary database are propagated to the standby sites, so that they are available even after a failover operation.

Normal restore points or guaranteed restore points are defined at the primary site to enable fast point-in-time recovery in the event of logical corruptions. These restore points are stored in the control file. In the event of a failover, the standby database becomes the primary database. However, the restore point information is lost. Propagating restore points from the primary to the standby simplifies the complexity of the restore and recovery process after a failover because the standby database is updated with the restore points created on the primary database.

Flashback Standby Database When Primary Database is Flashed Back

The standby database in an Oracle Data Guard setup can be automatically flashed back when a flashback operation is performed on the primary database.

When a flashback operation is performed on the primary database, the standby is no longer synchronized with the primary. In earlier releases, you needed to perform certain steps to synchronize the standby with the primary. This feature introduces a new parameter that enables the standby database to be flashed back automatically when a flashback operation is performed on the primary database. This reduces time, effort, and human errors thereby resulting in faster synchronization and reduced recovery time objective (RTO).

Oracle Data Guard Multi-Instance Redo Apply Works with the In-Memory Column Store

The In-Memory Column Store and Data Guard Multi-Instance Redo Apply can now be enabled at the same time on an Active Data Guard standby. Previously the two features were mutually exclusive.

You can now use the fastest redo apply technology (Data Guard Multi-Instance Redo Apply) and the fastest analytical query technology (In-Memory Column Store) on the same Active Data Guard standby to gain the best of both features. Multi-Instance Redo Apply uses information in the In-Memory Column Store on the Active Data Guard standby to increase apply speed where possible.

Active Data Guard DML Redirection

Incidental Data Manipulation Language (DML) operations can be run on Active Data Guard standby databases. This allows more applications to benefit from using an Active Data Guard standby database when some writes are required.

DML redirection helps in load balancing between the primary and standby databases. When incidental DML is issued on an Active Data Guard standby database, the update is passed to the primary database where it is executed. The resulting redo of the transaction updates the standby database after which control is returned to the application.

PDB Recovery Catalog

Connections to a recovery catalog are supported when the target database is a pluggable database (PDB).

Oracle Database Release 19c provides complete backup and recovery flexibility for multitenant container database (CDB) and PDB level backups and restores, including recovery catalog support. You can use a virtual private catalog (VPC) user to granularly control permissions to perform backup and restore operations at a PDB level. Metadata view is also limited, so a VPC user can view only data for which the user has been granted permission.

Clear Flashback Logs Periodically for Increased Fast Recovery Area Size Predictability

Fast recovery area management and database health are improved by automatically deleting flashback logs that are beyond the retention period.

The fast recovery area is critical for databases because it stores backups, online redo logs, archived redo logs, and flashback logs. Because many databases can all use the fast recovery area, multiple databases are impacted when the fast recovery area becomes full. This feature makes flashback space usage become predictable from a storage management perspective, since flashback uses no more space than is required by retention. It also allows you to control cumulative space pressure by adjusting the flashback retention.

New Parameters to Tune Automatic Outage Resolution with Oracle Data Guard

Oracle Data Guard automatic outage resolution can be tuned to fit your specific needs.

Oracle Data Guard has several processes, on the primary database and standby databases, which communicate with each other over the network to manage redo transport and archiving. In certain failure situations, network hangs, disconnects, and disk I/O issues, these processes can hang potentially causing delays in redo transport and gap resolution. Oracle Data Guard has an internal mechanism to detect these hung processes and terminate them thus allowing the normal outage resolution to occur. You can now use two new parameters, DATA_GUARD_MAX_IO_TIME and DATA_GUARD_MAX_LONGIO_TIME, to tune waits times for a specific Oracle Data Guard configuration based on the user network and disk I/O behavior.

Finer Granularity Supplemental Logging

Fine-grained supplemental logging provides a way for partial database replication users to disable supplemental logging for uninteresting tables so that even when supplemental logging is enabled in a database or schema level, there is no supplemental logging overhead for uninteresting tables.

Use of this feature significantly reduces the overhead in terms of resource usage and redo generation when only some of the tables in the database require supplemental logging, such as in an Oracle GoldenGate partial replication configuration. Supplemental logging was designed and implemented for logical standby databases or for full database replication requirements. This adds unnecessary overhead in environments where only a subset of tables is being replicated.

Source: Oracle