DEV Community

Cover image for 1Z0-076 in One DGMGRL Session: Build, Check, Switch Over and Fail Over a Data Guard Pair
DBExam Study Notes
DBExam Study Notes

Posted on

1Z0-076 in One DGMGRL Session: Build, Check, Switch Over and Fail Over a Data Guard Pair

Oracle's 1Z0-076 exam checks whether you can run Oracle Data Guard 19c from a fresh standby all the way to a failed-over primary, and much of that work happens in one tool: the Data Guard broker command line, DGMGRL. If you can run the session below on a two-database lab and explain every line of its output, you have worked through 7 of the 19 topic groups on the exam page.

The exam, as listed on Oracle's 1Z0-076 exam page on MyLearn on 16 October 2026, has 74 multiple-choice questions, a 120-minute limit and a passing score of 61%, taken proctored online. The page shows no fee to a signed-out visitor; DBExam's syllabus page lists USD $245, which varies by country.

Every command and sample message below comes from the Oracle Database 19c Data Guard Broker guide. The names are the ones Oracle's own examples use: a configuration called DRSolution, a primary called North_Sales and a physical standby called South_Sales. That way you can read this post next to the documentation, line by line.

What do you need before the first DGMGRL command?

You need a primary and a physical standby that already exist and already exchange redo. Building that standby is its own topic group (the exam names the RMAN command DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE), so it sits outside this session.

Three details from Oracle's guide decide whether the first commands work:

  • The account you connect with needs the SYSDG or SYSDBA privilege on both databases. A CONNECT with no AS clause logs in as SYSDBA.
  • Each broker member name must match that database's DB_UNIQUE_NAME. Check it in SQL*Plus with SHOW PARAMETER DB_UNIQUE_NAME.
  • Remote redo destinations (LOG_ARCHIVE_DEST_n) on the standby must be cleared first. If they are not, creating the configuration fails with ORA-16698. Destinations on the primary can stay as they are.

Also give both databases standby redo log files now. Several later steps refuse to run without them.

How do you create and enable the broker configuration?

Start DGMGRL on a host where Data Guard is installed, connect to the primary, create the configuration with only the primary in it, and then add the standby:

$ dgmgrl
DGMGRL> CONNECT sysdg@North_Sales.example.com;
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
> PRIMARY DATABASE IS 'North_Sales'
> CONNECT IDENTIFIER IS North_Sales.example.com;
DGMGRL> ADD DATABASE 'South_Sales' AS
> CONNECT IDENTIFIER IS South_Sales.example.com;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> SHOW CONFIGURATION;
Enter fullscreen mode Exit fullscreen mode

Until ENABLE CONFIGURATION runs, SHOW CONFIGURATION reports a status of DISABLED, which means the broker is not managing anything yet. Afterwards the same command shows Protection Mode: MaxPerformance, both members, Fast-Start Failover: DISABLED and a status of SUCCESS. Learn to read that one screen quickly, because the monitoring topic group expects it.

Which newer broker commands should you know by name?

Two objective lines ask you to "list the new" broker commands: one for VALIDATE commands and one for commands in general. Oracle's Data Guard Broker release notes for 18c and 19c name them:

  • Release 18c added VALIDATE DATABASE SPFILE, VALIDATE NETWORK CONFIGURATION and VALIDATE STATIC CONNECT IDENTIFIER.
  • Release 19c added EXPORT CONFIGURATION and IMPORT CONFIGURATION, the EDIT DATABASE ... SET PARAMETER family for initialization parameters, SET TRACE_LEVEL, SET FAST_START FAILOVER TARGET, and an observe-only mode for fast-start failover.

Run the three VALIDATE checks right after you enable the configuration, while nothing depends on it yet:

DGMGRL> VALIDATE NETWORK CONFIGURATION FOR ALL;
DGMGRL> VALIDATE STATIC CONNECT IDENTIFIER FOR ALL;
DGMGRL> VALIDATE DATABASE South_Sales SPFILE;
Enter fullscreen mode Exit fullscreen mode

The first command tests connectivity between the instances, using each database's DGConnectIdentifier property. The second connects through the static service the broker needs when it restarts a database during a role change. The third compares the SPFILE entries of the primary and the named standby, and prints "No parameter differences found" when they match. It will not run against the primary itself.

One trap sits in Oracle's own examples. The 19c guide still sets the log file name format with EDIT DATABASE 'South_Sales' SET PROPERTY 'LogArchiveFormat'=..., yet the same release deprecates LogArchiveFormat and eight other properties that map to initialization parameters. For those, 19c tells you to use EDIT DATABASE ... SET PARAMETER instead, and that is the form to pick when a question asks what is current.

