Automated Standby Database with Oracle 26ai Data Guard

Distinguish three recovery mechanisms

FAST_START_MTTR_TARGET influences the target for single-instance crash recovery; it does not create a standby or enable automatic failover. It is not an upper bound on application downtime. Oracle describes the parameter's scope in the Oracle 26ai parameter reference. Keep checkpoint tuning separate from the standby deployment decision.

This separation matters during an incident. An instance crash with intact storage may be handled by restart and instance recovery. Loss of a site may require a standby role transition. A network outage requires a decision based on the configured failover policy and available evidence. Labeling every event “Fast-Start recovery” conceals the different prerequisites and consequences.

Plan the topology and acceptance criteria

Use example database unique names cdb1 and cdb1_stby. A physical standby shares the primary's DB_NAME but has its own DB_UNIQUE_NAME. Database role changes occur at CDB scope in this architecture. Oracle's physical standby creation guide describes the multitenant scope and primary preparation, including archiving and an appropriate logging mode.

Begin with a deployment worksheet. Record each host, database name, administrative service, storage location, software version, patch level, and owner. Check that the selected platform and release combination is supported. Include encryption keystore access when encrypted datafiles are involved. A datafile copy without its required keys is not an operational standby.

Choose the failure domain deliberately. A standby on the same host can support a laboratory exercise but does not protect against that host disappearing. A remote site must have enough compute, storage, and network capacity for the workload it will inherit. Test those assumptions rather than assuming that a smaller machine becomes sufficient because it usually performs only apply work.

Define the permitted data loss and the time allowed to restore application service. Specify how each will be measured. A role transition that finishes before the availability deadline can still fail the requirement if applications cannot connect or committed business results are missing. Give database and application teams a shared acceptance checklist.

Prepare logging, storage, and connectivity

Inspect the primary from the root container using a privileged session:

SHOW CON_NAME
SELECT name, db_unique_name, database_role,
       open_mode, log_mode, force_logging
FROM v$database;

For the conventional setup illustrated here, prepare ARCHIVELOG and FORCE LOGGING through the approved database procedure. If an archiving-mode change is necessary, schedule its required mount and restart work rather than treating shutdown as an unconditional first step. Size the recovery area from redo production, retention, backups, and planned outage duration; an arbitrary 10 GB or 20 GB value is not a capacity plan.

Inventory control files, datafiles, redo logs, recovery-area locations, and filesystem or ASM permissions on the auxiliary host. Document how primary file names map to standby storage. Do not copy an SPFILE and assume its primary control-file paths or archive destinations are suitable for another host. Review inherited settings before duplication can create files.

Administrative connections, redo transport connections, and application connections serve different purposes. Verify the administrative and transport paths between the participating hosts using actual database connections. A listener responding or a naming alias resolving does not by itself prove that the required privileged authentication works. Use approved credential handling without putting passwords in command files or lesson examples.

Configure redo transport and standby redo logs

Oracle's redo transport guide describes synchronous and asynchronous transport. Asynchronous transport allows primary commits without waiting for the remote destination; synchronous transport ties the commit path to the configured acknowledgement. Protection mode and transport policy must be chosen together. An asynchronous configuration should not be described as a guaranteed zero-data-loss solution.

Provide standby redo logs on both sites so either can receive redo after role reversal. The current 26ai guide specifies at least as many standby log groups as source online groups for each thread, with each file at least as large as the largest source online redo file. Additional groups may be part of the reviewed design. Inspect the actual threads, counts, and sizes:

SELECT thread#, group#, bytes FROM v$log;
SELECT thread#, group#, bytes FROM v$standby_log;

Record the design before adding groups. A single-instance example must not silently become a RAC recipe that omits other threads. After creation, check the resulting inventory rather than assuming every statement produced the intended files. Include this check in the role-reversal review so the current primary is not left unable to receive redo later.

Create the physical standby with RMAN

Choose active duplication when copying from the running source over the network is appropriate, or backup-based duplication when the required backups and redo are available to the standby host. Prepare the auxiliary instance in NOMOUNT, its authentication and listener connectivity, and its file-name strategy first. The RMAN duplication guide covers these prerequisites and warns that bypassing file-name checks on a local host can overwrite source files.

After establishing the target connection to the primary and auxiliary connection to the prepared standby, the central RMAN command is:

DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER;

This is a command template, not a complete host-independent deployment script. File destinations, channels, initialization settings, and connection details must already fit the selected environment. The example intentionally does not bypass file-name checks. Treat the network and storage plan as prerequisites rather than trying to infer them from a short duplication command.

The RMAN standby creation documentation explains that FOR STANDBY creates a standby rather than an independent database with a new DBID. DORECOVER performs initial media recovery but leaves the standby mounted without starting ongoing managed recovery. Therefore, successful duplication still needs transport and continuous apply configuration.

Keep the RMAN log as evidence. Verify the resulting standby's identity and role, file locations, and recoverability before proceeding. If duplication fails, diagnose the recorded error and validate the remaining auxiliary state. Do not repeatedly retry against unreviewed directories; a cleanly documented retry is easier to assess than several partial attempts.

Register the existing databases with broker

Broker registration manages databases that already exist. It does not replace the duplication step. Enable broker startup in the appropriate root context on each database. For a prepared SPFILE-based setup, the illustrative SQL is:

ALTER SYSTEM SET DG_BROKER_START=TRUE
  SCOPE=BOTH SID='*';

