Under curtain circumstances a standby control file may be recreated:
1. Automatically by Dbvisit Standby, when it detects that new datafile(s) have been added to the primary 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)
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
FORCE_DEFAULT_STDBY_LOC = 'No'; If set to Y, ignore temp file and redo locations specified in the old control file and use the ones set by DEFAULT_STDBY_TEMP_LOC and DEFAULT_STDBY_REDO_LOC
If set to N, Dbvisit Standby will attempt to use old locations first to rename temp files and redo, if possible (default)
DEFAULT_STDBY_TEMP_NAME = 'temp%N.dbf Name pattern to use when creating non OMF standby temp files, %N is counter starting from 1
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 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:
> dbv_functions -Q dbvlx102
Dbvisit Database configuration (DDC) file dbv_dbvlx102.env.
=>Replace current standby controfiles on dbvisit32 with new standby
controlfile? <Yes/No> [No]: y
Creating standby controlfile controlfile...
Replacing standby controlfile...
----------------------------
Dbvisit Database configuration (DDC) file dbv_dbvlx102.env.
Starting Standby Database dbvlx102...
Standby Database dbvlx102 started nomount.
Controlfile backed up as /usr/tmp/standby_dbvlx102_201203301052.ctl.
===>Should recreating of control file fails, see file /oracle/orabase/admin/dbvlx102/dbvisit/dbv_stdby_ctl_dbvlx102.lck on dbvisit32 for steps to resolve.
Starting Standby Database dbvlx102...
Standby Database dbvlx102 started nomount.
STANDBY controlfile created.
Starting Standby Database dbvlx102...
Standby Database dbvlx102 started .
Standby file +DATA/dbvlx102/datafile/system.298.754676807 renamed to +DATA/dbvlx102/datafile/system.276.779280379 in database dbvlx102.
Standby file +DATA/dbvlx102/users.dbf renamed to +DATA/dbvlx102/datafile/users.274.779280585 in database dbvlx102.
Standby file +DATA/dbvlx102/datafile/sysaux.297.754676905 renamed to +DATA/dbvlx102/datafile/sysaux.260.779280473 in database dbvlx102.
Standby file +DATA/dbvlx102/datafile/undotbs1.287.754676863 renamed to +DATA/dbvlx102/datafile/undotbs1.266.779280433 in database dbvlx102.
Standby file +DATA/dbvlx102/datafile/users.290.754677031 renamed to +DATA/dbvlx102/datafile/users.273.779280601 in database dbvlx102.
alter database rename file '+ONLINELOGS/dbvlx102/onlinelog/redo_2_1' to '+ONLINELOGS';
alter database rename file '+ONLINELOGS/dbvlx102/onlinelog/redo_2_2' to '+ONLINELOGS';
alter database rename file '+ARCHIVELOGS/dbvlx102/onlinelog/group_3.450.779106171' to '+ARCHIVELOGS';
alter database rename file '+ARCHIVELOGS/dbvlx102/onlinelog/group_3.451.779106175' to '+ARCHIVELOGS';
alter database rename file '+DATA/dbvlx102/tempfile/temp1.307.775046681' to '+DATA';
alter database rename file '+DATA/dbvlx102/tempfile/temp01.dbf' to '+DATA';
----------------------------
Standby controfiles on dbvisit32 replaced.