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.
No Comments