1.  Introduction

In this section, we will cover how to deploy Dbvisit Standby on an Oracle Standard Edition High Availability (SEHA) cluster. SEHA is a feature replacing RAC which is no longer available on Standard Edition starting with 19c version.

In this section, the concepts will be explained using an example. We will demonstrate how to configure Dbvisit on SEHA cluster with sample test environment which consists of following servers:

Primary SEHA Cluster, nodes czrlin0217, czrlin0218, allocated VIP dbvisit-vip2178 (192.168.8.12), shared volume /dbvisit (shared between czrlin0217 and czrlin0218)

Standby SEHA Cluster, nodes czrlin0222, czrlin0223, allocated VIP dbvisit-vip2223 (192.168.8.13), shared volume /dbvisit (shared between czrlin0222 and czrlin0223)

Volume /dbvisit is not shared between both clusters, it's shared between two nodes on local cluster only (Volume is not shared between primary and standby).

1.1  Different types of Oracle SEHA configurations

Dbvisit Standby MP handles Oracle SEHA deployment similar to Oracle RAC Cluster with few differences. There are two types of possible SEHA cluster configurations:

A. One or more Oracle database instances running on one of the SEHA cluster nodes while the other node hosts are not running any database instances.

B. Two or more Oracle database instances running on both SEHA cluster nodes.

1.2  Oracle RAC

For deployment to Oracle RAC clusters, follow the same steps as mentioned below. There is only cosmetic difference when creating DDC configuration in the GUI at the end of the process.

Make sure that you’re running supported RAC version as per:

System Requirements | 3.1. Supported Oracle Database Editions

From 19c onwards, RAC is Enterprise Edition (EE) option only and is not certified with Dbvisit Standby, please contact Dbvisit Support if you wish to deploy Dbvisit to such RAC environment.

1.3  Prerequisites

To deploy Dbvisit Standby on SEHA cluster following prerequisites are needed:

• New dedicated IP address and hostname for new cluster VIP address. This VIP address will be different from existing cluster VIP addresses. Our suggestion is to use hostname such as dbvisit-vip1 for example.

• Shared storage between both primary cluster nodes with minimum 15GB free space. Such shared storage can be provided by ACFS or NFS for example

• Make sure the Oracle Grid Infrastructure is deployed as per Oracle documentation. The group membership for oracle and grid users needs to be correct. Dbvisit supports cluster role separation (oracle and grid user) as well as simple configuration (oracle user only)

• Verify that the primary oracle database is SEHA enabled:

• In srvctl config output "Configured nodes" needs to contain TWO nodes. If you see only one node, database does not have SEHA feature enabled

• Make sure that /etc/oratab on each cluster node contains entry for specific ASM instance. For example on 1st node you need to have:

And on 2nd node, you need to have entry for +ASM2.

2.  Dbvisit Software Setup on Primary Cluster

2.1  Creating Dbvisit Dedicated VIP Address

Before starting with Dbvisit Installation we need to create dedicated VIP address mentioned in the "1.2 Prerequisites". In our example the pre-allocated VIP for our SEHA cluster is "192.168.8.12" and we decided to assign DNS name "dbvisit-vip2178". To create new VIP address you need to execute as root user:

the setperm command with "grid" user is valid only when using role separation on your SEHA cluster. Once VIP is created, test migrating is and SSH to it as oracle user:

You should get connected to both nodes. Finish this preparation step by relocating the new VIP to the 1st SEHA cluster node.

2.2  Installing Dbvisit Software

In this section we will highlight only the most important and SEHA related aspects of Dbvisit Installation. For complete guide please refer to:

Installing Standby Multiplatform

In this example we’ll be aiming for Dbvisit configuration as follows:

We will first start on primary SEHA cluster. We need first to create directory which will contain Dbvisit installation DBVISIT_BASE:

Continue by starting the dbvagentmanager installer and specifying this directory as DBVISIT_BASE:

Do not create systemctl service. There’s no dbvcontrol component on this SEHA cluster - installation of the product on primary cluster is hence finished.

2.3  Creating Cluster Action script for dbvagentmanager