How do you move from MaxPerformance to MaxAvailability?

A new configuration starts in maximum performance mode with ASYNC redo transport. Maximum availability needs a standby that receives redo in SYNC or FASTSYNC mode and has standby redo logs:

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
DGMGRL> SHOW CONFIGURATION;
Enter fullscreen mode Exit fullscreen mode

Three rules from the guide turn up in questions. You cannot go straight from maximum performance to maximum protection; you must pass through maximum availability first. Changing the protection mode does not need a restart of the primary. And the broker rejects the SYNC setting on a database that has no standby redo log files.

Setting SYNC on North_Sales as well is not decoration. The property describes how a database receives redo while it is a standby, so the current primary needs the right value for the day the roles swap. The next step shows what happens when it is missing.

What does VALIDATE DATABASE tell you before a switchover?

Run it against the target before every role change, and only then switch:

DGMGRL> VALIDATE DATABASE 'South_Sales';
DGMGRL> SWITCHOVER TO 'South_Sales';
DGMGRL> SHOW CONFIGURATION;
Enter fullscreen mode Exit fullscreen mode

In the DGMGRL scenarios chapter of the broker guide, Oracle shows VALIDATE DATABASE answering "Ready for Switchover: No" for a physical standby in maximum availability mode. The reason is printed right above it: no other standby could support the protection mode, because North_Sales still has LogXptMode set to ASYNC. That is exactly the case the previous step avoids.

When validation passes, SWITCHOVER shuts down and restarts the old primary on its own, which only works if the broker can reach both instances through their static connect identifiers. Add VERBOSE to see every item that was checked, or a STRICT clause such as STRICT ALL to add checks for Flashback Database, force logging, offline data files and cleared log files.

How do you set up fast-start failover and the observer?

Fast-start failover lets an observer process fail over to a target standby without a person typing the command. Oracle's order is: Flashback Database on each database, SYNC transport in maximum availability, a target, an observer, and only then the enable command. Flashback first, in SQL*Plus:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;
ALTER DATABASE ARCHIVELOG;
ALTER SYSTEM SET db_recovery_file_dest_size=<size>;
ALTER SYSTEM SET db_recovery_file_dest=<directory-specification>;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;
Enter fullscreen mode Exit fullscreen mode

Then the broker side:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
DGMGRL> START OBSERVER observer1 IN BACKGROUND
> FILE IS /net/sales/dat/oracle/broker/fsfo.dat
> LOGFILE IS /net/sales/dat/oracle/broker/observer.log
> CONNECT IDENTIFIER IS North_Sales
DGMGRL> ENABLE FAST_START FAILOVER;
DGMGRL> SHOW FAST_START FAILOVER;
DGMGRL> VALIDATE FAST_START FAILOVER;
Enter fullscreen mode Exit fullscreen mode

Points the guide makes about this step:

  • Enabling fast-start failover does not start a failover. It allows the observer to start one when conditions call for it.
  • You can run up to three observers. Once fast-start failover is enabled, one is the master and the others are backups, and only the master coordinates a failover.
  • The failover starts when both the observer and the target standby lose the primary for FastStartFailoverThreshold seconds. The default is 30 and the lowest value is 6, and you can change it while fast-start failover is enabled.
  • With two or more standbys, set FastStartFailoverTarget on the primary. The broker sets the matching value on the target for you.
  • VALIDATE FAST_START FAILOVER reports problems such as an observer that is not started or Flashback Database that is off.

What happens to the old primary after a failover?

A manual failover runs while DGMGRL is connected to the standby that will take over:

DGMGRL> CONNECT sysdg@South_Sales.example.com;
DGMGRL> FAILOVER TO 'South_Sales';
DGMGRL> SHOW CONFIGURATION;
Enter fullscreen mode Exit fullscreen mode

Afterwards the old primary is disabled with ORA-16661 ("the standby database needs to be reinstated"), and the new primary carries the warning ORA-16629 until a standby protects it again. Oracle recommends this default, complete failover; an immediate failover is for the cases where a complete one fails, and it usually loses some data.

Reinstatement is the reason Flashback Database mattered. Start the old primary to the mounted state, connect DGMGRL to the new primary, and run:

DGMGRL> REINSTATE DATABASE 'North_Sales';
DGMGRL> SHOW CONFIGURATION;
Enter fullscreen mode Exit fullscreen mode

The old primary returns as the same type of standby as the database you failed over to, so a failover to a physical standby gives you back a physical standby. If it cannot be reinstated, it has to be re-created as a standby of the new primary. The switchover and failover chapter lists which bystander standbys get disabled in each case.

