Parameter file for Oracle Standby Database

When building a physical standby database in Oracle Database using Oracle Data Guard, the initialization parameter file (initSTBYDB.ora) defines how the standby database identifies itself and communicates with the primary database.
Each parameter orchestrates redo transport, recovery, and file management.

Below is a clear explanation of each parameter in your configuration.


1. DB_NAME=PRIMDB

Purpose

This parameter defines the database name shared by both primary and standby databases.

Important rule

  • The DB_NAME must be identical on both primary and standby databases.
  • It represents the same database identity in the Data Guard configuration.

Example

Primary database:

DB_NAME=PRIMDB

Standby database:

DB_NAME=PRIMDB

Reason

Data Guard treats the standby database as a transactionally synchronized copy of the primary database. Therefore, the base database name must remain the same.


2. DB_UNIQUE_NAME=STBYDB

Purpose

This parameter provides a unique identifier for each database in the Data Guard configuration.

Important rule

  • Primary and standby must have different DB_UNIQUE_NAME values.

Example:

Primary

DB_UNIQUE_NAME=PRIMDB

Standby

DB_UNIQUE_NAME=STBYDB

Why it is required

Oracle uses this parameter to:

  • Distinguish databases in Data Guard
  • Control redo shipping destinations
  • Manage switchover and failover operations

Without unique names, redo transport configuration cannot function correctly.


3. CONTROL_FILES='/u01/oradata/control01.ctl'

Purpose

Defines the location of the control file(s) used by the standby database.

The control file stores critical metadata such as:

  • Database structure
  • Datafile locations
  • Archive log history
  • Checkpoints
  • Data Guard metadata

Best Practice

Multiple control files should be configured for redundancy.

Example:

CONTROL_FILES='/u01/oradata/control01.ctl','/u02/oradata/control02.ctl'

In standby setup

The control file is typically restored using:

RESTORE STANDBY CONTROLFILE

4. LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIMDB,STBYDB)'

Purpose

Defines the list of databases participating in the Data Guard configuration.

Example:

LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIMDB,STBYDB)'

This tells Oracle:

  • PRIMDB is part of the configuration
  • STBYDB is part of the configuration

Why this matters

Oracle uses this parameter to:

  • Validate redo transport
  • Prevent unauthorized redo shipping
  • Maintain Data Guard topology awareness

If a database name is not listed here, redo transport may fail.


5. LOG_ARCHIVE_DEST_1

LOG_ARCHIVE_DEST_1=
'LOCATION=/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=STBYDB'

Purpose

Defines the local archive log destination on the standby server.

Components

LOCATION=/arch

Archive logs will be stored locally in:

/arch

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

This defines when the destination is valid.

Meaning:

  • Works for online redo logs
  • Works for standby redo logs
  • Works when database role is primary or standby

DB_UNIQUE_NAME=STBYDB

Identifies the destination database.

This ensures redo generated on this database belongs to STBYDB.


6. LOG_ARCHIVE_DEST_2

LOG_ARCHIVE_DEST_2=
'SERVICE=PRIMDB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRIMDB'

Purpose

Defines the redo transport destination used to ship redo logs.

In this configuration, standby can ship logs back to primary after a role change.

Components

SERVICE=PRIMDB

Uses a TNS service defined in tnsnames.ora to connect to the primary database.

Example:

PRIMDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST=primary_host)(PORT=1521))
(CONNECT_DATA =
(SERVICE_NAME=PRIMDB)
)
)

ASYNC

Defines redo transport mode.

Meaning:

  • Redo is shipped asynchronously
  • Primary database does not wait for standby acknowledgment

This provides better performance but slightly higher risk of data loss during disasters.

Other option:

SYNC

Used in Maximum Availability / Maximum Protection modes.


VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

Meaning:

This destination is active only when:

  • Database role = Primary
  • Redo source = Online redo logs

DB_UNIQUE_NAME=PRIMDB

Specifies the destination database identity.


7. FAL_SERVER=PRIMDB

Purpose

FAL stands for Fetch Archive Log.

This parameter tells the standby database:

Which server to contact when archive logs are missing.

Example scenario:

If standby detects a missing archive log:

Sequence 100 missing

Standby automatically requests it from:

PRIMDB

This enables automatic gap resolution.


8. FAL_CLIENT=STBYDB

Purpose

Defines the TNS name of the standby database itself.

This parameter allows the primary database to identify:

Who requested the missing archive log

Example:

FAL_SERVER = PRIMDB
FAL_CLIENT = STBYDB

So when standby requests a log:

Primary sends the archive log to STBYDB.


9. STANDBY_FILE_MANAGEMENT=AUTO

Purpose

Controls automatic datafile management on the standby database.

AUTO (Recommended)

When a datafile is added on primary:

ALTER TABLESPACE users ADD DATAFILE ...

Oracle automatically creates the corresponding file on the standby database.

No manual action required.


MANUAL

If set to MANUAL:

DBA must manually create the datafile on standby.

Example:

ALTER DATABASE CREATE DATAFILE ...

This increases operational overhead and risk.

Oracle DBA

Experienced OCM-certified Oracle Database Administrator with over 18 years of expertise in designing, implementing, and managing complex database solutions. My expertise spans performance optimization, security, and high-stakes solution implementation. Adept at managing complex environments with precision.

No Comments

    Leave a Message

    Your email address will not be published. All fields are mandatory. **