On this page we’ll list necessary prerequisites and checks you should perform before creating standby database for your primary to ensure whole process will go smoothly.

You will find some prerequisites listed here also directly on the page https://dbvisit.atlassian.net/wiki/spaces/DSMP/pages/3289350145/Create+DR+Database+for+Oracle. This duplicity is intentional as not everybody reads prerequisites.

1. Oracle Home Check

Standby (DR) Oracle Home and Primary Oracle Home must be on identical patch level. To identify the patch level, you can run:

Note that you need to have exactly same patches installed on primary and standby, not only matching release.

2. Prepare Filesystem Space

In general, you will need to have free space on primary equal to the size of the primary database. This space will be used by RMAN full backup which Dbvisit uses for standby database creation. On standby server you need to have free space equal to 2x size of your primary database (1= space for database, 1=space for backup).

SQL for size of your primary database:

On primary and standby server, you can pre-create directories which you will use for storing the backup during standby database creation. For example:

3. Server Time Check

Oracle Database time is derived from OS session time which starts up the database. Dbvisit uses Database time for calculating various variables including standby database time lag. You need to ensure that your primary and standby servers have same time and same timezone. On both serves run:

The different time is indication that OS time synchronization daemons (chronyd, ntpd) are not working properly or are not configured. The time difference (or timezone difference) will then cause confusing gap time report of standby database in the GUI dashboard.

4. Check Primary Database

You need to verify following on the primary database:

4.1 Database is in archivelog mode

4.2 Database uses spfile:

If you don’t get file path, then your database uses pfile only and you need to create & start your primary database with spfile.

4.3 Database is in force logging mode:

Dbvisit can’t keep your standby database effectively in sync without force logging enabled. In case result of the select is “NO”, you will need to enable the force logging mode by running:

4.4 Database redo logs should use 512 byte sectors only:

4.5 Database redo logs size

The redo on your primary DB should be at least of 200MB in size (each member):

Note that 200MB is the bare minimum. Usually we would recommend to have even bigger redologs, because too frequent redo log switches will cause your standby database to get out of sync. You should aim for archivelog switch to happen at most every 5 minutes (approx. 300 archlogs per day) in your “business as usual” situation, before you create any standby database.

You can use following select to determine archivelog count generated per day for past 7 days:

If your archivelog generation is higher than required, you should increase size of your redo appropriately, otherwise the synchronization might experience delays.

5. 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:

5.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.

5.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:

5.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 “5.1 Using Exclusively OMF Naming Structure” apply:

6. Cleanup Standby Server

Before creating standby database, you must ensure that the standby server doesn’t contain any old database files. This step doesn’t apply for first-time standby database setup.

• If standby server contains existing running database which you want to replace with new standby, you can use following command for cleanup:

As the command is very destructive, make sure to double check that you’re on correct server and ORACLE_SID is set properly.

• If there are old database files on standby server, but database can’t be started, you will have to cleanup all locations manually

7. Verify Standby Server Memory Limits

Dbvisit doesn’t configure in any way memory limits on your standby server but we need those to be correctly set before you will start standby database creation. The easiest way to verify if the memory limits are set correctly, is to startup a dummy instance on standby server.

• check your current memory allocation on primary:

• on standby server create pfile for the dummy instance:

• attempt to start the instance:

• if you see any issues or errors, you need to refer to dummy instance alert log, for example:

8. Check your backup scripts on Primary database

You must ensure that no archivelog on your primary database will be deleted before Dbvisit is able to send it to the standby server.

Very often RMAN backup scripts on production are set to backup archivelogs and delete all archivelogs immediately after backup:

Such archivelog backup & retention strategy won’t be compatible with Dbvisit. Archivelog might be deleted by RMAN backups before it is shipped to standby causing the synchronization to break.

Dbvisit requires retention of at least 1-2 hours worth of archivelogs (recommendation would be 1 day if your disk space is available).

This can be achiveved for example by following commands:

this will delete all archivelogs from primary older than 1 day.