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

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

Volume /dbvisit is not shared between both clusters, it's visible only to local cluster nodes.

1.1  Different types of Oracle SEHA configurations

Dbvisit Standby version 10 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 single instance databases running on one of the SEHA cluster node while the other node hosts no running databases

Such deployment is supported by Dbvisit version 10.2 and onwards. In this type of deployment Dbvisit uses cluster resources and shared storage to be able to failover to the other SEHA node

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

This includes configurations where for example Oracle single instance databasea A and B run on SEHA node 1 and single instance database run on node 2.

Such deployment is as of this moment currently NOT supported by Dbvisit Standby. Dbvisit Standby can be active only on one of the SEHA cluster nodes, not on both.

1.2  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 Dbvisit Standby

We need first to create directory which will contain Dbvisit installation (DBVISIT_BASE:

Continue by starting the installer and specifying this directory asd ORACLE_BASE:

Because this is our primary cluster we will install only basic components:

Next important point is when you will be asked for listener address for dbvnet:

Make sure to specify our VIP address which we created. Same thing for dbvagent:

No SEHA related change needs to be done for port and password.

2.3  Creating Cluster Action scripts for dbvnet and dbvagent

To enable easy SEHA failover for Dbvisit processes we recommend to integrate them into Oracle Grid by using action scripts.We will start by creating directory for cluster actions scripts:

Upload dbvnet and dbvnet action scripts to this directory.

Open

Open

Once files are uploaded set correct privileges:

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

You should get the exact output as displayed. Execute the same for dbvagent:

Again, you should get the exact output as displayed.

Now we can finally create resources for dbvnet and dbvagent. 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 dbvagent and dbvnet processes are 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 host is completely the same as on primary, you only need to choose dbvisit-vip2223 as listener address for dbvnet and dbvagent. The installation directory for dbvisit (DBVISIT_BASE) in our example was also /dbvisit. This volume is only local with czrlin0222 and czrlin0223 cluster and is not shared with the primary cluster czrlin0217 and czrlin0218.

3.3  Creating Cluster Action scripts for dbvnet and dbvagent

Same as with the software installation, the creation of the action script for the standby SEHA cluster is exactly the same as on primary. Use the same commands, only change node hostnames and use VIP address dbvisit-vip2223. Once you are done with this step, you should have Dbvisit setup on primary and standby SEHA cluster and you should see dbvagent and dbvnet processes running on 1st cluster node of each 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

5.1. Adding hosts and DDC file creation

To start, logon to the central console GUI. Below are the screenshots showing you how you can use the Central Console to create the DDC file for this configuration:

Step 1:  Open Main Screen, navigate to manage hosts, and first add the two hosts (dbvisit-vip2178 and dbvisit-vip2223)

Open

Step 2:   Add a new host

Open

Step 3: Add the SEHA node 1 (dbvisit-vip2178) - but not the public node hostname - you must use the VIP that we assigned. This allows us to move to czrlin0218 without having to update names as we use the Virtual IP (dbvisit-vip2178) which can be rellocated together with Dbvisit cluster resources.

Step 4:  Add dbvisit-vip2223 host

Step 5:  Review hosts - for both hosts you need to see the green checkmark.

Step 6: Add new DDC → navigate to Manage Configurations

Step 7:  Start the new DDC process by selecting "NEW"

Step 8:  Fill in the required details:

1. Select the source as the primary Virtual IP - dbvisit-vip2178, then accept the license agreement

2. Select the source Instance Name SOLO - this is obtained from the /etc/oratab file.  

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

4. Specify to use DBVNET by default (recommended)

5. You will now be presented with the primary SEHA database details, review and confirm the ASM instances match the servers they are running on.  Dbvisit Standby will detect these values based on the connection that was made to the primary instance that was selected in step 2 above.

6. As we are going to create a standby SEHA database, we will adjust this setting to YES.  See the next screenshot below

From the above image we can see:

1. Specify the standby database will be a SEHA enabled environment

2. Select the standby Virtual IP hostname - dbvisit-vip223

3. You are then presented with the SEHA node1 and node2 on the standby server, fill in the required detail

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

5. Review and update the Dbvisit Base location on the standby server if different

6. Review the Oracle Database Home on the standby server

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

8. Specify the Dbvisit Standby Configuration (DDC) name

9. Provide the license key for the configuration, this is optional and can be provided after the DDC creation, but must be provided before running the CSD(Create Standby Database)

Once the details are provided, click on Submit and the DDC file will be created.

Step 9:  Review the DDC file

Step 10:  Make sure you apply your License key for this newly created DDC before you move onto the Create Standby Database (CSD), this can be done while creating the DDC itself.

6.  Creating the Standby Database (CSD)

This example will only show using the Central Console. It is possible to create the standby database either via the Command Line Interface (CLI) using the command:  ./dbvctl -d <DDC> --csd   in this example:  "./dbvctl -d SOLO --csd"

To use the Central Console, navigate to the Central Console page and follow the steps as outlined below:

6.1 Start CSD process

Step 1:  Navigate to the Create Standby Database (CSD) Menu

Step 2:  Select the DDC, Create New Database option and update the Database SPFILE parameters to match the Standby server configuration. Make sure you review the locations of the datafiles, redo logs and spfile.

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.

Step 3: 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.

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

6.1 Send logs from Primary to Standby

Once CSD process is completed, verify archivelogs can be successfully sent and applied. Navigate to Database actions, click on send log button

Apply Archive logs to Standby database

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

Graceful Switchover (GS)

1. Select Graceful switchover, Choose the Configuration (1) and press Submit (2)

3. Primary and Standby server roles are swapped

4. Switchback

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