Dbvisit Standby can assist in creating the standby database. Dbvisit Standby supports the creation of standby databases even if ASM or OMF are used. If you are still using RAW devices, Dbvisit Standby version 10 can also support this.
Dbvisit Standby version 10 also supports the creation of an Oracle RAC enabled standby database. Since Oracle is discontinuing RAC for Standard edition from 19c, Dbvisit standby also support HA Clusterware for Oracle Standard Edition. There are a number of prerequisites before this can be performed. For example, the standby environment must already have the Clusterware (GI) installed and ASM storage configured, as well as have the Oracle Database software installed, this option will be discussed in more detail in this section.
Before getting into the more advanced configurations it is important to first make sure you understand the basics and then move onto the more advanced configurations.
Dbvisit Standby version 10 will guide you through the creation of the standby process, and by answering a few short questions you will be ready to start the process.
Creating a standby database can be done in three ways:
- Creating the standby database manually (this option will not be discussed in this guide - for more detail please see the Oracle Documentation)
- Creating the standby database using the Dbvisit Standby Core - Command Line Interface
- Creating the standby database using the Central Console - GUI
Please note that this guide will refer to the Create Standby Database process as the CSD process.
If using ASM based databases, we do not recommend the use of ASM aliases but to rather use Oracle Managed File naming.
If you do create a standby database where ASM is used and the primary database is making use of ASM aliases, the standby database will only end up with OMF datafiles and ASM aliases will not be created.
ASM Aliases can be created post CSD either using a post-processing script or by manually creating them.
For more detail see: Pre/Post Processing#Pre/PostProcessing-ASMAliases
As a prerequisite, you have to make sure that the Primary database uses SPFILE and not PFILE before running the Create Standby Database process.
If you are using ODA machines, It is required that you create the dbstorages before creating the standby databases using Dbvisit. Please refer the blog for further details.
2. Creating The Standby Database - Command Line
Creating the Standby Database is an easy process if you are familiar with your Database environment and have followed all the pre-requisites when installing the Dbvisit Standby software. Create a Standby Database via command line has to be started from the Primary server.
Please ensure you have adequate available space on the standby server to copy the RMAN backup and restore backup copy that this process does.
This section will focus on using the command line interface using the dbvctl command: ./dbvctl --csd
To quickly obtain the usage (syntax) of the CSD command run: "./dbvctl -h --csd"
When running the CSD process from the command line, you are not required to use the options listed in brackets  example:
[--mode CLI|BATCH|GUI] [--restart] [--noprompt] [-j json_file] [--dump_template]
These are optional parameters.
2.1. Creating Single Instance Standby (non-RAC)
In the following example we will create a standby database based on the following information:
- Primary Server Details:
- Server Name: dbv1
- DB_NAME: DEV
- DB_UNIQUE_NAME: DEV
- The database is in archivelog mode
- Database archive log destination is set to the default recovery area (FRA) - /u01/app/oracle/fast_recovery_area
- There is a local backup folder /u01/app/oracle/backup which has sufficient space to hold a full compressed backup of the primary DEV database (RMAN Backup)
- The database data files are located in /u01/app/oracle/oradata/DEV
- NON-OMF is used
- One controlfiles are located in /u01/app/oracle/oradata/DEV and the second one in the FRA - /u01/app/oracle/fast_recovery_area/DEV
- Standby Server Details:
- Server Name: dbv2
- The DB_NAME and DB_UNIQUE_NAME will be the same as the primary
- The same folder structure as the primary will be used
- The Oracle Database software is already installed on the standby server and match the same version and edition of the primary
- The standby server also has a /u01/app/oracle/backup folder with sufficient space for a full RMAN database backup
In this example, the ideal configuration is used. This means that the primary and standby database servers are an exact match with regards to storage and the directory structure.
In this case, it will not be required to set any additional parameters such as the db_file_name_convert or log_file_name_convert parameters.
We can now start the process by running the following command from the primary server: ./dbvctl -d DEV --csd
The example output below shows the detail steps followed:
Once the above process is complete, you should be able to send and apply logs which are shown below.
2.1.1. Sending Logs
Sending archive logs to the standby database can be done by running the following command: ./dbvctl -d <DDC>
2.1.2. Applying Logs
Applying archive logs on the standby database run the following command: ./dbvctl -d <DDC>
2.1.3. Running the log gap report
To ensure the primary and standby databases are up to date, you can run the Log Gap Report using the following command from the primary database server:./dbvctl -d <DDC> -i
2.2. Creating a filesystem-based Standby Database for ASM storage based primary
In this example, we will show you how to create the standby database when the primary database is a single instance database using ASM based storage and the standby database server will be using Filesystem based storage.
Please note that we do recommend a Primary and Standby storage match, meaning if a primary is using ASM, ideally the standby database server should as well and should have the same disk group layout. This is to ensure the primary and standby database servers match as much as possible.
If your primary database has both OMF and non-OMF datafiles, you might have to consider adding a few other parameters like below when editing the parameter values while running the CSD process. This has to be matched in the reverse order in primary as well to avoid issues during Graceful Switchover.
Mixing OMF and non-OMF datafiles should be avoided as it provides unnecessary complexity to the environment.
- On the primary Oracle Managed Files (OMF) is used and the diskgroup in use is +DATA (kiwi701 is the primary).
- On the standby database server, the database files will make use of /u01/app/oracle/oradata and /u01/app/oracle/fast_recovery_area as the datafile location and recovery area(kiwi703 is the standby).
You will notice in this example we have to modify the "db_create_file_dest" and the "db_recovery_file_dest" to point the filesystem locations.
We recommend that following a successful standby database creation you first run Dbvisit Standby manually once to ship and apply logs before you schedule it or run the Daemon process.
2.2.2. Sending Logs
2.2.3. Applying Logs
2.3. Creating a Single Instance Standby for an Oracle RAC Primary
In this example, we are going to create a single instance standby database using filesystem based storage for a RAC enabled primary database.
Key points to note with regards to this configuration:
- The standby database is using Filesystem Based storage:
- database files will be located in /u01/app/oracle/oradata and /u01/app/oracle/fast_recovery_area.
- Oracle Managed Files (OMF) is used
- The standby database will be created without using transportable media, meaning backups will be created locally in a temporary area (which must have sufficient disk space to hold a full compressed database backup)
- The creation process can take time. To estimate the time, keep in mind we need to create a full compressed database backup, copy the files to the standby database server and then perform a full restore
- In the example below, we modify the SPFILE parameters as the standby database is using filesystem based storage, not ASM.
2.3.2. Review Directory Structure on Standby
Once the restore is complete we now have our standby database. If we review the directory structure on the standby server we will notice the following:
The next step is to ship and apply logs manually before we enable either a schedule (using the CRON scheduler) or by running Dbvisit Standby as a Daemon process (background process) using the "dbvctl -d <DDC> -D start|stop|status" option.
2.3.3. Sending Logs from primary RAC
2.3.4. Applying logs on standby: kiwi91
We have now successfully created the standby database.
3. Creating the Standby Database - Central Console (GUI)
Create a Standby Database is one of the most important functions of Dbvisit Standby. Launch it by clicking the Create Standby Database button from the main page.
3.1. Creating Single Instance Standby
Begin by selecting the Configuration/DDC to work with . Next, you will need to select one of three possible process options:
- New Database : This will allow you to set up a new Standby Database completely from scratch. You will need to review system parameters and add/edit values as necessary. This is the default CSD process mode.
- Use Template : Using this option you can run a CSD process using values saved from a previous successful operation. This is a good way to repeat similar/identical CSD operations without having to manually change system parameters each time.
- Resume CSD : Initially disabled, this option becomes available if a previous CSD operation did not fully complete for whatever reason. This could be because you are creating a Standby database using the Transportable Media option (more on this below), or because an error has occurred that you need to resolve before re-trying to restore your database logs.
After selecting this option, you will need to review the system parameters presented in the table below the option selectors .
Please refer to Section 7.4: Edit DDC of this guide for tips on how to use the parameter table. Parameters highlighted with a blue background cannot be altered .
Following the parameter table are several Options:
- Parallel Option [ 1]: This can be enabled if you want dbvisit to determine if the transfer of the backup files can be done in parallel as well as the restore of the datafile if this option is enabled you cannot use the Transportable Media option 
- Transportable media : Set this to Yes if you want to use a physical medium to manually move your database backup files. You may wish to do this if your database is very large and it would be faster to use a physical drive to move the data.
NOTE: Choosing to use Transportable Media will effectively split the CSD process into two distinct parts: Backup and Restore. Once all necessary data is Backed up onto your Transportable Media, you will need to physically move it to the Destination Host and continue the process into the Restore stage. For details, please see section 3.2: Using Transportable Media below. Windows system login If you are using a Windows environment with Oracle 12c, you will need to enter the username and password of the Windows user that will run the Oracle service.
- Source and Target temp location : Please ensure both of these locations have enough disk space to hold a full backup of your primary database.
- Create a Standby Database  will start the process without saving your parameter settings.
- Create Standby Database & Template  will start the process AND save your parameter settings in a template. Next time you run a CSD process, you can instantly reload values from this template to speed up your work.
- Create Template Only  will ONLY create the template with your saved parameters. The CSD process itself will NOT be initiated.
Once all the options above are set, please click Submit  to initiate the Create Standby Database process.
OPTION: Use Template 
This option works exactly the same as Option 1 above, except all the values in the parameter table are loaded from a Template created during a previous iteration of the CSD process. This can be a good way to save time by reusing previously set values for complex installations.
OPTION: Resume CSD 
This option, normally disabled, will only become available if a previously initiated CSD process has stopped before completion. Most often, this will be because you have chosen to use the Transportable Media option, and the system is waiting for you to move the database backup files to the correct location before proceeding. Once you have moved the files, selecting this option and clicking Submit  will resume the process from where it stopped. NOTE: You can also do this from within the Task Details pane of the relevant CSD task - more on this in section 10 below.
Another reason this option is available may be because an error has occurred after the primary database backup step. In this case, you may be able to modify Configuration/DDC parameters, or other system settings, to resolve the error and resume the CSD process without having to re-run the database backup step.
Once the CSD process is underway, you can track it as a separate Task in the Active Task List .
3.2. Using Transportable Media Option
If you are using the transportable media option, you need to make sure that the temporary backup location you selected on the CSD main screen has full permissions for the database user.
Once the CSD process is started, the high-level steps are:
- A local backup will be created in the location specified as the source temporary backup directory - this should be your external drive, i.e. your Transportable Media.
- Once the Backup is complete, the process will be stopped and a pause option will become available in the Active Task List.
- The external storage must now be transferred to the standby site (Destination Host) and mounted to the temporary backup location previously specified.
- Once this is done, clicking on the paused CSD task in the Active Task List and then the Resume Create Standby Database button will resume the CSD process.
The images below provide an example of how a paused (waiting for Transportable Media to be moved) CSD process looks:
4. Creating an Oracle 12c Multitenant Standby Database
There are a few important pre-requisites that you need to be aware of when using Oracle 12c Multitenant option:
- Before creating a standby database, ensure that the primary database already has the required PDB created.
- Dbvisit Standby is focussed on Oracle Standard Edition (SE, SE1 and SE2) and in the case of using 12c, you are allowed to use Oracle Standard Edition 2 (SE2) with one single pluggable database. Using more than one PDB does require an Enterprise Edition license and the Multitenant Option.
- Using Oracle Managed Files (OMF) is recommended, especially when using ASM.
Please note that when you are using the Oracle-supplied templates - example the General Purpose one, you might notice that the primary SEED database is not actually located under the SEED GUID. However, when you create the standby database using Dbvisit Standby, the SEED will be placed under the GUID (as long as OMF is used).
To explain what we mean by this, let's review an example using Oracle Database 12.2.
In this example we would like to highlight that if you created a primary database using the DBCA option and you used one of the standard templates provided by Oracle - example General Purpose as shown in figure below, and Oracle Managed Files (OMF) is used, the default directory for the SEED database would not match the GUID for the seed database.
The end result showing the directory locations for the primary database can be seen below:
The standby database created in this example is making use of Filesystem Based storage - but importantly also using Oracle Managed Files.
When the standby database is created, the db_create_file_dest and db_recovery_file_dest was set. Note setting the required db_create_online_log_dest_n is recommended but not required.
5. Adding Datafiles to Primary Database
Normally, Oracle does not propagate the adding of datafiles on the primary database to the standby database. This must be done manually on the standby database.
Dbvisit Standby will automatically add the datafile to the standby database. Dbvisit Standby will attempt to generate a new name for a standby datafile, in case the primary name cannot be used due to different storage type (ASM and non-ASM) or different database file structure between the primary and standby.
There are some restrictions to automatically adding the datafiles to the standby database.
Note 1: There must be sufficient space on the standby server for Dbvisit Standby to add the datafile. If there is not sufficient space, then Oracle will generate an error message which will be captured by Dbvisit Standby and an alert will be sent.
Note 2: This feature is independent of the Oracle parameter STANDBY_FILE_MANAGEMENT. Dbvisit Standby will detect if STANDBY_FILE_MANAGEMENT has added the datafile to the standby database, and if so, Dbvisit Standby will not add the datafile.
Note 3: STANDBY_FILE_MANAGEMENT can only be used in Enterprise Edition and should not be set in Standard Edition.
Every time Dbvisit Standby runs on the primary, it takes a snapshot of primary datafile ids and names and saves it in the repository.
It detects if new data files have been added to the primary since the last run. If so Dbvisit Standby creates a new text file "datafiles_ORACLE_SID_DEST.txt" and ships it to the standby server to the location specified by parameter LOGDIR_DR, before proceeding with transferring redo logs.
Every time Dbvisit Standby runs on the standby, it reads the file datafiles_ORACLE_SID_DEST.txt and uses the primary datafile names to work out the location and name of a new standby datafile should one has to be added to the standby database. Actions related to recreating of a new standby control file are logged to Dbvisit Standby output and trace file.
This approach has certain limitations and Dbvisit may fail to obtain the primary name for a new standby datafile, if a delayed lag is set for the standby, or if the datafile(s) have been dropped and added to the primary in between two consequent Dbvisit runs and Oracle happened to reuse file ids.
To deal with this limitation Dbvisit first attempts to obtain the primary name for the new standby datafile from the datafiles_ORACLE_SID_DEST.txt file. If that fails, Dbvisit looks for Oracle error message ORA-01274 that contains the primary name of the new datafile. If the error message is not present in the sqlplus output, Dbvisit will attempt to create a new standby datafile as an OMF file, but only if the creation of OMF files is enabled on the standby. This functionality can be turned off by setting the global ADD_DATAFILE_FORCE_OMF to N (default Y).
Dbvisit Standby can by default only add a maximum of 10 data files per session. This is controlled by the MAX_DATAFILES_TO_ADD a parameter that can be set in the Dbvisit Database Configuration File (DDC)
When Using ASM
If the Standby database is making use of ASM, using OMF (Oracle Managed Files) is recommended.
If ASM is used on the standby database for database storage, datafiles on the standby database will be created as Oracle Managed Files (OMF).
If a new datafile was added to the primary database the same process will be followed as mentioned above where the "datafiles_ORACLE_SID_DEST.txt" file is used, but if the standby database is making use of ASM and OMF is enabled - db_create_file_dest is set to a specific disk group - the standby database datafiles will be added as OMF files. (Aliases will not be used).
6.1 Create Standby Database - Filesystem to Filesystem
6.2 Create Standby Database - ASM to Filesystem
6.3 Create Standby Database - ASM to ASM
6.4 Create Cascade Standby Database
6.5 Create Standby database using Transportable Media