Oracle Data Guard Licensing:
Active vs Standard & Standby Database Rules

Oracle Data Guard Licensing: The Line Between Free and $11,500 Per Processor

Oracle Data Guard licensing is one of the most misunderstood areas in the Oracle database stack, and the financial consequences of getting it wrong are severe. Standard Data Guard ships with every Oracle Database Enterprise Edition license at no additional cost. It provides real time redo log shipping, automatic failover, and disaster recovery protection. Active Data Guard, by contrast, is a separately licensed Enterprise Edition option priced at $11,500 per processor. The distinction between the two comes down to a single technical behavior: whether the standby database is open for read access while redo apply is running. Understanding this boundary is critical for any enterprise running Oracle disaster recovery, and our Oracle Audit Risk Assessment can help you quantify your current exposure before Oracle's LMS team does.

The problem is that this line is extraordinarily easy to cross. A DBA opens a standby database for read access to offload reporting queries. A BI team routes month end reports to the standby to reduce primary database load. A third party monitoring tool connects to the standby in read only mode. In every one of these scenarios, the enterprise has triggered Active Data Guard licensing obligations across every processor on both the primary and standby servers, regardless of whether anyone intended to use ADG functionality.

Standard Data Guard vs Active Data Guard: The Technical Licensing Boundary

With standard Data Guard, the standby database must remain in mount state. It receives redo data from the primary and applies it, but it is not open for any user connections. This is the free configuration included with your Oracle Database Enterprise Edition license at $47,500 per processor. The moment you open that standby database for read only access while redo apply continues, you have crossed into Active Data Guard territory. Oracle's licensing position is unambiguous: any standby database that is simultaneously open for reads and applying redo data requires Active Data Guard licenses on both the primary and every standby server.

This means a typical two node configuration (one primary, one standby) requires Active Data Guard licenses on both servers. On a four processor primary and four processor standby, that is 8 processors at $11,500 each, totaling $92,000 in license fees alone, plus 22% annual support ($20,240 per year). Many enterprises discover this obligation only after Oracle's License Management Services team presents an audit finding. For a deeper understanding of how Oracle database processor licensing works alongside options like Oracle RAC, the cost implications compound even further in clustered environments.

The 10 Day Failover Rule and Its Limits

Oracle's licensing policies include a failover exception that allows an unlicensed standby server to run the primary database for up to 10 separate 24 hour periods in any given year. This is designed to cover legitimate disaster recovery testing and actual failover events. However, this rule applies only to cold standby scenarios where the standby is not performing any productive work while the primary is operational. The 10 day rule does not apply to Active Data Guard. If your standby is open for read queries at any point while redo apply is active, the failover exception is irrelevant. Oracle will demand full processor licensing for every day the standby operated in that mode, and our Oracle audit defense resources detail exactly how LMS teams build these claims.

In one documented case, Oracle's LMS audit scripts detected that a standby database had been opened for read only queries by a business intelligence team for approximately two hours each month end. Despite the limited duration of roughly 24 hours total across the year, Oracle classified this as Active Data Guard usage and generated a $1.2M compliance claim for unlicensed ADG processors across the standby cluster. The lesson is clear: duration does not matter. Even two hours of read access on a standby with redo apply running constitutes Active Data Guard usage in Oracle's view.

Audit Evidence: How Oracle Proves Active Data Guard Usage

Oracle's LMS team does not rely on your word about how the standby is used. Their audit scripts query the DBA_FEATURE_USAGE_STATISTICS view, which records every instance of Active Data Guard feature usage across the database lifetime. This view captures when the standby was opened for reads, when real time query was enabled, and when redo apply ran concurrently with an open database. The data is timestamped and persistent. Even if you correct the configuration today, historic usage remains in the data dictionary as permanent evidence.

Verbal assurances carry no weight in an Oracle audit. What matters is the technical evidence in DBA_FEATURE_USAGE_STATISTICS and the configuration parameters captured by LMS collection scripts. Organizations that lack proper documentation of their Data Guard architecture frequently face inflated compliance claims because they cannot demonstrate that a standby was in mount state rather than open for reads. For enterprises navigating the latest Oracle database changes, our guide to Oracle Database 23ai licensing covers how new features interact with Data Guard licensing obligations. Download our Oracle Total Cost Optimisation playbook for the complete framework on reducing database licensing spend.

Protecting Your Enterprise: Compliance Best Practices

The most important step is to audit every standby database in your environment and confirm its operational state. If any standby is open for reads while applying redo, you are using Active Data Guard and must license it accordingly. If you do not need read access on the standby, ensure it remains in mount state and document this configuration in your licensing records. For environments where read access on the standby delivers genuine business value, the economics of licensing ADG should be weighed against the cost of provisioning a separate reporting database.

Maintain a detailed license inventory that maps every primary and standby pair, documents the Data Guard mode in use, and records processor counts on both servers. This documentation is your first line of defense in any Oracle audit. For enterprises managing multiple vendor renewals simultaneously, our Vendor Shield subscription provides ongoing advisory coverage across all major vendors, including continuous monitoring of Oracle compliance posture. To assess your current risk, book a confidential call with our Oracle licensing team. We have helped clients resolve Data Guard compliance disputes and avoid millions in unnecessary licensing fees, as documented in our client case studies. Additional research and resources are available in our white papers library.