Oracle Database 19c: What's New, Release History & Support Lifecycle

What Is New in Oracle Database 19c

What Does Automatic Indexing Actually Do in Oracle Database 19c?

Automatic Indexing continuously monitors application workloads and creates, rebuilds, or drops indexes without any DBA involvement. The optimizer evaluates candidate indexes against a test workload in a shadow environment before making them visible, so there is no risk of regressing existing query plans.

In practice, this is the most operationally significant feature for OLTP environments. The background task runs using the DBMS_AUTO_INDEX package framework, and DBAs can control it at the CDB or PDB level. You can set the overall mode to IMPLEMENT, REPORT ONLY, or OFF:

-- Enable automatic indexing in report-only mode first
EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE', 'REPORT ONLY');

-- Check what automatic indexing would have created
SELECT index_name, table_name, index_columns, index_type, impact
FROM   dba_auto_index_ind_actions
ORDER BY creation_time DESC;

Watch out for environments where developers rely on hints to force specific plans -- automatic indexing will create new indexes that the optimizer may prefer, potentially changing plans that were previously hint-driven. Always run in REPORT ONLY mode first and review the output before switching to IMPLEMENT.

How Does the 19c AutoUpgrade Tool Change the Database Upgrade Process?

AutoUpgrade replaces the traditional manual upgrade approach -- running catupgrd.sql and manually handling pre- and post-upgrade steps -- with a single tool that automates the entire lifecycle from analysis through post-upgrade validation.

The tool operates in three modes: analyze (checks for issues only), fixups (automatically applies pre-upgrade fixups), and deploy (runs the full upgrade). This matters if you manage a large fleet of databases, because AutoUpgrade can handle multiple databases in parallel from a single configuration file.

# Example AutoUpgrade config file (config.txt)
global.autoupg_log_dir=/opt/oracle/autoupgrade/logs

upg1.dbname=ORCL
upg1.source_home=/u01/app/oracle/product/12.2.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/19.0.0/dbhome_1
upg1.sid=ORCL
upg1.log_dir=/opt/oracle/autoupgrade/logs/ORCL
upg1.upgrade_node=localhost
upg1.target_version=19

# Run analysis first
java -jar autoupgrade.jar -config config.txt -mode analyze

Subsequent Release Updates added significant capabilities: RU 19.21 extended AutoUpgrade to automate Data Guard role transitions during upgrade, handle RAC rolling upgrades, and convert non-CDB databases to PDB in a single operation. If you are still using manual upgrade scripts, this is the single most impactful process change in 19c.

What Active Data Guard Enhancements Came with Oracle 19c?

Oracle 19c delivers several meaningful Active Data Guard improvements that reduce the architectural compromises you previously had to make between high availability, performance, and operational flexibility.

The most practically useful changes are:

• DML Redirection on Standbys: Applications that issue occasional writes -- such as updating a session table or audit log -- can now target the standby directly. The standby transparently forwards the DML to the primary, commits, and receives the redo. This eliminates the need to maintain a separate read-write endpoint for applications with mixed workloads.
• Multi-Instance Redo Apply + In-Memory Column Store: Previously you had to choose between fast redo apply (Multi-Instance Redo Apply) and fast analytical queries (In-Memory Column Store) on an Active Data Guard standby. In 19c, both can run simultaneously, and Multi-Instance Redo Apply actively uses the In-Memory Column Store to accelerate apply speed.
• Dynamic Fast-Start Failover Target: You can now use SET FAST_START FAILOVER TARGET in DGMGRL to change the failover target without disabling fast-start failover, eliminating the protection gap that previously existed during target reassignment.
• Propagate Restore Points to Standby: Guaranteed restore points created on the primary are automatically propagated to standby sites and survive failover, significantly simplifying point-in-time recovery after switchover events.
• Observe-Only Fast-Start Failover Mode: You can simulate fast-start failover behavior on a production system without triggering any actual failover, which makes it practical to tune FSF thresholds in live environments.

