1Z0-076: Oracle Database 19c: Data Guard AdministrationDemo

Data Guard Broker requires the primary and standby databases to run the same Oracle Database version. DG_BROKER_START must be set to TRUE before a database participates in the broker configuration. For an Oracle RAC database, the DG_BROKER_CONFIG_FILEn parameters must reference the same shared broker configuration files for every instance of that RAC database; this requirement does not apply to non-RAC databases elsewhere in the configuration.

Maximum Protection guarantees no data loss when the primary fails, and a physical standby can be opened for read-only access to offload queries from the primary. With only that single physical standby, the configuration cannot preserve Maximum Protection while using the standby as a snapshot or transient logical standby for general patch testing, rolling release upgrades, or writable application-release testing. A snapshot standby also cannot be the only standby in a Maximum Protection configuration.

A snapshot standby database is opened read-write and is fully updatable, permitting operations such as dropping tables and creating tablespaces. It can be the target of a manual FAILOVER TO operation; the broker converts it to a physical standby, applies accumulated redo, and transitions it to the primary role. A switchover to a snapshot standby is not allowed, and a dropped tablespace’s data file cannot be restored by Flashback Database.

A physical standby shares the primary database’s DBID and is registered in the recovery catalog in relation to its registered primary database; RMAN does not require a separate, manually ordered standby registration. RMAN catalog metadata also makes backups of standby and nonstandby control files interchangeable, allowing a standby control-file backup to restore the primary control file.

A Far Sync instance maintains an SPFILE, a control file, and standby redo logs. A primary database can send redo to multiple configured Far Sync destinations. By placing a Far Sync instance near the primary, synchronous transport is limited to the short link; the instance forwards redo asynchronously to remote terminal standbys, avoiding the primary database’s direct long-distance transport overhead. Far Sync is supported in Maximum Performance and Maximum Availability modes, and Data Guard Broker is not mandatory for its deployment or management.

The nested broker configuration layout represents a redo route from the primary database through the far sync instance to the physical standby database. A far sync instance receives redo from the primary and forwards it to the downstream physical standby. This forwarding is independent of Fast-Start Failover being disabled and is supported in MaxPerformance mode.

Redo Apply requires CPU, memory, and I/O resources. DB_BLOCK_CHECKING adds data-protection validation overhead during recovery, so lowering its level can improve apply throughput. Recovery workers also read required data blocks into the buffer cache; enlarging that cache reduces physical reads and can improve media-recovery and redo-apply performance.

Synchronous redo transport prevents a transaction from committing until its redo has been successfully sent to the synchronous destination, supporting zero-data-loss protection. A snapshot standby is intended for temporary read/write testing and, when converted back to a physical standby, discards local changes and applies redo received from the primary. A physical standby with real-time query can remain open for reporting while Redo Apply remains active, so it continues to provide data protection.

With COMMIT_OUTCOME set to TRUE, Oracle Transaction Guard retains a transaction’s commit outcome so that, after a recoverable outage, an application can determine whether the transaction committed. The configured RETENTION value specifies how long that outcome is retained.

DBMS_LOGSTDBY.UNSKIP requires an exact match to an existing SKIP rule. Wildcards in schema_name or object_name are not expanded during UNSKIP; consequently, EMP% does not match either EMP_NEW or EMP_OLD. The procedure succeeds but removes neither SQL Apply filter. Oracle DBMS_LOGSTDBY documentation

A logical standby can have different indexes and on-demand-refresh materialized views, isolating DSS auxiliary-structure work from the primary, and it supports rolling patch and release upgrades with minimal downtime. A physical standby remains an exact replica of the primary for testing new application releases. Combining one logical standby with one physical standby is therefore the smallest configuration that provides both capabilities.

A configured fast recovery area can be used as the default local archive destination when an explicit local LOG_ARCHIVE_DEST_n destination has not been configured. Each database must also have a distinct DB_UNIQUE_NAME, which identifies that database independently of its current primary or standby role. COMPATIBLE is specified with the same value when switchover is expected, rather than being an unconditional requirement for every configuration.

