Free 1Z0-076 Practice Test

The DGMGRL SHOW CONFIGURATION output explicitly states, "Observer is not running." Therefore, the observer cannot be connected to any database, making option E true. A bystander database is any standby in a Data Guard configuration that is not the designated fast-start failover target. Since Fast-Start Failover is disabled in this configuration, there is no target. Consequently, the standby database 'Cats' is not the target and can be considered a bystander.

A. The output clearly states "Observer is not running," so it cannot be connected to the primary database or any other database.
B. The output explicitly shows "Observer is not running," contradicting the claim that it is running on any host.
C. The provided output does not contain information about the configured observer host, so we cannot determine where it should run.

1. Oracle Database Administration Documentation, 19c. Data Guard Broker. "SHOW CONFIGURATION". The command output format includes the observer status.

2. Oracle Database Administration Documentation, 19c. Data Guard Concepts and Administration. Glossary. Defines a "bystander standby database" as one that is not the fast-start failover target. When FSFO is disabled, no standby is the target.

The Data Guard Broker is the Oracle framework designed to simplify the management and monitoring of a Data Guard configuration. It automates complex tasks and provides a single point of control. The broker can be managed through two interfaces: the command-line interface DGMGRL and the graphical interface provided by Enterprise Manager Cloud Control. Both tools can manage multiple standby databases, simplify role transitions (switchover, failover), handle reinstatements, convert to snapshot standbys, and automate failover using Fast-Start Failover.

A. RMAN is used for backup, recovery, and database duplication (including standby creation), not for managing Data Guard role transitions or broker automation.
B. SQLPlus can execute the underlying commands for role transitions, but it does not simplify or automate the process; it is entirely manual.
C. CRSCTL is a Clusterware utility used to manage cluster resources, not Data Guard configurations.
F. SRVCTL is a utility for managing RAC databases and their services, not for Data Guard role management.
G. GDCCTL is not a standard Oracle tool for Data Guard management.

1. Oracle Data Guard Broker, 19c, E96602-13, Chapter 1, "Introduction to Oracle Data Guard Broker". This chapter introduces the broker and its two clients: "Oracle Enterprise Manager Cloud Control... and the Oracle Data Guard command-line interface (DGMGRL)".

2. Oracle Data Guard Broker, 19c, E96602-13, Section 1.2, "Oracle Data Guard Broker Management Model". This section details how the broker simplifies switchovers, failovers, and other management tasks.

3. Oracle Data Guard Broker, 19c, E96602-13, Chapter 4, "Enabling Fast-Start Failover". This chapter describes how to use the broker (via DGMGRL or Enterprise Manager) to automate failovers.

Fast-Start Failover (FSFO) requires synchronous transport (SYNC or FASTSYNC) between the primary and the designated target standby, and the primary’s LogXptMode must therefore not be ASYNC. In addition, each primary and its target standby must have the FastStartFailoverTarget property set. If these conditions are missing, Broker raises ORA-16693 when you attempt to enable FSFO.

C. Transport mode on a non-target standby (Cats) is irrelevant to FSFO requirements.
E. FASTSYNC on the primary (Dogs) is an allowed synchronous transport and therefore satisfies FSFO prerequisites.

1. Oracle Data Guard Broker Admin Guide 19c, Sec. 6.2 “Fast-Start Failover Requirements” (F32926-21, p. 6-3).

2. Oracle Database 19c Data Guard Concepts & Administration, Sec. 12.3 “Synchronous Redo Transport Modes” (E96232-24, p. 12-5).

3. Oracle Doc ID 1625597.1 “ORA-16693 when Enabling FSFO” (Oracle Support, official).

The requirements are: maximum protection, reporting on a physical standby, no reporting lag, and resilience to a single network failure.
- Maximum Protection: Requires SYNC redo transport to at least one standby. The primary will shut down if it cannot confirm the redo has been written at a synchronized standby.
- Resilience: To survive a single network failure to a standby without shutting down, the primary must have at least two SYNC destinations. If one fails, it can continue operating as long as the other is available.
- Reporting/No Lag: Requires a physical standby with Active Data Guard (Real-Time Query). A SYNC standby ensures data is current, eliminating lag.
Option A fulfills all these conditions by proposing two standbys (providing resilience) with SYNC transport (for max protection), with at least one being a physical standby with Real-Time Query (for reporting with no lag).

