Oracle Database 19c: Data Guard Free Sample Questions

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.

The DB_FILE_NAME_CONVERT parameter is used to specify how to convert primary database datafile paths to standby database datafile paths. RMAN's DUPLICATE command reads this parameter from the auxiliary (standby) instance's parameter file to automatically create the standby datafiles in the correct location. The format is ('string1', 'string2'), where string1 is the pattern in the primary location and string2 is the pattern for the standby location.

When the primary database is shut down gracefully, the Broker recognizes this as a controlled event, not an error. The overall configuration is still considered valid and will report a status of SUCCESS. However, the state of the primary database itself will change to reflect that it is no longer transporting redo, typically shown as LOG-TRANSPORT-OFF. An ERROR status would imply an unexpected failure.

The DBMS_LOGSTDBY.SKIP procedure is used to create rules for SQL Apply. To skip DDL for a specific object while allowing DML, the statement_opt should be set to 'SCHEMA_DDL' and the schema_name and object_name parameters should be specified. Using 'TABLE' would skip both DDL and DML for the object. This provides granular control over what gets applied on the logical standby.

Redo transport compression can be configured on a per-destination basis. By adding the COMPRESSION=ENABLE attribute to the specific LOG_ARCHIVE_DEST_n parameter that points to the reporting standby, compression will be enabled only for that redo stream. This allows for granular control, leaving the transport to the other DR standby uncompressed if desired. This feature requires an Active Data Guard license.

This statement is true. The VALIDATE DATABASE command is a powerful diagnostic tool within DGMGRL. It performs a comprehensive check of the specified database's readiness for its role, which includes verifying that standby redo logs (SRLs) are properly configured. It checks for correct size, number of groups, and whether they are being used, which is critical for higher protection modes.