SQL Apply divides its configurable process capacity between APPLIER and PREPARER processes. Decreasing the PREPARER count makes capacity available for additional APPLIER processes, while increasing MAX_SERVERS raises the available SQL Apply process capacity. Oracle documents the required relationship between APPLY_SERVERS, PREPARE_SERVERS, and MAX_SERVERS, and identifies MAX_SERVERS, APPLY_SERVERS, and PREPARE_SERVERS as the controls for SQL Apply process allocation.

A PDB’s open mode can be controlled independently while its CDB is open, and a PDB in a physical standby CDB defaults to read-only when opened. Oracle also automatically creates a default service for each PDB; that service has the PDB’s name and identifies the PDB as its initial container. Redo Apply is managed at the physical-standby database level, whereas DB_UNIQUE_NAME and the traditional Data Guard database role are database/CDB-level properties.

Data Guard Broker can fail over to a snapshot standby database by converting it to a physical standby database, applying accumulated redo, and completing the role transition. An immediate failover stops redo or SQL apply without waiting for available redo to be applied; consequently, any apply lag can result in data loss.

Maximum Protection with synchronous affirmed transport guarantees zero data loss by requiring transaction redo to be written to the primary online redo log and persisted in a standby redo log on at least one synchronized physical standby before commit. If that standby is unavailable, the primary shuts down rather than permit unprotected commits. With only one standby, it cannot be converted to a snapshot standby while Maximum Protection remains in effect, because a snapshot standby cannot be the sole standby in that mode. Maximum Protection likewise requires a physical standby, not only a logical standby. Oracle Data Guard supports Oracle RAC for both primary and standby databases.

For a synchronous redo transport destination, NET_TIMEOUT defines how long LGWR waits for acknowledgement of redo receipt. If no acknowledgement arrives within that interval, Oracle logs an error and terminates the redo transport session to that standby destination.

Logical standby SQL Apply can become the bottleneck even when redo reaches the standby without delay. Direct-path or bulk inserts on the primary are applied as conventional INSERT statements on the logical standby, and batch updates are applied as individual row modifications. SQL Apply also stages logical change records in shared-pool memory, so insufficient shared-pool capacity can cause memory pressure and pageouts. Missing usable unique indexes can make SQL Apply perform full table scans for row modifications, substantially reducing apply throughput.

The observer reconnects to an unreachable primary for the configured 30-second threshold before initiating fast-start failover. A 30-second Fast-Start Failover Lag Limit applies to a maximum-performance configuration. Because the Corrupted Controlfile health condition is enabled, its detection initiates fast-start failover without waiting for the failover threshold, provided the target is eligible to accept the failover.

Maximum Performance mode minimizes primary-database impact by using asynchronous redo transport. A logical standby can create and maintain local materialized views, offloading that work from the primary, and SQL Apply supports rolling upgrades to a new database release with minimal downtime. Certified Standby-First patches require a physical standby using Redo Apply, while exact production-replica testing in a read-write standby is provided by a snapshot physical standby, not a logical standby.

Fast-Start Failover is a Data Guard Broker capability. In the legacy prerequisite set, the broker configuration must use Maximum Availability or Maximum Performance mode, and Flashback Database must be enabled on both the primary database and target standby database so that the former primary can be reinstated after failover.

Oracle Active Data Guard lets a physical standby remain open for read-only real-time queries while Redo Apply continues, enabling reporting to be offloaded. It also supports offloading incremental backups to the standby. Asynchronous redo transport avoids the primary database waiting for remote standby acknowledgment, avoiding the synchronous transport latency that could materially affect primary performance.

With fast-start failover enabled, a manual failover must be directed to the configured target, be synchronized in maximum availability mode, have an active observer, and have the primary database shut down before the manual failover. Because Cats remains the configured primary in the displayed successful configuration, the broker rejects the failover rather than completing it. The automatic-reinstate and primary-shutdown settings apply to defined fast-start-failover conditions, not to authorizing a manual failover while the primary is still active.

Oracle Data Guard Broker retains a database profile that identifies the standby type. After an out-of-band conversion from physical to logical standby, the stale physical-standby profile must be removed from the broker configuration. The converted database can then be added as a logical standby and enabled, creating metadata consistent with its current role and apply method. The REMOVE DATABASE command deletes the standby profile from the broker configuration; Fast-Start Failover is disabled here, so its target-removal restriction does not apply.