To enable easy SEHA failover for dbvagentmanager we recommend to integrate them into Oracle Grid by using action script. Here is single action script for dbvagentmanager and for dbvcontrol:

Open

Dbvcontrol will not be installed on primary cluster, but same action script will be used for dbvagentmanager and dbvcontrol on standby cluster.

Upload the script to directory /dbvisit/app/standbymp/bin and set correct privileges:

You need to check that the scripts are working properly. For checking run:

You should get the exact output as displayed.

Now we can finally create resource for dbvagentmanager. As root user execute:

As oracle user start resources and verify processes are started:

Test relocation of the VIP address back and forth:

After each relocation of VIP address, check that dbvagentmanager process is running on that respective node. 

This step concludes the installation and setup of Dbvisit on primary SEHA cluster

3.  Dbvisit Software Setup on Standby Cluster

3.1  Creating Dbvisit Dedicated VIP Address

Same as on primary SEHA cluster, before starting with Dbvisit Installation we need to create dedicated VIP address mentioned in the "1.2 Prerequisites". Our pre-allocated VIP for our styandby SEHA cluster is "192.168.8.13" and we decided to assign DNS name "dbvisit-vip2223". To create new VIP address you need to execute as root user:

the setperm command with "grid" user is valid only when using role separation on your SEHA cluster. Once VIP is created, test migrating is and SSH to it as oracle user:

You should get connected to both nodes. Finish this preparation step by relocating the new VIP to the 1st SEHA cluster node.

3.2  Installing Dbvisit Software

Installation of Dbvisit software on standby cluster is completely the same as on primary - the only difference is that we’ll install dbvcontrol component in addition to dbvamanager. First install dbvagentmanager:

Do not create systemctl service. Afterwards, install dbvcontrol:

Do not create systemctl service. We have installed both components on standby cluster, installation of the product is hence finished.

3.3  Creating Cluster Action scripts for dbvagentmanager and dbvcontrol

Upload the action script from primary cluster from to directory /dbvisit/app/standbymp/bin and set correct privileges:

You need to check that the scripts are working properly - do exactly the same steps as on primary cluster.

Now we can finally create resource for dbvagentmanager and dbvcontrol As root user execute:

As oracle user start resources and verify processes are started:

Test relocation of the VIP address back and forth:

After each relocation of VIP address, check that dbvagentmanager and dbvcontrol process is running on that respective node. 

This step concludes the installation and setup of Dbvisit on standby SEHA cluster

4.  Creating Dbvisit Database Configuration (DDC) with CLI

Here is and example on how to create DDC file for SEHA configuration. In our sample test environment, we have primary database SOLO running on primary SEHA cluster czrlin0217 and czrlin0218 with database home /u02/app/oracle/product/21.0.0/dbhome_1.

Make sure dbvisit vip as well as Oracle SEHA database instance runs on first SEHA node and from first SEHA node run:

Answer initial prompts and accept licence agreement:

Now the main part of the setup will follow, first we enter primary database details - select your primary instance and confirm:

Use Dbvisit primary cluster VIP. Next step is to choose a directory for archsource.

In Following part we will need to provide information about SEHA node names and names of ASM instances running on SEHA nodes.

Next we set communication details for primary site. We don’t want SSH nor to change the default port, so we go with default values.

Now we need to enter details for the standby site. In our case remote site is also SEHA cluster so we enter VIP address of the second SEHA cluster and we choose to use default port for communication.

Next is to enter the configuration details of second SEHA cluster:

After entering unique name for standby database there’s important choice if standby is supposed to be SEHA, in our case yes, so we go with non-default:

Next important choice is ARCHDEST directory on standby server. This directory will receive all archivelogs from primary server, so make sure to choose directory on mountpoint with sufficient space. We can also change the instance name for our standby database (ORACLE_SID_DR) but in our example we go with default.

In next part we enter details about standby SEHA cluster. For educational purposes we will choose to use ACFS for our standby database.

Licence key is the last step, we skipped it as we can modify it later. The very last step is the review and final confirmation:

DDC file is now created.

5.  Creating Dbvisit Database Configuration (DDC) with GUI

