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

What Is New in Oracle Database 18c

Oracle Database 18c marks the first release under Oracle's new annual cadence model -- formerly tied to multi-year product cycles, the database now ships updates on a yearly basis. This release builds on the multitenant foundation of 12c and 12c Release 2, doubling down on pluggable database (PDB) flexibility, in-memory performance, expanded JSON and graph support, and meaningful improvements to availability and security. For production DBAs and architects, the features here touch almost every layer of the stack.

What Is Transparent Application Continuity and How Does It Differ from Application Continuity?

Transparent Application Continuity (TAC) is an enhancement that allows session state to be automatically tracked and replayed after a recoverable failure -- without requiring any application code changes. This is the key difference from the original Application Continuity (AC), which required developers to explicitly annotate request boundaries in their connection code.

In practice, TAC works by having the database observe the session state automatically via runtime tracking. When a failover or planned maintenance event occurs (such as draining a service for a PDB relocation), in-flight requests are replayed transparently on a new server instance. The application never sees the error.

Two complementary capabilities ship alongside TAC in 18c:

• Server Draining: When relocating or stopping a service or PDB, the database waits for active requests to complete rather than killing sessions abruptly. This is critical for rolling maintenance windows on RAC clusters.
• Request Boundary Detection: The database itself can now detect request start and end points, removing the dependency on the connection pool or the application to signal these boundaries.

Watch out for workloads that use session-level state extensively (for example, global temporary tables with ON COMMIT PRESERVE ROWS, or session-level package state). TAC cannot replay operations that involve non-tracked side effects -- the DBA must verify that their workload is TAC-compatible using the new session state tracking views before enabling it in production.

How Does Oracle Database 18c Improve Multitenant and PDB Management?

Oracle Database 18c delivers the most substantial set of multitenant enhancements since PDBs were introduced, making the CDB/PDB architecture significantly more practical for large-scale deployments. Non-CDB architecture is formally desupported in this release, so teams still running non-CDB must plan their migration.

The most operationally impactful new capabilities include:

• PDB Snapshot Carousel: Maintains a ring buffer of up to eight PDB snapshots automatically, enabling fast point-in-time clones without manual RMAN intervention. This is a game-changer for developer provisioning and pre-upgrade checkpoints.
• Refreshable PDB Switchover: A refreshable PDB clone (introduced in 12.2) can now be promoted to become the primary PDB, while the original becomes the refreshable copy. This enables near-zero-downtime migrations between CDBs.
• CDB Fleet Management: A single lead CDB can now manage a fleet of member CDBs across the network, enabling centralized patch reporting, configuration drift detection, and bulk operations against all member databases.
• PDB Lockdown Profile Enhancements: Administrators can now restrict specific SQL features, network access, OS access, and common user operations per PDB -- without needing Oracle Database Vault.
• Copying a PDB in a Data Guard Environment: PDBs can now be cloned to a standby CDB directly, reducing the complexity of DR provisioning workflows.

Most teams running 20 or more PDBs per CDB will find CDB Fleet Management alone justifies testing this release. The centralized drift reporting identifies parameter divergence and missing patches across the fleet with a single query rather than a DBA manually connecting to each database.

-- Example: Check PDB snapshot carousel status
SELECT con_id, snapshot_name, snapshot_scn, full_snapshot_path
FROM   cdb_pdb_snapshots
ORDER  BY con_id, snapshot_scn;

What Performance Improvements Does Oracle Database 18c Bring to In-Memory and OLTP Workloads?

Oracle Database 18c delivers targeted performance improvements across both analytical (In-Memory) and high-throughput OLTP workloads through several new and enhanced capabilities.

Database In-Memory enhancements in this release include:

• Automatic In-Memory: The database autonomously decides which segments to load into the In-Memory Column Store (IMCS) based on heat-map statistics, reducing the need for manual INMEMORY clause placement on hot tables.
• In-Memory Optimized Arithmetic: NUMBER type arithmetic on IMCS data now uses native SIMD hardware instructions where supported, delivering measurably faster aggregation queries without schema changes.
• Dynamic Capture Window for In-Memory Expressions: Frequently evaluated expressions are automatically materialized in the IMCS, reducing repetitive CPU cycles on computed columns in analytical queries.
• Database In-Memory Support for External Tables: External tables can now be cached in the IMCS, allowing the same columnar scan performance for Hadoop and flat-file data as for native Oracle tables.

OLTP-focused improvements are equally practical:

• Memoptimized Rowstore: A new buffer pool layer for key-value style lookups that pins frequently read rows in memory for sub-millisecond primary key reads. Target: IoT ingestion and high-frequency trading patterns.
• Scalable Sequences: Sequence contention on RAC clusters is eliminated by sharding sequence cache values per instance. Workloads that use sequences as surrogate keys in high-insert applications will see significant latch reduction.
• Approximate Top-N Query Processing: APPROX_RANK in SQL returns approximate top-N results orders of magnitude faster than exact ranking for dashboards and recommendation engines where precision is less critical than speed.

This matters if your OLTP workload runs on RAC and uses sequences heavily -- sequence scalability has been a chronic contention source in 12c environments with 100+ inserts per second per table. The Memoptimized Rowstore requires the MEMOPTIMIZE_POOL_SIZE initialization parameter to be set before use.

-- Enable Memoptimized Rowstore for a table
ALTER TABLE iot_readings MEMOPTIMIZE FOR READ;

-- Create a scalable sequence (sharded per RAC instance)
CREATE SEQUENCE order_seq
  START WITH 1
  INCREMENT BY 1
  SCALE EXTEND;  -- SCALE keyword enables instance-level sharding