How do you get a writable test copy without losing the standby?

Convert the standby to a snapshot standby, test against it, and convert it back:

DGMGRL> CONVERT DATABASE 'South_Sales' TO SNAPSHOT STANDBY;
DGMGRL> CONVERT DATABASE 'South_Sales' TO PHYSICAL STANDBY;
Enter fullscreen mode Exit fullscreen mode

While it is a snapshot standby, the database keeps receiving redo but does not apply it. The conversion creates a guaranteed restore point, so a fast recovery area is required. Converting back throws away every change made during the test and then applies the redo that piled up.

Finish the session by saving the broker metadata, one of the 19c additions:

DGMGRL> EXPORT CONFIGURATION TO 'myconfig.txt';
Enter fullscreen mode Exit fullscreen mode

IMPORT CONFIGURATION FROM reads that file back if you ever need to rebuild the configuration.

Which exam topics does this session cover, and which does it leave out?

Step Main commands Topic group on Oracle's page
Create and enable CREATE CONFIGURATION, ADD DATABASE, ENABLE CONFIGURATION Creating a Data Guard Broker Configuration
Check the setup VALIDATE NETWORK CONFIGURATION, VALIDATE STATIC CONNECT IDENTIFIER, VALIDATE DATABASE SPFILE Monitoring a Data Guard Broker Configuration
Raise protection EDIT DATABASE SET PROPERTY LogXptMode, EDIT CONFIGURATION SET PROTECTION MODE Configuring Data Protection Modes
Switch over VALIDATE DATABASE, SWITCHOVER Performing Role Transitions
Prepare reinstatement ALTER DATABASE FLASHBACK ON Using Flashback Database in a Data Guard Configuration
Automate failover START OBSERVER, ENABLE FAST_START FAILOVER, REINSTATE DATABASE Enabling Fast-Start Failover
Test on a copy CONVERT DATABASE Creating and Managing a Snapshot Standby Database

Those seven groups hold 23 of the 63 objective lines on the exam page. The other 12 groups need a different kind of practice: creating the standby with RMAN or DBCA, real-time query on Active Data Guard, logical standby and SQL Apply, Oracle Net setup, RMAN backups taken from a standby, patching and rolling upgrades, tuning, far sync and real-time cascading, and client failover with Application Continuity. Oracle's Data Guard Concepts and Administration guide for 19c covers most of them.

Nine-step DGMGRL session for 1Z0-076, from connect to export, each step tagged with its topic group

How can you check yourself once the lab runs cleanly?

Try to answer questions about the session without the terminal in front of you. DBExam keeps a page of free 1Z0-076 sample questions with answers that you can work through first.

When you want a timed run, the 1Z0-076 online practice exam keeps the real exam's question format, time limit and passing score.

The DBExam YouTube channel has no Data Guard video yet. The closest is a two-minute set of preparation tips for an Oracle database certification; its examples come from the Autonomous Database exam 1Z0-931-23, not from 1Z0-076.

FAQs

1. How many questions are on the 1Z0-076 exam, and what score do you need?

Oracle's exam page lists 74 multiple-choice questions, a 120-minute limit and a passing score of 61%. The exam is taken proctored online, and the result appears on screen when you finish.

2. Does passing 1Z0-076 alone give you the Data Guard Administrator credential?

No. Oracle lists two steps for Oracle Certified Professional, Oracle Database 19c: Data Guard Administrator. First you hold Oracle Database Administration 2019 Certified Professional, or one of three retired credentials (Oracle Database 12c Administrator Certified Professional, Oracle Certified Expert, Oracle Database 12c: Data Guard Administrator, or Oracle Database 11g Administrator Certified Professional). Then you pass 1Z0-076.

3. Which DGMGRL VALIDATE commands count as new?

Oracle's broker guide lists VALIDATE DATABASE SPFILE, VALIDATE NETWORK CONFIGURATION and VALIDATE STATIC CONNECT IDENTIFIER as new commands in release 18c. The 19c guide also documents VALIDATE DATABASE with a STRICT clause, VALIDATE DATABASE DATAFILE for lost writes, and VALIDATE FAST_START FAILOVER.

4. Can you change a configuration straight from maximum performance to maximum protection?

No. The broker guide says you must change to maximum availability first and then to maximum protection. The primary database does not need a restart for a protection mode change.

5. Does ENABLE FAST_START FAILOVER fail the database over right away?

No. Enabling it only allows the observer to start a failover when conditions call for one, such as the observer and the target standby both losing the primary for longer than FastStartFailoverThreshold, which defaults to 30 seconds.

Written by the team behind DBExam.

Top comments (0)