Oracle Data Guard Standby Database Startup Commands

calendar Oct 23, 2025 / · 6 min read · Oracle Data Guard Standby Database Database Recovery High Availability Backup DBA SQL Commands  ·
Share on: linkedin copy

Oracle Data Guard Standby Database Startup Commands

Oracle Data Guard standby database startup commands enable database administrators to initialize and maintain physical standby databases that provide disaster recovery and high availability for production systems. These three essential commands work together to bring a standby database online and synchronize it with the primary database through automated redo log application.

Purpose

The Oracle Data Guard startup sequence serves to establish and maintain a synchronized replica of the primary database at a remote location. These commands initialize the standby instance, mount the standby database, and activate the Managed Recovery Process (MRP) to continuously apply redo data from the primary database. This configuration enables organizations to protect against data loss, minimize downtime during disasters, and offload read-only workloads from production systems.

SQL Code

1startup nomount
2alter database mount standby database;
3alter database recover managed standby database disconnect;

Breakdown of Commands

Command 1: STARTUP NOMOUNT

1startup nomount

The STARTUP NOMOUNT command starts the Oracle instance without mounting or opening the database. When executed on a standby server, Oracle performs several critical initialization steps: it reads the parameter file (init.ora or spfile), allocates the System Global Area (SGA) in memory based on initialization parameters, starts essential background processes including SMON, PMON, and LGWR, and opens alert log and trace files for monitoring. At this stage, the database is not yet associated with the instance, which is required for certain maintenance operations including creating control files and preparing standby databases for mounting.

Command 2: ALTER DATABASE MOUNT STANDBY DATABASE

1alter database mount standby database;

This command mounts the physical standby database and associates it with the instance that was started in the previous step. When the mount operation completes, the standby instance reads the control file, identifies the database structure including datafiles and redo logs, and prepares to receive redo data from the primary database. The keywords "STANDBY DATABASE" are technically optional because Oracle automatically determines whether the database is primary or standby, but including them makes the intent explicit for documentation and automation scripts.

Command 3: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT

1alter database recover managed standby database disconnect;

The final command starts the Managed Recovery Process in background mode to continuously apply redo logs from the primary database. The DISCONNECT keyword is crucial because it starts the MRP as a background process and immediately returns control to the user session, allowing administrators to continue working while recovery runs automatically. Without the DISCONNECT option, the recovery would run in foreground mode and the SQL session would remain locked until manually stopped. The MRP monitors for new archived redo logs from the primary database and applies them automatically to keep the standby database synchronized.

Key Points

Instance Initialization: The NOMOUNT stage is mandatory for standby databases because it allows Oracle to start the instance using the standby-specific parameter file before attempting to access the database files.

Automatic Synchronization: Once the managed recovery process starts, the standby database automatically receives and applies redo logs from the primary database without requiring manual intervention.

Background Processing: Using the DISCONNECT keyword ensures the recovery process runs in the background, freeing the database session for other administrative tasks.

File Management: Setting the parameter STANDBY_FILE_MANAGEMENT to AUTO allows the standby database to automatically create new datafiles when they are added to the primary database.

Startup Sequence: These three commands must be executed in the exact order shown because each step depends on the successful completion of the previous one.

Insights and Best Practices

The startup sequence for physical standby databases differs fundamentally from primary database startup because standby databases must remain in a special recovery mode to receive and apply redo data continuously. Administrators should always start the primary database and enable log shipping before starting the standby database to ensure proper synchronization from the beginning. Monitoring the standby database status using queries against V$DATABASE and V$ARCHIVE_DEST_STATUS views helps verify that the MRP is running and redo logs are being applied successfully.

For environments using Oracle 19c or later with Active Data Guard, administrators can open the standby database in read-only mode while keeping the managed recovery process active, enabling reporting queries to run against current data without impacting the primary database. This capability transforms standby databases from idle disaster recovery resources into productive assets that provide return on investment through query offloading.

When troubleshooting startup issues, check the alert log for the standby database to identify problems with network connectivity, missing archived logs, or configuration parameter errors. Common issues include incorrect service names in the log_archive_dest parameters, missing or mismatched passwords in password files, and firewall rules blocking listener connections between primary and standby sites.

When to Use These Commands

Database administrators execute this startup sequence when initially configuring a physical standby database, after performing planned maintenance that required shutting down the standby, following server restarts or power outages, and when recovering from network interruptions that disconnected the standby from the primary. The commands are also used during Data Guard broker configuration and when testing disaster recovery procedures to ensure failover capabilities work correctly.

Common Variations

For delayed standby configurations that intentionally lag behind the primary by a specified time period, administrators add the DELAY parameter: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 60 DISCONNECT to delay application by 60 minutes. When using the Data Guard Broker for centralized management, the equivalent operation is performed through DGMGRL commands: DGMGRL> edit database standby_db set state='APPLY-ON'. For standby databases in Oracle Real Application Clusters (RAC) environments, administrators use SRVCTL commands to register and start the database across all cluster nodes.

References

Posts in this series