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

What Is New in Oracle Database 21c

Oracle Database 21c is an Innovation Release that introduces a sweeping set of new capabilities across JSON handling, machine learning, security, high availability, and developer tooling. It also marks the first generally available release to include all features originally previewed in the Oracle Database 20c preview release. The upgrade is most compelling for teams investing in JSON-native workloads, in-database machine learning, or tighter multitenancy control.

Does Oracle Database 21c Finally Give JSON First-Class Status?

Yes -- Oracle Database 21c introduces a native JSON data type that replaces storing JSON in VARCHAR2, CLOB, or BLOB columns, and the performance difference in production workloads is substantial. The new JSON type stores data in a proprietary binary format optimized for query and DML processing, and it can be populated in the In-Memory Column Store for even faster analytical access.

In practice, this changes how you should design JSON-heavy schemas going forward. The new JSON_TRANSFORM function gives you a clean way to apply multiple transformations in a single statement, and multivalue indexes on JSON columns let you index arrays without the old workarounds using function-based indexes.

RFC 8259 compliance is also addressed -- JSON columns now accept top-level scalar values, not just objects or arrays. GoldenGate, XStream, Data Pump, SQL*Loader, OCI, JDBC, and PL/SQL all gained native support for the new JSON type, so the ecosystem is consistent from ingestion to replication.

-- Create a table using the native JSON data type
CREATE TABLE orders (
    order_id   NUMBER PRIMARY KEY,
    order_data JSON
);

-- Use JSON_TRANSFORM to apply multiple changes in one call
UPDATE orders
SET order_data = JSON_TRANSFORM(
    order_data,
    SET '$.status'   = 'shipped',
    SET '$.shipped_at' = SYSTIMESTAMP
)
WHERE order_id = 1001;

-- Create a multivalue index on a JSON array field
CREATE MULTIVALUE INDEX idx_order_tags
    ON orders o (o.order_data.tags[*].NUMBER);

How Do Blockchain Tables and Immutable Tables Work in Oracle 21c?

Oracle Database 21c introduces Blockchain Tables as a built-in mechanism for tamper-evident ledger storage -- without requiring any external blockchain infrastructure. Rows inserted into a Blockchain Table are cryptographically chained: each row's hash depends on the previous row, making retroactive modification detectable at the database level. Immutable Tables offer a simpler variant where rows are append-only and protected against deletion for a configurable retention period, without the full chaining overhead.

This matters if your team is building financial audit trails, supply chain records, or compliance logs where you need verifiable proof of data integrity that survives even a privileged DBA account. Watch out for one key operational constraint: rows in Blockchain Tables cannot be deleted before their retention period expires, and the table itself cannot be dropped until all rows have aged out. Plan your retention windows carefully before deploying in production.

-- Create a Blockchain Table with a 30-day minimum retention
CREATE BLOCKCHAIN TABLE audit_ledger (
    entry_id    NUMBER,
    event_type  VARCHAR2(50),
    payload     JSON,
    recorded_at TIMESTAMP DEFAULT SYSTIMESTAMP
)
NO DROP UNTIL 30 DAYS IDLE
NO DELETE UNTIL 30 DAYS AFTER INSERT
HASHING USING "SHA2_512" VERSION "v1";

-- Create a simpler Immutable Table
CREATE IMMUTABLE TABLE compliance_records (
    record_id  NUMBER PRIMARY KEY,
    rec_data   VARCHAR2(4000)
)
NO DROP UNTIL 90 DAYS IDLE
NO DELETE UNTIL 90 DAYS AFTER INSERT;

What Changed for Automation, In-Memory, and High Availability in Oracle 21c?

Oracle Database 21c significantly expands the Automatic Operations portfolio. Automatic Materialized Views allow the optimizer to create and maintain materialized views on its own when query patterns justify it -- a major shift for analytical workloads that previously required DBA-led tuning cycles. Automatic Indexing picks up additional enhancements including Automatic Index Optimization, which drops indexes that are no longer beneficial.

• Automatic SQL Tuning Set -- the database continuously captures SQL for the SQL Tuning Set in the background, removing the need to schedule capture jobs manually.
• Automatic Temporary and Undo Tablespace Shrink -- space is reclaimed automatically after workload spikes, reducing the common problem of tablespaces growing unboundedly after batch jobs.
• Automatic Zone Maps (Exadata) -- Zone Maps are now created and maintained automatically based on observed query predicates, a previously manual Exadata tuning step.
• Database In-Memory Base Level -- a no-cost tier is introduced, allowing up to 16 GB of In-Memory Column Store on Enterprise Edition without the full Database In-Memory option license. This is a meaningful licensing relaxation for teams wanting to try in-memory acceleration on specific tables.
• In-Memory Vectorized Joins -- joins between in-memory tables now use SIMD vectorization, improving join performance significantly for star schema patterns.