B. Asynchronous (ASYNC) transport does not support maximum protection mode; it is used for maximum performance mode.
C. A single physical standby does not provide resilience to a network failure in maximum protection mode; the primary would shut down.
D. A single physical standby, like in option C, creates a single point of failure for the network connection, violating the resilience requirement.
E. SYNC NOAFFIRM is not used for maximum protection mode. Maximum protection requires SYNC AFFIRM to ensure redo is written to standby redo logs before the primary transaction commits.

1. Oracle Data Guard Concepts and Administration 19c, "Maximum Protection", Section 4.2.1. This section states that this mode requires at least one standby database be configured with the SYNC transport mode.

2. Oracle Database High Availability Best Practices 19c, "Data Guard Protection Modes", Section 4.2.3, Page 26. It explains that for Maximum Protection, "To avoid a primary outage due to a network or standby failure, Oracle recommends a minimum of two SYNC standbys".

3. Oracle Data Guard Concepts and Administration 19c, "Using an Active Data Guard Standby for Real-Time Reporting", Section 9.2. This section describes using Real-Time Query, which is only possible on a physical standby.

For RMAN active duplication to a separate host, the primary database must already archive redo (ARCHIVELOG), the standby instance must be started NOMOUNT so that RMAN can create the control file, and Oracle Net connectivity between primary and standby must exist for RMAN’s network-based copy. No user-equivalence is required, and DBUNIQUENAME on the primary can remain the same as DBNAME.

B. RMAN active duplication uses Oracle Net, not OS-level file copying; no operating-system user equivalence is mandated.
D. Only the DBUNIQUENAMEs of the two databases must differ; the primary’s DBUNIQUENAME may equal its DBNAME.

1. Oracle Database Backup and Recovery User’s Guide 19c, §26.3.3 “Using RMAN to Duplicate from an Active Database” (p. 26-23).

2. Oracle Data Guard Concepts & Administration 19c, §3.1 “Configuring Standby Databases” (p. 3-4).

3. Oracle Net Services Administrator’s Guide 19c, §4 “Configuring Connectivity” (p. 4-1).

A single logical standby database meets all stated requirements with the fewest number of databases. Because a logical standby is open for read-write access while applying changes, it can host its own bitmap indexes and materialized views, offloading their maintenance from the primary (permanent requirements). It also serves as an up-to-date replica for application testing. Furthermore, a logical standby can be used for rolling patches and database release upgrades to minimize downtime, thus satisfying all the temporary requirements.

B. Two logical standby databases would work, but the question asks for the solution with the "fewest of databases." One is sufficient.
C. A physical standby is a block-for-block copy and cannot have its own independent indexes or materialized views, failing the permanent requirements.
D. Two physical standby databases would also fail the permanent requirements for the same reason as a single physical standby.
E. This configuration works but requires an additional database (one logical and one physical standby) compared to using a single, capable logical standby.

1. Oracle Data Guard Concepts and Administration, 19c, E96601-16, Section 1.4.2, "Logical Standby Databases". This section explains that a logical standby is updated using SQL statements and can be used for other tasks concurrently with SQL Apply.

2. Oracle Data Guard Concepts and Administration, 19c, E96601-16, Section 12.1, "Using a Logical Standby Database for Rolling Upgrades". This section confirms that logical standbys can be used to perform rolling upgrades of database software.

3. Oracle Database High Availability Best Practices, 12c, Page 17. "A logical standby database can be used to offload reporting activities from the primary database... It is possible to create additional indexes and materialized views on the logical standby to improve query performance."

The Data Guard Monitor (DMON) process is the core component of the Data Guard Broker. It is responsible for managing and monitoring the entire Data Guard configuration. Its key tasks include maintaining the configuration's state in binary files, coordinating and executing role transitions like switchovers and failovers upon request, and managing role-dependent database services to ensure they are active only on the appropriate database (typically the primary).

D. The observer is a separate client process, not a database process with its own DMON. The observer communicates with the DMON processes on the primary and standby databases.
E. There is no Oracle background process named "dkon". The broker's background process is DMON, which communicates with other DMON processes in the configuration.

1. Oracle Database Documentation, 19c, Data Guard Broker, Chapter 1, "Oracle Data Guard Broker Components", Section "The Data Guard Monitor Process". This section details the responsibilities of the DMON process, including maintaining configuration files and managing state transitions.

2. Oracle Database Documentation, 19c, Data Guard Broker, Chapter 4, "Role Transitions", Section "Performing a Switchover". This describes the broker's role in coordinating the switchover, which is handled by the DMON process.

