Before creating standby database it is important to consider placement of standby database files on standby server.

1. Check Primary Database Files Naming Structure

For creating standby database, It’s not important whether primary database files are stored on ASM, ACFS, Filesystem or NFS, because Dbvisit does support all storage methods certified by Oracle. What matters is the naming structure on your primary database - whether it’s OMF (Oracle Managed Files) or whether you use non-OMF (user custom naming). There are several database files for which we need to perform this check:

• Controlfiles

• Redo log files

• Datafiles

• Tempfiles

You can use following select for your convenience to determine your File Name structure:

1.1 Using Exclusively OMF Naming Structure

If the previous SQL returned only “OMF” values in Result column for all lines, you’re using OMF naming structure only.

Using OMF (Oracle Managed Files) naming means that all of your database files are fully managed by Oracle database itself. The files have automatically generated identifier in their name, for example:

• Controlfiles (format o1_mf_%u.ctl)

• Redo logs (format o1_mf_%g_%u.log), %g = group#:

• Datafiles (format o1_mf_%t_%u.dbf), %t = tablespace name:

• Tempfiles (format o1_mf_%t_%u.dbf), %t = temporary tablespace name:

The file names are slightly different for ASM, but they always contain the unique identifier.

Exclusive OMF naming structure is fully supported by Dbvisit Standby with following conditions:

Otherwise functionality of Dbvisit standby is very limited. If for example OMF datafiles are spread across more diskgroups, you will have to manually create your standby database and the only functionality available will be failover and archivelog synchronization.

1.2 Using Exclusively non-OMF Naming Structure

If the previous SQL returned only “NOT OMF” values in Result column for all lines, you’re using user defined naming structure. The file names contain “human readable” names, for example:

• Controlfiles:

• Redo logs:

• Datafiles:

• Tempfiles:

Exclusive non-OMF naming structure is fully supported by Dbvisit with following condition:

1.3 Using mix of OMF and non-OMF Naming Structure

If the previous SQL returned some “OMF” and some “NOT OMF” values (regardless for which file types) then you’re using mix of OMF and non-OMF files on your primary database.

Such configuration is not according to the best practices, but can be supported by Dbvisit. Typical example is mix of datafiles:

or mix between OMF datafiles and non-OMF redo log files:

For mix of OMF and non-OMF files, following restrictions apply:

• you must set OMF parameters db_create_file_dest and db_create_online_log_dest_[x] on primary and standby database. In case db_create_online_log_dest_[x] is not set on primary, db_create_file_dest and db_recovery_file_dest must be set.

• in case of switchover, all redo logs and tempfiles on new primary server (formerly standby) will be forcefully re-created as OMF

• datafile naming structure will remain the same even after switchover

• In addition same conditions as in “1.1 Using Exclusively OMF Naming Structure” apply:

2. Determine Standby Files Placement

The information listed below will dictate which parameters you will need to set when running the create standby database process and we will also clarify where the standby database will be created on standby server.

If you’re not using OMF files structure, of if you’re using OMF and non-OMF mix, we recommend to prepare standby file directories on standby server in advance.

2.1 OMF files

Location of OMF files on standby server is completely driven by OMF parameters db_create_file_dest , db_create_online_log_dest_[x] and db_recovery_file_dest. You may change it to place your files on different ASM diskgroup, different filesystem mountpoint etc … OMF parameters on primary and standby are needed even if you don’t make any type of name/path conversion.

OMF init parameters are:

If db_create_online_log_dest_[x] is not set, Oracle creates redo in db_create_file_dest and creates automatically mirror in db_recovery_file_dest

If you have identical filesystem structure on standby and on primary (no path conversion done):

• You will need to set OMF parameters when creating standby database to the same values as on your primary. This is done automatically during create standby database wizard, so you don’t have to worry about it further.

If you would like to have different file paths on primary and standby or if you’re converting between ASM and filesystem (path conversion is done):

• You will need to set OMF parameters when creating standby database to intended locations as described further

 Following rules will apply for different types of files when standby database is created:

2.1.1 Location of OMF datafiles and tempfiles on standby

They will be created on standby in location <db_create_file_dest>/<db_unique_name>/datafile. For example if you have OMF datafile on primary (primary db_unique_name=SOLO):

and your standby will be on filesystem with init parameters:

db_create_file_dest = /u01/app/oracle/oradata

db_unique_name=dev

then standby OMF file will be created like so:

2.1.2 Location of OMF redo logs on standby

They will be created on standby in location(s) <db_create_online_log_dest_[x]>/<db_unique_name>/onlinelog.

If parameters db_create_online_log_dest_[x] are not set, oracle will automatically create redo in <db_create_file_dest>/<db_unique_name>/onlinelog and its mirror in <db_recovery_file_dest>/<db_unique_name>/onlinelog.

For example if your primary has redo logs (only group 3 is displayed):

and your standby will be on filesystem with init parameters

db_create_file_dest = /u02/app/oracle/oradata

db_recovery_file_dest = /u02/app/oracle/fast_recovery_area

db_unique_name=dev

db_create_online_log_dest_[x] are not set

then standby OMF redo logs will be created like so (only group 3 is displayed):

2.1.3 Primary ASM to Standby filesystem conversion example with OMF files

Let’s have a look how primary ASM to Standby Filesystem conversion works for exclusively OMF primary database.

Primary database has following configuration:

During create standby database we would set OMF parameters like so:

Open

After standby database is created it will have following structure:

2.2 Non-OMF files

If you have identical filesystem structure on standby and on primary (no path conversion done):

There’s no need to set any specific parameters for standby database if your primary database uses non-OMF files and you have identical filesystem structure / paths on standby and on primary.

If you would like to have different file paths on primary and standby or if you’re converting between ASM and filesystem (path conversion is done):

You need to set the convert parameters for your standby database during standby database creation. There are two convert parameters to set:

The convert parameters have following properties:

• They contain pair or pairs of strings which are used for path conversion when standby database is created

• They are valid on standby database only. On primary, they are not effective.

• For Dbvisit to work properly, they need always set on primary and standby (their values are reversed)

2.2.1 Primary filesystem to Standby filesystem conversion example with non-OMF files

Primary database has following configuration:

On standby server we want to place all files on u02 instead of u01. So during the create standby database we would specify following parameters:

Open

After the standby database is created, files will have following configuration:

2.3 Mixing OMF and Non-OMF files

This configuration is very complex for standby database creation and placement of database files on standby.

If you have identical filesystem structure on standby and on primary (no path conversion done):

• You will need to set OMF parameters when creating standby database to the same values as on your primary (this is done automatically during create standby database wizard)

• There’s no need to set any specific parameters for non-OMF files

If you would like to have different file paths on primary and standby or if you’re converting between ASM and filesystem (path conversion is done):

• You will need to set OMF parameters when creating standby database to intended locations

• You will need to set db_file_name_convert and log_file_name_convert as well

2.3.1 Primary filesystem to Standby filesystem path conversion example with OMF and non-OMF mix:

Primary database has following configuration:

All files are OMF except of one datafile (nonomf.dbf) and one redo member (redo99.log).

On standby server we want to place all files on u01 instead of u02. So during the create standby database we need to specify following parameters:

We need to specify OMF parameters and convert parameters as well, becausew we’re using OMF and non-OMF file types and we want to have path conversion.