Recreate Standby Database Controlfile

Under curtain circumstances a standby control file may be recreated:

1. Automatically by Dbvisit Standby during:

During Create Standby Database (CSD) process
During the Re-Synchronize of a Standby Database

2. Manually by running dbv_functions –Q

With Dbvisit Standby version 6.0.26 and later, the functionality of recreating the standby control file has been improved and extended to handle scenarios when the primary and standby have different type of storage (ASM and filesystem), use different types of database files (OMF and non OMF) and contain different numbers of redo log groups and/or members, or different number of temp files.

Recreating of a standby control file includes the following major steps:

1. Create a standby control file on the primary database and ship it to the standby server

2. Backup current standby control file. This backup can be used to restore (using rman) an old standby control file should recreating of a new one fails.

3. Shut down the standby database and start no mount

4. Restore the new standby control file

5. Mount the standby database

6. Rename the standby data files (optional – if full names of standby data files differ from primary ones)

7. Create any new data files that have been created on the primary but do not exist on the standby (optional)

8. Rename standby temp files (optional – if full names of standby temp files differ from primary ones)

9. Rename standby redo logs (optional – if full names of standby redo logs differ from primary ones)

Considerations related to renaming redo logs and temp files once a standby control file has been recreated

The logic of renaming standby temp files and redo logs can be quite complex, especially for non standard database configurations.

The following settings are taken into account by Dbvisit Standby when renaming the standby database files:

DEFAULT_STDBY_TEMP_LOC
Default location to create standby temp files when none of locations recorded in either old or new control file, are valid. If null then set to location of the first standby system file

DEFAULT_STDBY_REDO_LOC
Default location to create standby redo files when none of locations recorded in either old or new control file, are valid. If null then set to location of the first standby system file

DEFAULT_STDBY_TEMP_NAME = '%T_%N.dbf
Name pattern to use when creating non OMF standby temp files, %N is counter starting from 1, %T is tablespace name

DEFAULT_STDBY_REDO_NAME = 'redo_%G_%N.log';
Name pattern to use when creating non OMF redo logs , %N is counter starting from 1, %G is group number

The user should avoid adding the above settings to the Dbvisit Configuration file unless advised by Dbvisit support

Dbvisit applies the following logic to determine the locations of redo logs in the standby database (keep in mind redo logs are not created on the standby only referenced in the standby control file):

Location specified by DEFAULT_STDBY_REDO_LOC is used if set to a non null value, otherwise
If creation of OMF logs is enabled, then all valid and existing OMF files locations are used, otherwise
If any of old redo locations (specified in the standby control file before it has been replaced) match the database storage type (ASM on non ASM) and exist, then these locations will be used. If old redo locations for some but not all redo groups are valid, these locations are used for all groups, otherwise
Location of the first SYSTEM datafile is used

Dbvisit applies the following logic to determine the type and name for redo logs in the standby database:

if the standby database is ASM, redo logs are specified as +DG, where DG is an ASM disk group name. Should the standby is activated, OMF redo logs will be created under the specified ASM disk group
If the standby is not ASM, and creation of OMF redo logs is enabled, then redo logs with OMF names do not get renamed. This may result in the standby control file referencing ASM redo logs, however should the standby is activated, filesystem OMF redo logs will be created under valid OMF locations
If the standby is not ASM, and creation of OMF redo logs is not enabled, or redo logs have non OMF names in the new control file, then redo logs are renamed using the pattern specified by DEFAULT_STDBY_REDO_NAME

Dbvisit applies the following logic to determine the locations of temp files in the standby database (keep in mind temp files are not created on the standby only referenced in the standby control file):

Location specified by DEFAULT_STDBY_TEMP_LOC is used if set to a non null value, otherwise
If creation of OMF data and temp files is enabled and exists, then this location is used, otherwise
If any of old temp file locations (specified in the standby control file before it has been replaced) match the database storage type (ASM on non ASM) and exist, then these locations will be used, otherwise
Location of the first SYSTEM datafile is used

Dbvisit applies the following logic to determine the type and name for temp files in the standby database:

if the standby database is ASM, temp files are specified as +DG, where DG is an ASM disk group name. Should the standby is activated, OMF temp files will be created under the specified ASM disk group
If the standby is not ASM, and creation of OMF data and temp files is enabled, then temp files with OMF names do not get renamed. This may result in the standby control file referencing ASM temp files, however should the standby is activated, filesystem OMF temp files will be created under a valid OMF location
If the standby is not ASM, and creation of OMF temp files is not enabled, or temp files have non OMF names in the new control file, then temp filess are renamed using the pattern specified by DEFAULT_STDBY_TEMP_NAME

Dbvisit Standby implements a locking mechanism when recreating a standby control file: once an old control file is backed up, a lock file dbv_stdby_ctl_DDC.lck (where DDC is the name of the Dbvisit Database Configuration) is created under location specified by LOGDIR. The lock file contains instructions how to restore the old standby control file should the recreating procedure fails. On successful completion of replacing a control file, the lock file gets deleted automatically. The locking mechanism is introduced to prevent Dbvisit Standby from continuing running on the standby, if the standby control file has not been successfully replaced after adding new data files, to notify the user about the problem that needs to be resolved manually.

Here is a sample output of a successful dbv_functions –Q run:

oracle@dbvlin505[/usr/dbvisit/standby]: ./dbv_functions -Q testdb
Dbvisit Database configuration (DDC) file dbv_testdb.env.
=>Replace current standby controfiles on dbvlin506 with new standby
controlfile? <Yes/No> [No]: Yes
Creating standby controlfile as '/usr/dbvisit/standby/tmp/13465_testdb_ctl.dbv'...
 > Transferring '13465_testdb_ctl.dbv' to server dbvlin506:7890
 Progress: 0%...20%...40%...60%...80%...100% [11834 KB/s] - done.
Replacing standby controlfile...
----------------------------
Dbvisit Database configuration (DDC) file dbv_testdb.env.
Starting Standby Database testdb...
Standby Database testdb started nomount.
Controlfile backed up as /usr/dbvisit/standby/tmp/standby_testdb_201306281321.ctl.

===>Should recreating of control file fails, see file /usr/dbvisit/standby/log/dbv_stdby_ctl_testdb.lck on dbvlin506 for steps to resolve.
Starting Standby Database testdb...
Standby Database testdb started nomount.
STANDBY controlfile(s) restored from /usr/dbvisit/standby/tmp/13465_testdb_ctl.dbv.
Starting Standby Database testdb...
Standby Database testdb started .
OK
----------------------------
Standby controfiles on dbvlin506 replaced.
To complete please run Dbvisit on the primary node(s), then on the standby.
oracle@dbvlin505[/usr/dbvisit/standby]: