Oracle Database Support Lifecycle & Release History

Oracle Database Long-Term and Innovation Release Tracks

Oracle Database follows a dual-track release model -- Long-Term Releases (LTR) and Innovation Releases (IR) -- each with distinct support windows that determine how long your database engine receives patches and error corrections.

Long-Term Releases are the production-grade choice for most enterprises. They receive five years of Premier Support from general availability, followed by three years of fee-based Extended Support, and then indefinite Sustaining Support. Innovation Releases are short-cycle releases designed for early access to new capabilities; they receive Premier Support only, are not eligible for Extended Support, and exit the patching pipeline much earlier.

Oracle ships Release Updates (RUs) quarterly for active releases. These are cumulative patches that include bug fixes, security fixes, and recommended one-off patches. Release Update Revisions (RURs) -- which are security-only, lower-risk stacks -- are reserved exclusively for Long-Term Releases and are not provided for Innovation Releases.

Support dates, patch end dates, and any exceptions are governed by the authoritative MOS Note 742060.1 -- Release Schedule of Current Database Releases and the Oracle Technology Products Lifetime Support Policy. Always verify against these sources, as Oracle does revise dates -- including multi-year Premier Support extensions, as shown in the release table above.

Data Integrity and Security Exposure in Unsupported Oracle Engines

Running an Oracle Database instance outside of Premier or Extended Support means no new RUs, no Critical Patch Updates (CPUs), and no security alerts -- leaving your storage engine, listener, and network encryption stack exposed to unpatched CVEs.

Oracle CPUs are released quarterly and often patch vulnerabilities with CVSS scores above 9.0 affecting the Oracle kernel, Java VM, XML DB, and the Oracle Net layer. An unsupported instance stops receiving these fixes permanently. Unlike open-source databases where community patches occasionally backport fixes, Oracle's proprietary model means there is no unofficial patch channel once a release exits support.

Beyond security, older Oracle engine versions lose certification with new OS releases, storage firmware, and third-party middleware. A release on Sustaining Support can still be licensed and run, but Oracle will not reproduce bugs against it or certify it against new Red Hat, SUSE, or AIX versions. This creates a creeping compatibility wall -- not an immediate failure, but a growing constraint on your infrastructure roadmap.

For databases handling financial transactions or PII, auditors increasingly flag instances running past Extended Support end dates. Oracle's own audit language in support contracts distinguishes between "supported" and "sustained" states, and the distinction matters when evaluating patch currency during reviews.

Sustaining Support Phase: What Oracle Still Provides After Extended Support Ends

When Extended Support expires, Oracle Database does not become unsupported in the traditional sense -- it transitions to Sustaining Support, an indefinite tier that provides access to existing patches but no new ones.

Under Sustaining Support, Oracle will not create new bug fixes, will not release new RUs, and will not certify the release against new OS, hardware, or third-party versions. You retain access to My Oracle Support, existing knowledge base articles, and patches that were already published during Premier and Extended Support. That backlog can be substantial for a mature LTR, but it is a static artifact -- it will not grow.

In practice, teams staying on Sustaining Support are either running isolated workloads with no external connectivity, or are mid-migration and treating the instance as a read-only historical archive. For any active OLTP or data warehouse workload, Sustaining Support is not a viable long-term posture.

The migration path for most on-premises environments is direct upgrade to the current Long-Term Release using Oracle's AutoUpgrade tool, which automates pre-checks, schema migration, and timezone updates. Multi-hop upgrades -- skipping intermediate major versions -- are supported within documented minimum source version constraints. Oracle's AutoUpgrade documentation and Mike Dietrich's Oracle Database Upgrade Blog are the most reliable resources for planning this path.

Querying the Oracle Engine: Identifying Your Active Database Version

The most reliable way to identify an Oracle Database version is to query the V$VERSION or PRODUCT_COMPONENT_VERSION dynamic performance views directly from a SQL session.

From SQL*Plus or any SQL client

SELECT * FROM V$VERSION;

-- Or for a single-row summary:
SELECT BANNER FROM V$VERSION WHERE ROWNUM = 1;

This returns the full version string including the base release, the applied Release Update number, and the patch level -- for example, the banner will show the major version, RU number, and build date. The RU number is critical: two instances on the same major release can be at very different patch levels depending on which quarterly RU has been applied.

Checking the Release Update (RU) patch level

SELECT PATCH_ID, PATCH_UID, VERSION, ACTION, STATUS, DESCRIPTION
FROM DBA_REGISTRY_SQLPATCH
ORDER BY ACTION_TIME DESC;

This query against DBA_REGISTRY_SQLPATCH shows the full patch application history, including which RUs and one-off patches have been applied, their status, and the timestamp. It is the authoritative record of the instance's patch currency.

From the OS command line (without a SQL session)

$ORACLE_HOME/bin/sqlplus -version

# Or using opatch to list all applied patches:
$ORACLE_HOME/OPatch/opatch lspatches

The opatch lspatches command is particularly useful for infrastructure teams who need to audit patch levels across a fleet of Oracle homes without logging into each database individually.