1Z0-076 Oracle Database 19c: Data Guard Practice Questions

While standby redo logs are primarily used on a standby to receive redo, they should also be configured on the primary database. Their purpose on the primary is to be ready for a future role transition. After a switchover, the old primary becomes the new standby. If SRLs are already configured, it can immediately start receiving redo from the new primary without any delay or manual intervention, ensuring a smooth and fast role reversal.

When a switchover fails after the standby has become the new primary, the immediate goal is to complete the role reversal. The old primary is likely in a state where it just needs to be properly configured as a standby. The correct procedure is to manually mount the old primary database, convert it to a physical standby using ALTER DATABASE CONVERT TO PHYSICAL STANDBY, and then start redo apply. Once it's functioning as a standby, the Broker configuration can be re-enabled and validated.

The ApplyLagThreshold property of a standby database in the Broker configuration defines the acceptable apply lag in seconds. If the actual apply lag exceeds this value, the Broker will report a WARNING status for the standby database. This is a crucial property for monitoring the health and RTO readiness of a standby.

Application Continuity works by capturing and replaying the transactional history of a session. However, it does not capture nontransactional session state changes, such as those made by ALTER SESSION. If an application relies on such custom session settings, these settings will be lost upon reconnection to the new primary, which can cause queries to fail or produce different results. This is a common reason for replay failure.

The correct and required sequence is to register the primary database in the recovery catalog first. The standby database is a copy of the primary, and the catalog needs to know about the source database before it can associate the standby with it. Attempting to register the standby first will result in an error because the catalog will not recognize its DBID as belonging to a known database.

In Maximum Availability mode, if the primary database cannot contact the SYNC destination (in this case, the Far Sync instance), it will not shut down. Instead, it temporarily operates as if it were in Maximum Performance mode to prioritize primary database availability. Once connectivity is restored, it will automatically resynchronize and revert to Maximum Availability behavior. Shutting down is characteristic of Maximum Protection mode.

FastStartFailoverThreshold defines how long (in seconds) the observer waits after detecting a primary failure before initiating a failover. Increasing this value makes it less sensitive to short outages. ObserverReconnect specifies the time (in seconds) the observer waits before attempting to reconnect to the primary. Together, these properties help prevent unnecessary failovers due to transient network issues. FastStartFailoverLagLimit is related to data loss tolerance, not network glitch tolerance. ObserverOverride is used to force a failover when the observer disagrees with the standby's assessment.

The MaxConnections attribute for the LOG_ARCHIVE_DEST_n parameter, when set to a value greater than 1, allows the redo transport destination to use multiple network connections. This enables redo data from multiple LGWR processes on a busy primary system to be transmitted in parallel or aggregated, which can significantly improve redo transport throughput and reduce the performance impact on the primary database.

This statement is false. A key feature of a snapshot standby is that while it is open in read-write mode for testing, it continues to receive redo data from the primary database. The redo is archived but not applied. When the snapshot standby is converted back to a physical standby, the changes made are discarded using Flashback Database, and the accumulated redo is then applied, quickly resynchronizing it with the primary.

When Flashback Database is enabled, the REINSTATE command is highly efficient. The Broker's first action is to use Flashback Database to rewind the old primary to the SCN just before the failover occurred. This avoids a full restore. After the flashback, it converts the database into a standby of the new primary and begins applying the archived redo logs received from the new primary to catch up.