What Changed in Oracle 19c: RAC Removed from Standard Edition 2
Oracle Real Application Clusters (RAC) was historically available on Standard Edition — allowing organisations to run active-active database clusters with load balancing and near-zero downtime at a fraction of Enterprise Edition's cost. Many small and mid-sized enterprises built their high availability strategies around Standard Edition RAC, particularly on 2-node clusters.
Starting with Oracle Database 19c, RAC is no longer permitted on Standard Edition 2. This is a licensing restriction, not a technical limitation — the RAC binaries may still be present in the installation, but running a RAC cluster on SE2 19c violates Oracle's licence terms. The change is explicitly documented in Oracle's Database Licensing Information User Manual for 19c.
Oracle's rationale aligns with its broader commercial strategy: encouraging customers to adopt Enterprise Edition (at significantly higher cost) or migrate to Oracle Cloud Infrastructure (OCI) where RAC is available as part of managed database services. For IT asset managers and database architects, this represents one of the most impactful licensing changes in Oracle's recent history — forcing a re-evaluation of architecture, budgets, and vendor strategy for every SE2 RAC deployment.
🎯 Key Facts About the 19c RAC Removal
- Scope: The restriction applies to all on-premises and BYOL cloud deployments of Oracle Database 19c and later on Standard Edition 2. RAC remains available on Enterprise Edition as an extra-cost option ($23,000/Processor).
- Previous versions: RAC was permitted on SE2 through Oracle Database 18c (with a maximum of 2 nodes and 2 sockets per node). Organisations running 12c, 12.2, or 18c SE2 RAC are not affected — until they upgrade.
- Compliance risk: Organisations that upgrade to 19c SE2 and continue running RAC are out of compliance. An Oracle audit would retroactively require Enterprise Edition + RAC option licences for the entire cluster — a six-figure to seven-figure exposure depending on core count.
- Replacement feature: Oracle introduced Standard Edition 2 High Availability (SE2HA) in 19c — a cold-failover clustering solution that provides automatic restart on a standby node, but not active-active clustering.
- No price reduction: Oracle did not reduce SE2 licence prices or support fees despite removing RAC. Customers pay the same (or more, with annual support increases) for fewer capabilities.
SE2 vs Enterprise Edition with RAC: The Cost Gap
The financial impact of the RAC removal is stark. Standard Edition 2 is licensed per socket at $17,500, while Enterprise Edition is licensed per core (with Core Factor) at $47,500/Processor — and RAC is an additional $23,000/Processor option on top of Enterprise Edition. The difference is not incremental — it is an order-of-magnitude cost increase.
| Cost Element | SE2 (2-Node, 2 Sockets) | EE + RAC (2-Node, 16 Cores Each) |
|---|---|---|
| Licence metric | Per socket | Per core (with 0.5 Core Factor for Intel) |
| Licence count | 2 socket licences | 32 cores × 0.5 = 16 Processor licences |
| Base licence cost | 2 × $17,500 = $35,000 | 16 × $47,500 = $760,000 |
| RAC option cost | Included (pre-19c) / Removed (19c+) | 16 × $23,000 = $368,000 |
| Total licence cost | $35,000 | $1,128,000 |
| Annual support (22%) | $7,700/year | $248,160/year |
| 5-year total (licence + support) | $73,500 | $2,368,800 |
"Moving from SE2 to Enterprise Edition with RAC on the same hardware represents a 32× cost increase in this scenario. Even with aggressive negotiation securing 50% discount, the EE + RAC path costs $1.18M over 5 years — still 16× more than SE2. This cost reality is why most organisations should exhaust every alternative before accepting the Enterprise Edition upgrade path."
SE2 High Availability (SE2HA): The Official Replacement
Oracle introduced SE2HA in 19c as its answer to the RAC removal. SE2HA uses Oracle Clusterware to provide automatic failover: the database runs on one active node, and if that node fails, Clusterware automatically restarts the database on a standby node. It is included in the SE2 licence at no additional cost.
Included in SE2 Licence — No Extra Cost
One active database instance at any time. If the active node fails, Oracle Clusterware automatically starts the database on the standby node. Recovery time depends on database size and instance startup — typically 2–10 minutes for unplanned failover. No load balancing, no parallel query across nodes, no rolling patches. The standby node must remain idle except during failover — Oracle's 10-day rule limits standby usage to 10 days per calendar year without additional licensing. Suitable for workloads with moderate availability requirements (e.g., 99.9% uptime target).
EE Base ($47,500/Core) + RAC Option ($23,000/Core)
Multiple active database instances running simultaneously across cluster nodes. True load balancing, connection failover, and parallel query processing. Rolling patches and upgrades with zero planned downtime. Automatic workload redistribution on node failure — near-zero unplanned downtime. No restrictions on standby usage. Required for mission-critical applications demanding 99.99%+ uptime. Cost: 20–30× more than SE2 on equivalent hardware.
Compliance Risks: What Happens If You Ignore the Change
Organisations that upgrade to 19c SE2 and continue running RAC — whether intentionally or through oversight during a standard database upgrade — face serious compliance exposure. Oracle's Licence Management Services (LMS) team can detect RAC usage through automated audit scripts that examine the cluster configuration, instance counts, and Clusterware status.
| Compliance Scenario | Oracle's Likely Demand | Financial Impact |
|---|---|---|
| Running RAC on SE2 19c | Purchase EE + RAC licences for all cores in the cluster retroactively | $500K–$2M+ depending on cluster size and core count |
| RAC binaries installed but not running | Oracle may argue installation = licensable use | Risk of full EE + RAC demand; arguable but costly to contest |
| Exceeding SE2HA 10-day rule | Licence the standby node as a full SE2 instance (or EE if RAC detected) | $17,500–$47,500+ per additional licence required |
| SE2 on server exceeding 2 sockets | Licence as Enterprise Edition (SE2 is limited to 2 sockets maximum) | Full EE per-core licensing for the server |
Manufacturing Company: Accidental RAC on SE2 19c — $640K Audit Finding
Situation: A European manufacturing company with 3 SE2 RAC clusters (6 nodes total, 2 sockets per node with 12-core processors) performed a routine database upgrade to 19c. The DBA team upgraded the database software but did not reconfigure the cluster topology — RAC continued running on SE2 19c across all 3 clusters.
Audit finding: Oracle LMS detected active RAC configurations on SE2 19c and demanded Enterprise Edition + RAC licences for all 6 nodes: 6 nodes × 24 cores × 0.5 Core Factor = 72 Processor licences of EE ($3.42M) + 72 Processor licences of RAC ($1.66M) = $5.08M total at list price.
Takeaway: Database upgrades must involve the licensing team, not just DBAs. A routine 19c upgrade without architectural review can create seven-figure audit exposure within weeks.
High Availability Alternatives Without Enterprise Edition
SE2HA Cold Failover (Oracle's Official Alternative)
Included in SE2 at no extra cost. Provides automatic restart on standby node via Oracle Clusterware. Recovery time: 2–10 minutes for typical databases. Suitable for most business applications with 99.9% uptime requirements. Ensure the standby node complies with the 10-day failover rule — monitor and document all failover events for audit readiness.
OS-Level or Third-Party Clustering
Windows Server Failover Clustering (WSFC), Linux Pacemaker/Corosync, or commercial solutions like Veritas Cluster Server can provide automatic failover for Oracle databases independently of Oracle Clusterware. These solutions monitor the database process and restart it on a standby node if the primary fails. They achieve similar recovery times to SE2HA without requiring Oracle's clustering infrastructure. Ensure Oracle's licence terms are satisfied — the same 10-day rule applies to the standby node regardless of the failover mechanism used.
Manual Standby with Scripted Failover
Maintain a standby database using RMAN backup/restore or manual redo log shipping (Data Guard is not available on SE2). Custom scripts can automate the promotion of the standby in the event of primary failure. This is lower-cost than any commercial clustering solution but requires more operational effort and typically results in longer recovery times (15–60 minutes depending on database size and script sophistication).
Cloud-Based HA (OCI, AWS, Azure)
Oracle Cloud Infrastructure offers managed database services with built-in high availability — including RAC on Exadata Cloud Service. Moving SE2 workloads to OCI with licence-included subscriptions can provide enterprise-grade HA without on-premises licensing complexity. AWS RDS for Oracle provides Multi-AZ deployment (managed failover) for both Standard and Enterprise editions. Azure offers similar capabilities. Cloud HA converts large capital licensing expenses into operational subscription costs and eliminates the on-premises RAC licensing problem entirely.
Migrate to an Alternative Database Platform
For non-mission-critical workloads where Oracle's cost is prohibitive, evaluate PostgreSQL, MySQL, or MariaDB — all of which offer native replication and clustering at no licence cost. PostgreSQL in particular has mature HA solutions (Patroni, repmgr, pgBouncer) that provide automatic failover comparable to SE2HA. This is a long-term strategic decision requiring application testing and migration effort, but it eliminates Oracle licensing dependency entirely for suitable workloads.
Strategic Options: Decision Framework
| Strategy | Best For | Cost Impact | HA Level |
|---|---|---|---|
| Upgrade to 19c SE2 + SE2HA | Most workloads with moderate HA needs | No additional cost — included in SE2 | Cold failover (2–10 min recovery) |
| Upgrade to EE + RAC | Mission-critical, zero-downtime requirements | 20–30× cost increase over SE2 | Active-active (near-zero downtime) |
| Move to OCI managed DB | Organisations seeking HA without on-prem complexity | Variable — subscription model, potentially lower than EE on-prem | RAC or Data Guard managed by Oracle |
| Stay on 18c or earlier | Short-term only — buying time to plan | No immediate cost change | Existing RAC maintained — but no Oracle support/patches |
| Migrate to PostgreSQL/MySQL | Non-critical workloads; long-term Oracle cost reduction | Eliminates Oracle licensing entirely | Native replication + clustering (comparable to SE2HA) |
Negotiation Strategies When Enterprise Edition Is Unavoidable
For mission-critical databases where active-active RAC is genuinely required and no alternative suffices, upgrading to Enterprise Edition is unavoidable. However, the transition represents significant new spend with Oracle — which creates negotiation leverage. Here are strategies to minimise the cost impact.
First, treat the upgrade as a new deal, not a foregone conclusion. Oracle's sales organisation expects customers affected by the RAC removal to upgrade — use this expectation to negotiate aggressively. Request SE2 licence trade-in credits (Oracle sometimes offers conversion credits for existing SE2 licences applied against EE purchases). Time your purchase for Oracle's fiscal year-end (May) when sales representatives are most motivated to close deals. Bundle the EE upgrade with other planned Oracle purchases (support renewals, cloud credits, additional products) to increase your total deal value and justify deeper discounts.
Second, right-size the Enterprise Edition deployment. You do not need to upgrade every SE2 instance to EE. Categorise your databases by criticality: upgrade only the 2–3 databases that genuinely require RAC, and keep everything else on SE2 with SE2HA. Consolidate RAC databases on the smallest possible hardware footprint — fewer cores means fewer Processor licences. Consider using Oracle-approved hard partitioning (Oracle VM with pinned vCPUs) to limit the licensable core count on EE servers.
Third, explore Oracle's cloud migration incentives. Oracle frequently offers promotional cloud credits, discounted BYOL rates, and support fee reductions for customers migrating on-premises workloads to OCI. If some of your RAC-dependent databases are candidates for cloud deployment, bundling an OCI commitment into the EE negotiation can unlock additional discounts on the on-premises licences. Oracle's sales teams are incentivised to increase cloud revenue — use this to your advantage by presenting a hybrid strategy that includes both on-premises EE upgrades and OCI migration.