On the high availability side, Application Continuity gains a RESET_STATE service attribute that clears session state at the end of each request, dramatically increasing coverage for Transparent Application Continuity (TAC) in cases where applications previously set state that prevented clean replay. Data Guard picks up Far Sync support in Maximum Performance mode, expanding the architectures where zero-data-loss protection is achievable without the latency overhead of Maximum Availability mode.

What Are the Most Important Security and Multitenancy Changes in Oracle Database 21c?

Oracle Database 21c tightens both security defaults and multitenancy isolation across multiple dimensions. The most operationally significant default change is that Oracle Home is now installed as Read-Only by default, separating software binaries from configuration and diagnostic files -- a change that simplifies patching and supports OCI tooling, but requires teams to review any scripts that write directly into $ORACLE_HOME.

Security hardening highlights include:

• Gradual Database Password Rollover -- applications can now rotate passwords without a hard cutover, reducing the window of connection failures during credential rotation cycles.
• Minimum Password Length Enforcement for All PDBs -- a CDB-level policy can now enforce a minimum password length across all pluggable databases, closing a gap that previously required per-PDB management.
• Windows Authentication NTLM Disabled by Default -- Oracle now defaults to Kerberos TCP for database connections to Kerberos servers, and NTLM is no longer used by default for Windows Authentication. Teams relying on NTLM need to explicitly review their authentication stack before upgrading.
• TDE Improvements -- sharing of TDE master encryption keys across Oracle processes reduces key management overhead, and performance is improved when wallets or Oracle Key Vault contain large numbers of TDE keys.
• Unified Audit Policy Changes Effective Immediately -- audit policy changes no longer require a session reconnect to take effect, closing a long-standing operational gap.
• No Need to Disable Database Vault Before Upgrades -- a previous pain point for teams running Database Vault is eliminated; upgrades proceed without disabling the vault.

For multitenancy, DRCP can now be configured and managed at the individual PDB level using the new ENABLE_PER_PDB_DRCP parameter, replacing the all-or-nothing CDB-level pool. PDB-level Data Guard (introduced in Release Update 21.7) allows switchover and failover at the PDB granularity -- a significant operational improvement for consolidation scenarios where failing over the entire CDB to protect one workload was disproportionate.

-- Enable per-PDB DRCP (set in the PDB, not the CDB)
ALTER SYSTEM SET ENABLE_PER_PDB_DRCP = TRUE;

-- Start the DRCP pool for the current PDB
EXECUTE DBMS_CONNECTION_POOL.START_POOL();

-- Configure Gradual Password Rollover (grace period in minutes)
ALTER PROFILE app_profile LIMIT
    PASSWORD_ROLLOVER_TIME 1;  -- 1 day grace window

What Does AutoUpgrade Handle Automatically in Oracle Database 21c?

AutoUpgrade in Oracle Database 21c substantially reduces the manual steps required for complex upgrade scenarios. It now automates Data Guard operations during upgrades -- including switchover, upgrade of the primary, and switchback -- removing the lengthy runbook that previously accompanied every Data Guard upgrade. AutoUpgrade also handles Oracle RAC upgrades end-to-end, including the rolling node-by-node steps that previously required careful manual orchestration.

Additional AutoUpgrade capabilities in 21c:

• Non-CDB to PDB conversion is fully automated, including the necessary manifest and plug-in operations.
• PDB upgrade via unplug-plug-upgrade is orchestrated automatically, enabling PDB-level upgrades without touching the CDB.
• Out-of-place patching is now supported: AutoUpgrade can move a database to a new Oracle Home and apply a Release Update in a single, auditable operation.
• AutoUpgrade integrates with Fleet Patching and Provisioning (FPP), enabling fleet-level automation across large numbers of databases.
• For TDE environments, AutoUpgrade can generate and manage keystore credentials externally, enabling unmanned (unattended) upgrades even when TDE is active.

Most teams adopting 21c should treat AutoUpgrade as the standard upgrade path rather than the manual upgrade process. The manual steps that remain are largely configuration decisions -- not operational sequences.