To start, logon to the GUI. Below are the screenshots showing you how you can use them to create the New Oracle database configuration

Step 1:  Open Main Screen, navigate to New Configuration click (1)

Open

Step 2:  Choose (1) the Primary host dbvisit-vip2178 from the discovered host list.

Open

Step 3: Select the Source database Instance name SOLO. It is obtained from /etc/oratab

Step 4:  Next step is to select the Standby Host. Choose dbvisit-vip2223

Next step will apper a bit different for Oracle RAC and for Oracle SEHA.

Step 5.1 SEHA:

(1)Once the Primary and Standby hosts are selected you will now be presented with the primary SEHA database details, and review the node and ASM instances details.  

(2) Choose Yes to set up SEHA Standby.

(3) You are then presented with the SEHA node1 and node2 on the Standby server, fill in the required details

Step 5.2 RAC

For Oracle RAC this screen will appear a bit different:

(1) First, select whether you wish to enable RAC for the standby site

(2) Afterwards, you will need to fill in the RAC node hostnames

Step 6: Fill in the below-required details

1. Specify the ARCHSOURCE location.  This location should ideally be located on the shared storage location.  Remember when a Graceful Switchover is performed the roles are reversed between the ARCSOURCE and the ARCHDEST values in the DDC file

2. Review and update the Oracle SID. In this example, we are going to keep same as primary

3. Review the Oracle Database Home on the Standby server

4. Review and update the DB Unique Name (db_unique_name) of the standby if required - default value recommended 

5. Specify the ARCHDEST location - this should be on shared storage and is the location where Dbvisit Standby will transfer archive logs into the standby server.

6. Review and update the Dbvisit Base location on the Standby server if different

7. Specify the Dbvisit Standby Configuration (DDC) name

8. Provide the license key for the configuration.

9. Create New Configuration

6.  Setup Disaster Recovery Database

This example will only show using the Central Console. To use the Central Console, navigate to the Central Console page and follow the steps as outlined below:

6.1 Create SEHA DR database

Step 1:  Navigate to the DASHBOARD and click on Set up now

Step 2: Select Yes, to register your standby database with Clusterware if available

Review Temporary Backup Locations - Make sure that this location has sufficient space for a full RMAN compressed backup of the database.  In this example /usr/tmp has sufficient space on both the primary and standby.

Review the parameters and make sure the locations of the datafiles, redo logs and spfile exist on the Standby server

In this example, the primary and standby systems match exactly from a storage point of view (same disk groups etc) so we do not have to change any parameters.

Choose options (1) and (2) to automatically enable the scheduling and Observer once the Standby database is Created

Step 3: A job will appear in the taskbar, wait until it completes:

6. Perform Graceful Switchover

Primary Server: dbvisit-vip2178

Standby Server dbvisit-vip2223

Please refer the below link for the pre-requisites steps to be performed before switchover.

Oracle: Graceful Switchover

1. Navigate to DASHBOARd, click on the SOLO configuration and Select Graceful switchover

2. Internally pre-checks are done to check if the configuration is ready for switchover

3. Primary and Standby server roles are swapped

4. Switchback

7.  Summary

Standby cluster now hosts SEHA standby database which is also registered within OCR. you can check by executing the command below:

“Configured nodes” attribute needs to contain two cluster nodes otehrwise the database isn’t SEHA enabled. “Start options” and “Stop options” are always different for primary and standby database. “Database role” is always PRIMARY for primary and standby database.

• You’re able to failover primary or standby SEHA database by running srvctl relocate database -d SOLO -node <nodename>

• There’s no dependency between Dbvisit VIP and SEHA database, so if you manually relocate SEHA database, you also have to manually relocate Dbvisit VIP: crsctl relocate resource dbvisit-vip2223

• In case when node where SEHA database and Dbvisit VIP run wil fail, gets rebooted, SEHA database as well as Dbvisit VIP will get failed over to the second node automatically

• This guide doesn’t include integrating dbvctl daemon process for automatic log shipping and automatic log apply as cluster resource. If you wish, you can create action script for dbvctl daemon. In case you create dbvctl daemon as cluster resource you must not use Dbvisit CLI or GUI to control the daemon.