How Does Oracle Database 18c Improve JSON and Application Development Support?

Oracle Database 18c adds several practical improvements for teams storing and querying JSON data, as well as two new SODA (Simple Oracle Document Access) implementations that extend the NoSQL-style document API beyond Java and REST.

SODA for C and SODA for PL/SQL are the headline additions. SODA for C (part of OCI) allows C and C++ applications to perform CRUD operations on JSON document collections without writing SQL. SODA for PL/SQL brings the same document-oriented API to stored procedures. Both implementations are interoperable -- a document created via SODA for C can be queried via SODA for PL/SQL or the REST API without any format conversion.

Other JSON improvements include:

• SQL/JSON enhancements: TREAT (... AS JSON) allows PL/SQL function return values and WITH clause expressions to be treated as JSON in SQL queries. SQL/JSON functions can now return LOB data, removing the 32K varchar limitation for large JSON documents.
• Longer JSON key indexing: The JSON Search Index now indexes key names up to 255 bytes, up from 64 bytes. Teams using GSON or Jackson to serialize Java HashMaps into JSON regularly encounter keys longer than 64 characters -- those indexes were silently ignoring those keys before this fix.
• json_table enhancements: Dot-notation access and automatic column naming simplify query syntax. Materialized views built on json_table can now be automatically synchronized.

On the PL/SQL side, PL/SQL Qualified Expressions allow any PL/SQL value -- including records and associative arrays -- to be initialized inline using constructor-like syntax, similar to how SQL type constructors work. This significantly reduces boilerplate in complex record initialization code.

-- PL/SQL Qualified Expressions (new in 18c)
DECLARE
  TYPE t_rec IS RECORD (id NUMBER, name VARCHAR2(100));
  TYPE t_arr IS TABLE OF t_rec INDEX BY PLS_INTEGER;

  -- Qualified expression: initialize inline without row-by-row assignment
  l_arr t_arr := t_arr(
    1 => t_rec(id => 1, name => 'Alpha'),
    2 => t_rec(id => 2, name => 'Beta')
  );
BEGIN
  DBMS_OUTPUT.PUT_LINE(l_arr(1).name);
END;
/

Private Temporary Tables are another welcome addition for application developers. Unlike global temporary tables (GTTs), private temporary tables require no DDL beforehand -- they are created at runtime, exist only in memory, and are automatically dropped at the end of the transaction or session. This eliminates the need to pre-create GTTs in complex dynamic SQL frameworks.

-- Private Temporary Table: created at runtime, dropped automatically
CREATE PRIVATE TEMPORARY TABLE ora$ptt_staging (
  id   NUMBER,
  val  VARCHAR2(200)
) ON COMMIT DROP DEFINITION;  -- or ON COMMIT PRESERVE DEFINITION

INSERT INTO ora$ptt_staging VALUES (1, 'transient data');
SELECT * FROM ora$ptt_staging;
-- Table is gone after commit (with DROP DEFINITION option)

What Changes to Installation, Security, and the Oracle Home Should DBAs Know About Before Upgrading to 18c?

Oracle Database 18c introduces several infrastructure-level changes that affect how the software is installed, patched, and secured -- some of which are breaking changes for teams with scripts or automation built around older assumptions.

Read-Only Oracle Home is the most architecturally significant change. In 18c, the ORACLE_HOME directory can be made read-only by default, with all instance-specific configuration (trace files, audit files, log files) written to ORACLE_BASE instead. This aligns Oracle with container-friendly deployment models and simplifies patching because the Oracle Home binary layer is cleanly separated from runtime data.

Watch out for: any shell scripts, monitoring agents, or configuration management tools that write to ORACLE_HOME/dbs or ORACLE_HOME/network/admin will need to be updated to point to the new ORACLE_BASE paths.

Password file relocation: The default location for the Oracle password file (orapw) has changed from ORACLE_HOME/dbs to ORACLE_BASE/dbs. This is a silent breaking change for scripts that reference the file by hard-coded path.

RPM-based installation is now supported on Linux, allowing a single RPM to install Oracle Database without running the traditional OUI installer. This is a significant improvement for automated provisioning via Ansible, Chef, or Kubernetes-based infrastructure.

Security improvements include:

• Schema-Only Accounts: User accounts can now be created without a password, preventing any direct login while still allowing the schema to own objects. This is the correct way to create application-owner schemas -- no more workarounds using expired passwords or locked accounts.
• Per-PDB Keystores: Each PDB can now maintain its own TDE keystore, independent of the CDB keystore. This is essential for multi-tenant environments where different tenants have separate key management requirements.
• User-Defined Master Encryption Keys: Applications can supply their own master encryption key material rather than relying solely on Oracle-generated keys.
• Active Directory Integration: Native integration with Microsoft Active Directory for centralized user authentication without requiring Oracle Internet Directory as an intermediate layer.
• Sensitive Credential Encryption in Data Dictionary: Credential data stored in the data dictionary (such as database link passwords) is now encrypted by default.

Zero-Downtime Database Upgrade via Rapid Home Provisioning (RHP) deserves mention for teams running large fleets. The upgrade process can now keep the old home active while the new home is provisioned, with a fast switchover at a scheduled maintenance window -- reducing effective downtime to seconds rather than hours for patching.

-- Create a schema-only account (no password, no login)
CREATE USER app_owner NO AUTHENTICATION;
GRANT CONNECT, RESOURCE TO app_owner;
-- No password = no direct login, but app_owner can own tables and procedures

-- Verify no authentication type is set
SELECT username, authentication_type
FROM   dba_users
WHERE  username = 'APP_OWNER';