...
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 DEFAULT_STDBY_TEMP_LOC 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 DEFAULT_STDBY_REDO_LOC 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 fileFORCE_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
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%T_%N.dbf dbf Name pattern to use when creating non OMF standby temp files, %N is counter starting from 1, %T is tablespace name
DEFAULT 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 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:
> dbv_functions -Q dbvlx102
...