Most teams running Active Data Guard for offload reporting will want to evaluate DML Redirection early -- it can consolidate connection strings and simplify application code significantly.

How Do Real-Time Statistics and SQL Quarantine Improve Query Performance in Oracle 19c?

Real-Time Statistics and SQL Quarantine address two distinct but common performance problems: optimizer decisions based on stale statistics, and runaway queries that repeatedly consume excessive resources.

Real-Time Statistics piggybacks on bulk DML operations (such as INSERT /*+ APPEND */ or CTAS) to collect statistics incrementally, without a separate DBMS_STATS call. This means the optimizer sees accurate row counts and column statistics immediately after a large load completes, rather than waiting for the next scheduled statistics gather. For data warehouses or ETL pipelines that load millions of rows overnight, this eliminates the window where queries run against stale statistics.

SQL Quarantine extends the Resource Manager's runaway query controls. When a SQL statement is terminated by a Resource Manager threshold -- such as CPU time or I/O -- the execution plan that caused the violation is automatically quarantined. Future executions of that SQL with the same plan are rejected before they consume resources, returning an error to the caller immediately. DBAs can manage quarantine configurations through DBMS_SQLQ:

-- View currently quarantined SQL plans
SELECT sql_text, cpu_time, elapsed_time, reads, fetches
FROM   dba_sql_quarantine
ORDER BY last_executed DESC;

-- Manually create a quarantine for a known problematic SQL_ID
DECLARE
  l_quarantine VARCHAR2(30);
BEGIN
  l_quarantine := DBMS_SQLQ.CREATE_QUARANTINE_BY_SQL_ID(
    sql_id      => '7vgb2pkfnk3c9',
    plan_hash_value => 1234567890
  );
END;
/

This matters if you operate mixed-workload databases where ad hoc queries can occasionally escape normal bounds and starve OLTP sessions. SQL Quarantine is not a substitute for proper Resource Manager configuration, but it acts as a persistent safety net once a bad plan has been identified.

What Security and Compliance Improvements Were Added to Oracle Database 19c?

Oracle 19c includes a broad set of security enhancements across auditing, encryption, privilege management, and authentication -- many of which directly address compliance requirements for CIS benchmarks and regulatory frameworks.

Key security changes to evaluate during upgrades:

• Privilege Analysis in Enterprise Edition: Previously limited to Database Vault customers, Privilege Analysis now ships with Enterprise Edition. It captures the privileges actually used by a workload and identifies over-privileged accounts -- a critical step before applying least-privilege hardening.
• Passwords Removed from Oracle Database Accounts: Several built-in accounts are now schema-only accounts with no password. You can also create or convert accounts to schema-only status using CREATE USER ... NO AUTHENTICATION or ALTER USER ... NO AUTHENTICATION, which prevents password-based login entirely.
• Unified Auditing -- Top-Level Statements: The UNIFIED_AUDIT_TRAIL now records top-level SQL statements that trigger audited events indirectly (for example, a procedure call that issues a DML on an audited table), giving a complete audit chain.
• New EVENT_TIMESTAMP_UTC Column: The UNIFIED_AUDIT_TRAIL view gains an EVENT_TIMESTAMP_UTC column, making it straightforward to correlate audit records across databases in different time zones.
• Database Vault Operations Control: Infrastructure DBAs (with SYSDBA) can be blocked from accessing application data even in emergency scenarios, enforcing separation of duty at the operating system level.
• Multi-Factor Authentication (RU 19.28): Support for MFA in database authentication was added, allowing Oracle Database logins to require a second factor beyond username and password.
• Signature-Based Security for LOB Locators: Prevents LOB locator injection attacks where a malicious user substitutes a crafted locator to access unauthorized LOB data.

In practice, enabling Privilege Analysis in report mode before any security hardening effort is the lowest-risk, highest-value action. Run it against your application schemas for a representative period, export the results, and compare actual usage against granted privileges before revoking anything.