3. Oracle Database Documentation, 19c, Data Guard Broker, Chapter 5, "Managing Client Connectivity", Section "Managing Services". This section explains how the broker manages role-based services.

Flashback Database is a critical feature for rapid recovery in a Data Guard environment. It is fully compatible with real-time apply, allowing a physical standby to be quickly reverted to a point-in-time before a logical error (like an accidental table drop) was propagated from the primary. This capability is unaffected by the redo transport path, meaning a physical standby can be flashed back even if it receives its redo from a far sync instance. However, while Flashback Database is the primary method for reinstating a failed primary after a failover to a physical standby, it cannot be used for reinstatement after a failover to a logical standby due to the structural database changes that occur.

A. A Flashback Database operation on the primary is not automatically cascaded to a physical standby. The standby must be flashed back independently.
E. Flashback Database is the recommended method to efficiently reinstate a former primary database as a new standby after a failover to a physical standby.
F. Flashback Database is a physical-level operation and is not automatically propagated to a logical standby, which applies changes at the SQL level.

1. Oracle Database Data Guard Concepts and Administration, 19c - Chapter 13, Using Flashback Database and Restore Points in a Data Guard Environment:

For option D: Section 13.4, "Using Flashback Database for Recovery from Logical Corruptions," states, "You can use Flashback Database on a physical standby database to quickly recover from logical corruptions that have been propagated from the primary database. This is particularly valuable when real-time apply is in use..."

For option B & E: Section 13.6, "Using Flashback Database and Database Open Resetlogs," explicitly states, "You cannot use Flashback Database to return a primary database to a point in time before a failover to a logical standby." Conversely, Section 13.5, "Using Flashback Database After a Failover," describes its use to "convert the original primary database into a physical standby of the new primary database," directly contradicting option E.

2. Oracle Database Data Guard Concepts and Administration, 19c - Chapter 5, Far Sync Instances:

For option C: This chapter describes far sync instances as lightweight instances that only forward redo to other members of the configuration. The physical standby that receives this redo operates normally, including its ability to use local features like Flashback Database. The source of the redo does not alter the standby's capabilities.

3. Oracle Database High Availability Overview, 19c - Chapter 3, Oracle Data Guard:

For options A & F: The documentation describes Flashback Database as a command executed on a specific database (primary or standby). There is no mention of an automatic, cascading operation across the Data Guard configuration. Each database's flashback operation is independent.

The DGMGRL EDIT DATABASE ... SET PARAMETER command is used to manage initialization parameters within a Data Guard configuration.
A. The command works for static parameters by issuing an ALTER SYSTEM ... SCOPE=SPFILE command. The change takes effect upon restart.
C. The broker must be able to connect to the database instance to issue the ALTER SYSTEM command, so the database must be available.
E. The command's primary function is to connect to the specified database instance and execute an ALTER SYSTEM command to apply the parameter change, either to the running instance (for dynamic parameters) or the SPFILE.

B. This statement is false. The command can modify both dynamic and static initialization parameters.
D. While the broker configuration is updated to reflect the new parameter setting, the primary action is applying the change to the database itself. The term "directly stored" is less accurate than "directly applied."

1. Oracle Data Guard Broker, 19c, Chapter 8, "DGMGRL Command-Line Interface". The documentation for the EDIT DATABASE command states: "The broker propagates the property change to the server parameter file... For a dynamic parameter, the broker also alters the current running instance... The database must be enabled for this command to succeed." This confirms that it works for static parameters (A), requires the database to be available (C), and applies the change to the database (E).

Enabling block change tracking on a physical standby starts the Recovery Writer (RVWR) process, which records changed block information in the standby’s change-tracking file. This information lets RMAN perform fast incremental backups that can be completely off-loaded to the physical standby, preserving resources on the primary while still providing recoverable backups.

B – CTWR is started on the database where change tracking is enabled; enabling it on the standby does not start CTWR on the primary. C – Snapshot standby functionality is unrelated to block change tracking. D – The CTWR process is not used on a physical standby; RVWR maintains the bitmap. F – Primary database could already use its own change tracking; enabling it on the standby affects only the standby.

1. Oracle® Database 19c Backup and Recovery User’s Guide, “Block Change Tracking on Physical Standby Databases”, §5.8 (Doc-ID F30993-06).

2. Oracle® Database 19c Reference, “RVWR—Recovery Writer Process”, Background Processes Appendix.

3. Oracle® University Course “Oracle Database 19c: Backup and Recovery”, Lesson 6, slide 22.