If your primary database is residing on ASM, you must ensure that /etc/oratab contains entry for ASM instance. Database on ODA KVM is the only exception from this rule - with KVM, ASM instance must not be present in the /etc/oratab
1. Introduction
In this section, we will cover the creation of a new Dbvisit Standby Multiplatform Configuration, also known as creating a Dbvisit Database Configuration (DDC) file.
It is important that before you continue with these sections that you make sure the following pre-requisites have been performed:
Operating Systems are compatible
It is recommended that the primary and standby server operating systems match
Oracle Database Software is installed on both the primary and standby database servers
The Oracle Database software must use the same Edition - mixing editions is not recommended. Using a combination of Standard and Enterprise Edition is not supported.
You have a Primary Database already configured and it is open read/write and fully-functional
If you are using Oracle RAC, when installing and configuring Dbvisit Standby, it is recommended at the point of installation and configuration that all nodes on the Primary database be fully functional and that all instances are open and running.
If you are using Oracle RAC:
Shared storage is highly recommended for:
Dbvisit Standby Installation (Dbvisit Base)
Dbvisit Standby ARCHDEST and ARCHSOURCE locations
Agent(dbvagentmanager)must be installed and configured on both primary and standby servers.
Control Center must be installed on a separate server. Optionally you could install it on the standby server. However, we strongly recommend installing in a separate server other than Database servers
Dbvisit Standby Multiplatform allows you to create a DDC (Dbvisit Standby configuration file) for the following scenarios:
Oracle single instance database as primary with a single instance database as a standby
The primary and standby databases can use Filesystem based storage or ASM
If ASM is to be used on standby it must already be configured with the required disk groups
Primary and Standby database systems should match - especially the Oracle Database software (Including patch levels)
Mixing Database Editions are not supported. Both primary and standby must use the same Oracle Software version and Edition.
Oracle Real Application Cluster (RAC) database as primary to a single instance standby database (with multiple threads but only one is used)
Oracle Real Application Cluster (RAC) database as primary with an Oracle RAC database as a standby
Control Center (GUI) will be the preferred method for performing all the operations in Multiplatform. The CLI exists but must not be used without Dbvisit support supervision.
Standby Multiplatform is using Archive Logs to update the standby database. There should be sufficient space on the Standby Database server to store the archive logs from the primary database server. It is recommended you have sufficient space to keep at least 1 to 2 days worth of archive logs on disk. Please make sure you cater for peak load periods during which more redo can be generated.
Standby Multiplatform makes use of a Dbvisit Archive Destination referred to as ARCHDEST (on the standby server) and ARCSOURCE (on the primary server)
This is used to store the archive logs shipped from the primary server to the standby server. This location is NOT the same as the database archivelog destination.
This location should be big enough to keep at least 1 to 2 day's worth of archive logs, but the capacity to store three days or more is recommended.
For example, if you generate 2GB worth of redo (archive logs) on the primary in one day, you should have at least 2GB as an absolute minimum free space on the standby in the folder specified as the ARCHDEST.
2. Create a Configuration For Filesystem Based Storage
Below is a summary of the environment that will be used in this example:
This environment will not be using ASM for database storage
Primary Server: dbvel71
Standby Server: dbvel72
Primary Database Name: orcl21c
Primary Database Unique Name: orcl21c
Standby Database Unique Name and SID will be the same: orcl21c
Dbvisit Standby ARCHSOURCE location on the primary server: /u01/oracle/dbvisit_arch/orcl21c
Dbvisit Standby ARCHDEST location on standby server: /u01/oracle/dbvisit_arch/orcl21c
The Dbvisit Base directory is /usr/dbvisit
Dbvisit Standby Multiplatform is already installed on both the primary and standby servers
2.1 Login to the Central Console
Login to the central console from the web browser (preferred browsers are Firefox, Chrome). The console login URL is in the below format. For the below example, we have used the Firefox browser. It is always recommended to update your browser to the latest release.
https://<IPV4 address of the server on which control center is installed>:<control center port default is 12345>. In our example, it translates to
https://192.168.56.10:12345 ( 1 )
The default login and password ( 2 ) is admin/admin. Press Login ( 3 ) to enter into the main screen prompting to create new configurations or to dashboard if existing configurations are present.
2.2 Choosing New Configuration
As a next step, you can choose to create either Oracle ( 1 ) or SQL Server ( 2 ) configuration. In this example, we will create a configuration for Oracle Database ( 1 ). You can also check out image ( 3 )on how the standby multiplatform works.
2.3 Select Host
The next step is choosing the host for creating the configuration. You must choose the primary host first. In this case dbvel71.oraclekiwi.co.nz ( 1 )
Choosing the host will lead you to select the source database for which you need to create the configuration. We will be creating a configuration for the Oracle 21c database orcl21c.
2.4 Selecting Standby Host
Select the standby host from the dropdown list. The dropdown will list all the known hosts to the control center. In this example, we just have two hosts. One source host is primary and the other is the standby host.
2.5 Advanced Settings
Clicking on Advanced Settings ( 1 ) will prompt you to enter/change default configurational changes for the Oracle Database Configuration.
( 2 ) Archive Log File Location on Source Host: This location must be available in the source host. By default, there will no files in this location as this location will be used for storing archivelogs post graceful switchover for applying archivelogs. This location is also used as a temporary location to copy archivelogs from ASM to the filesystem and move the archivelogs to standby.
( 3 ) New configuration name: By default, the configuration is named as same as the source database name. This can be changed to any name preferred. But it's recommended to leave it as such as it's easier to identify the configuration with the database.
( 4 ) Oracle SID: The standby database Oracle SID (Instance Name). This may be different from the primary database instance name.
( 5 ) ORACLE_HOME directory on Standby: The Oracle Home location on the standby server. It is recommended that you add an entry into the /etc/oratab file on the standby server for the standby database.
( 6 ) Unique database name: This will be the DB_UNIQUE_NAME value of the standby database. It may be different than the Primary database one - by default, it will be set to the same value which should be fine for most configurations. You must set this to a different value if you are running two standby databases on the same standby database server - where both of them are for the exact same primary database.
( 7 ) Archivelog Files Location on Standby Host: This is the location where Dbvisit will copy archivelogs on the standby server from the primary server. By default, compression will be enabled and archive logs will be stored in compressed format on the standby server. This may be changed following the DDC file creation.
The location is not the same as the Oracle Database Archivelog destination and should never be located in the Fast Recovery Area (FRA) or be the same location as the Database Archivelog Destination.
( 8 ) Standby Dbvisit base directory: This location is automatically populated and must not be changed.
( 9 ) Would you like to use Automatic Storage Management: Selecting if ASM is being used on the standby server. Note that if you select yes for this option you must already have ASM configured on the standby database server. Once you use the toggle button it will prompt you to enter the ASM instance name of the standby server. This example uses filesystem for the standby so we leave it to default No
2.6 License Key and Create Configuration
Enter the license key provided by the Dbvisit renewals team or your trial key which was provided to you during your download. Once done please click on Create Configuration ( 1 )
2.7 Configuration List
The configuration will be listed in the dashboard and is now ready to set up Disaster Recovery by creating the standby database.
3 Create a Configuration for a Standby DB using ASM
The procedure does not change for creating an Oracle configuration for databases using ASM until 2.5 Advanced Settings. In the advanced setting, the ASM instance has to be provided to ensure that standby configuration is updated for the database using ASM storage.
( 1 ) The toggle button has to be slid to Yes to be enabled using ASM instance as storage for the standby database.
( 2 ) ASM instance name must be provided for the storage. This ASM instance would be used to create the DR standby database in ASM.
4 Create a Configuration on Oracle Database Appliance (ODA)
If you are using ODA machines, create an empty database on standby ODA and manually delete all of it’s files - dbstorage and dbhome will be preserved.
Alternatively, It is possible that you create the dbstorages before creating the standby databases using Dbvisit. Please refer to v10 documentation for the example of creating dbstorage:
For KVM, Dbvisit Multiplatform only supports homogeneous environments with both Primary and Standby servers being ODA KVM.
When creating the configuration on ODA KVM the process is very similar to the one described above. The differences are the following:
When ODA KVM is identified a new box with ASM details is displayed. For KVM the ASM instance runs directly on ODA bare metal, therefore the user needs to provide the hostname/ip address of the ODA server (e.g. see 10.100.100.250 in the screenshot bellow). Other connection details have to allow Dbvisit components to be able to connect from KVM to ASM instance running on ODA server via SQLNet.
