Introduction
In addition to its data protection capabilities, Oracle Data Guard provides additional features for workload scale-out, backup offload, and online maintenance and upgrade operations. Some features require the Active Data Guard (ADG) option license, and some do not. Sometimes the “little things” you need to be aware of make the difference. This blog post highlights these features and others that many usually think require the Active Data Guard option, but they don’t.
Before we begin, the single source of truth remains the Database Licensing Information User Manual.
Open Standby in Read-Only Mode
The standby database can be opened in read-only mode without having the ADG option license IF Redo Apply is stopped.
ADG is required when opening the standby in read-only mode while Redo Apply is in progress. This is called Real-time Query. The benefit is to have query results that are identical to what would be returned from the primary database.
Backup on Physical Standby
As a physical standby database is a block-by-block exact copy of the primary database, backups on physical standby can be used to recover the primary database and vice versa. Offloading the backup to the standby system frees resources on the primary that can be used for the production workload. The standby system provides a better Return On Investment (ROI) as it does some work and does not just hang around and remain idle until after an outage.
Backup on Physical Standby does not require ADG per se. What requires ADG is Fast Incremental Backup on Physical Standby having Block Change Tracking (BCT) enabled. The benefit is using even fewer resources on standby.
Cascading Standby
Another task that can be offloaded to a standby database is the redo transport when using multiple standby databases. Instead of having the primary transmitting redo to all standbys, the primary transmits redo to one standby (cascading standby) that forwards the redo to the remaining standbys (cascaded standbys, also called final destinations).
Cascading does not require ADG if it happens at the log switch. What requires ADG is Real-Time Cascade forwarding the redo immediately after being received. The benefit is that cascaded standbys (terminal destinations) provide the most recent data for reading applications and have fewer data loss in case of simultaneous failures on primary and cascading standby. This provides nearly the same level of data protection as any standby database that receives redo directly from a primary database using asynchronous redo transport.
Rolling Upgrade
You can use a logical standby database to perform major database release upgrades in a rolling manner incurring minimal downtime on the primary database. For upgrading, you can create a new logical standby database, use an existing logical standby, or convert an existing physical standby into logical standby. After upgrading, the logical standby, you can test and validate the new database major release without affecting the primary.
Rolling Upgrade using SQL Apply does not require ADG. What requires ADG is Rolling Upgrade using DBMS_ROLLING PL/SQL package. The benefit is that DBMS_ROLLING provides a streamlined and automated method of performing rolling upgrades with comprehensive feature support.
FastSync
FastSync is a redo transport mode that can be used in maximum availability mode. It ensures that redo is transferred synchronously and received by the standby database before the commit acknowledgment is sent back to the application. It does not wait for disk I/O to the standby redo logs, reducing the latency (fast) and enhancing transaction throughput on the primary.
FastSync does not require ADG. What requires ADG is Far Sync, a very different feature that sounds similar to FastSync. A Far Sync instance is a remote Data Guard destination that accepts redo from the primary and then ships that redo to other members of the Data Guard configuration. More on the benefits of FarSync in this blog post.
Snapshot Standby
A snapshot standby is a standby database open in read/write mode. You can use it for testing and development, reporting where read/write is required, or extracting data via Data Pump, as my dear colleague Daniel describes in this blog post.
The primary database is still protected, as the snapshot standby continues receiving and archiving redo. However, it does not apply the received redo until all local updates are discarded, and it’s converted back to physical standby. If the primary fails and this is your only standby, then the failover time will be higher. Make sure you have at least an additional standby for disaster recovery.
Snapshot Standby does not require ADG.
Fast-Start Failover (FSFO)
Fast-Start Failover (FSFO) automatically initiates a failover to a specified target standby when the primary database becomes unavailable. It reduces the Recovery Time Objective (RTO) tremendously as it does not need any human intervention by automatically detecting failures on the primary and immediately failing over to the standby.
FSFO does not require ADG. You only need an additional lightweight server that runs the Observer optimally in a different data center than the primary and standby. Additionally, you can enable automatic reinstatement of the failed primary after FSFO has occurred.
Further Features that REQUIRE ADG
The following features indeed require the Active Data Guard option license:
- Automatic Block Repair.
- Application Continuity.
- DML Redirection.
- Global Data Services.
- PDB Recovery Isolation (21c).
Check the Database Licensing Information User Manual and/or the Features and Licensing app for a complete list.
Conclusion
Oracle Data Guard provides data protection and features for higher availability, resiliency, scalability, and testing and development. Some features require the Active Data Guard option license, and some do not. Sometimes it is the “little” detail that makes the difference. Always look at the documentation and licensing manual before using any feature if you are unsure about it.
Database Heartbeat 