The DG_BROKER_START reference documents the parameter as instance-level and not modifiable within a PDB. Adapt persistence to the actual initialization-file arrangement. In RAC, verify the shared broker configuration-file arrangement as part of the installation design.

Connect DGMGRL to the primary through the approved administrative connection. The names below illustrate a new two-database configuration. The connection identifiers must resolve correctly from all participating databases:

CREATE CONFIGURATION 'CDB1_DR' AS
  PRIMARY DATABASE IS 'cdb1'
  CONNECT IDENTIFIER IS cdb1;

ADD DATABASE 'cdb1_stby' AS
  CONNECT IDENTIFIER IS cdb1_stby;

ENABLE CONFIGURATION;

Check the CREATE CONFIGURATION and ADD DATABASE references for current syntax and connection requirements. Review existing remote transport destinations before creating a configuration; do not remove them blindly if another operational arrangement depends on them.

Once broker owns the configuration, use its supported properties and state changes for management. Avoid a second automation process continuously rewriting the same redo destinations through manual SQL. Define ownership in the runbook so an operator can determine which interface is authoritative when settings appear inconsistent.

Start apply and validate the configuration

Broker distinguishes primary transport from standby apply. Request and inspect the standby apply state using DGMGRL:

EDIT DATABASE 'cdb1_stby' SET STATE='APPLY-ON';
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE 'cdb1_stby';
VALIDATE DATABASE VERBOSE 'cdb1_stby';

Oracle documents APPLY-ON in its broker member states guide. A mounted physical standby can apply redo. Opening it for query while apply remains active is a separate Active Data Guard capability; do not assume this lesson's setup includes the necessary entitlement.

VALIDATE DATABASE reports checks and detected errors or warnings. Review the output rather than using the command's completion as a health certificate. Record any unresolved item, its operational effect, and who will address it. Database validation should be followed by the planned application-level tests.

Monitor lag and the freshness of the evidence

On the standby, inspect transport and apply metrics with their timestamps:

SELECT name, value, unit, time_computed, datum_time
FROM v$dataguard_stats
WHERE name IN ('transport lag', 'apply lag', 'apply finish time');

V$DATAGUARD_STATS returns no rows on a primary. Its DATUM_TIME identifies when the source data used for the metric was received. An unchanged timestamp across samples can indicate that source data is not arriving. A small lag value from stale information is not evidence of a healthy current connection.

For a compact primary-side transport check, inspect destination errors:

SELECT dest_id, status, error
FROM v$archive_dest
WHERE status <> 'INACTIVE';

Correlate results with broker status and the database logs. Lag is not permanently one or two archived logs; use measured time and workload context. Capture observations during normal traffic and the largest expected batch. A quiet-period screenshot cannot establish that apply capacity is sufficient during sustained peak redo generation.

Plan role transitions and optional automatic failover

Switchover is a planned reversal of roles; failover responds to loss of the primary. Oracle describes the distinction in its broker role-transition guide. A role-changing activation command is not a routine health check. Practice transitions in a controlled environment with a return-to-service and old-primary recovery plan.

Fast-Start Failover adds an observer and an eligible target under the broker policy. The observer should have an independent placement and reliable connectivity to the relevant databases. Review target selection, protection mode, transport settings, thresholds, and any permitted data loss before enabling automatic action. Flashback planning and sufficient retained history support reinstatement of the former primary where the documented conditions permit it.

The Fast-Start Failover guide describes observe-only mode for evaluating decisions without automatic role transitions. After completing its prerequisites, an illustrative DGMGRL evaluation is:

ENABLE FAST_START FAILOVER OBSERVE ONLY;
SHOW FAST_START FAILOVER;

Start the observer from its own authenticated DGMGRL session on the planned observer host:

START OBSERVER;

The foreground observer occupies that session while it runs. Use a separate administrative session for subsequent inspection commands.

Observe-only mode does not provide automatic failover protection. A production decision to enable actual failover is a separate controlled step. Starting an observer also requires its approved authentication and operational supervision. Retain observer and broker logs so an evaluation can explain which conditions would have led to a transition.

Test the application and maintain the standby

Define services that follow the intended database role and test application reconnection through the normal client path. Database availability, listener availability, and an application transaction completing are separate observations. Check dependent systems such as authentication, external files, jobs, and downstream messaging so the alternate site can support the entire service.

1. Validate steady state. Confirm transport, apply, fresh metrics, and documented warning resolution.
2. Exercise role reversal. Verify client routing, workload behavior, and the new standby's ability to receive and apply redo.
3. Measure recovery. Record decision time, role-transition time, client reconnection, and a verified business operation.
4. Restore the intended topology. Confirm both databases are protected again and preserve the test evidence.

A useful acceptance test identifies a known committed transaction before the transition and checks its expected result afterward. Separate that result from work that was still in flight. Document what clients should retry and how the application prevents duplicate business actions. A successful database connection alone does not answer these transactional questions.

Keep independent backups and restoration tests alongside replication. A standby is another operational copy, not a substitute for retaining recovery points. Monitor recovery-area capacity, redo generation, apply throughput, and changes in infrastructure. After adding datafiles, changing services, or adjusting software, verify that both roles still satisfy the documented deployment assumptions.

Finally, maintain a short operational handover: current topology, transport policy, apply status, failover mode, observer owner, service routing, and latest successful test. Mark configuration completion separately from automatic-failover readiness. This gives the next administrator concrete evidence of what is working and what still needs validation.

The next lesson examines read-only database use, including how reporting requirements interact with standby apply. For further reading: Oracle Backup Recovery.