Oracle SEHA on Windows

Owned by Jan Klinke
Last updated: Mar 05, 2024
18 min read

1.  Introduction

This section will cover deploying Dbvisit Standby on an Oracle Standard Edition High Availability (SEHA) Windows cluster. SEHA is a feature replacing RAC, which is no longer available in Standard Edition, starting with the 19c version.

SEHA feature is available only on version 19.7 and onwards. Note that shared ACFS volume is required for Dbvisit installation. ACFS on Windows is deprecated for 19c and de-supported for all further releases by Oracle. In other words the only supported Oracle version from Dbvisit for SEHA configuration is 19c.

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 w19ora19seha3, w19ora19seha4, allocated VIP dbvisit-vip34, shared ACFS volume C:\dbvisit (shared between w19ora19seha3 and w19ora19seha4)

Standby SEHA Cluster, nodes w22ora19seha1, w22ora19seha2, allocated VIP dbvisit-vip12, shared ACFS volume C:\dbvisit (shared between w22ora19seha1 and w22ora19seha2)

Volume C:\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 similarly to Oracle RAC Cluster, with a few differences. There are two types of possible SEHA cluster configurations:

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

Such deployment is supported by Dbvisit Standby MP 11.1 and onwards. In this type of deployment, Dbvisit uses cluster resources and shared storage to failover to the other SEHA node.

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

This includes configurations where, for example, Oracle database instances A and B run on SEHA node 1 and database instance C runs on node 2. Dbvisit Standby currently does NOT support such Deployments. Dbvisit Standby can be active only on one of the SEHA cluster nodes, not on both.

1.2  Oracle RAC

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

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

https://dbvisit.atlassian.net/wiki/spaces/DSMP/pages/3238264943/System+Requirements#3.1.--Supported-Oracle-Database-Editions

From 19c onwards, RAC is an Enterprise Edition (EE) option only and is not certified with Dbvisit Standby. Don't hesitate to get in touch with Dbvisit Support if you wish to deploy Dbvisit to such an RAC environment.

1.3  Prerequisites

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

  • A new dedicated IP address and hostname for the new cluster VIP address are needed. 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 only provided by ACFS (no support for other methods)

In this guide, we will use shared ACFS storage C:\dbvisit created on primary and standby clusters

C:\Users\Administrator>acfsutil info storage Diskgroup Consumer Space Size With Mirroring Usable Free %Free Path ACFS 19.65 19.65 0.54 2% DBVISIT 19.00 19.00 18.22 95% C:\dbvisit CRS 4.99 4.99 4.64 92% DATA 39.29 39.29 39.18 99% FRA 19.65 19.65 17.88 91% ---- unit of measurement: GB

  • 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:

C:\Users\Administrator>srvctl config database -d TEST01 Database unique name: TEST01 Database name: Oracle home: C:\app\oracle\product\19.0.0.0\dbhome_1 Oracle user: dbvisit\oracle ... Configured nodes: w19ora19seha3,w19ora19seha4

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

  • On both SEHA nodes, check that the Windows Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraDB*Home* has a string value for ORACLE_SID.

Unless otherwise stated all commands in following chapters were executed as “Administrator” user

2.  Dbvisit Software Setup on Primary Cluster

2.1  Creating Dbvisit Dedicated VIP Address

Before starting with Dbvisit Installation, we need to create a dedicated VIP address mentioned in the "1.3 Prerequisites". In our example, the pre-allocated VIP for our SEHA cluster is "172.16.17.253," and we decided to assign the DNS name "dbvisit-vip34". To create a new VIP address, you need to execute:

C:\Users\Administrator>appvipcfg create -network=1 -ip=192.168.18.253 -vipname=dbvisit-vip34 -user=dbvisit\oracle Using configuration parameter file: C:\app\grid\product\19.0.0.0\gridhome_1\crs\install\crsconfig_params The log of current session can be found at: C:\app\orabase\crsdata\w19ora19seha3\scripts\appvipcfg.log

Verify VIP is correctly created:

2.2  Installing Dbvagentmanager on Primary Cluster

This section will highlight only the most important and SEHA-related aspects of Dbvisit Installation. For a complete guide please refer to:

https://dbvisit.atlassian.net/wiki/spaces/DSMP/pages/3242000447

We’ll be aiming for the Dbvisit configuration as follows:

Nodes

Associated VIP (active only on one SEHA node)

Installed Dbvisit component

Nodes

Associated VIP (active only on one SEHA node)

Installed Dbvisit component

w19ora19seha3, w19ora19seha4

dbvisit-vip34

Dbvagentmanager

w22ora19seha1, w22ora19seha2

dbvisit-vip12

Dbvagentmanager, Dbvcontrol

We will first start on the 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 (installation file agent-v11.6.0.msi was downloaded to C:\dbvisit\sw):

image-20240111-122750.png

Go for next to set passphrase:

image-20240123-122914.png

Choose any passphrase (but remember it) on next page and make sure to install in C:\dbvisit\app:

Once installation is completed, edit the dbvagentmanager configuration file and set FileTransferListenAddress to DBVISIT-VIP34.DBVISIT.CZ and save the file

Restart dbvagentmanager service:

set it to manual start mode:

Set the permissions to full control on service dbvagentmanager for “Service Logon User” and “Interactively logged-on user”:

2.3  Creating Cluster Action script for dbvagentmanager

To enable SEHA failover for dbvagentmanager, we recommend integrating them into Oracle Grid by using an action script. Action script for dbvagentmanager and dbvcontrol can downloaded from Dbvisit Software Github repository:

https://github.com/dbvisitsoftware/standby/blob/main/cluster-action-scripts/dbvcrs.bat

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

Upload the script to directory C:\dbvisit\app\bin

2.4  Creating dbvagentmanager service on the 2nd SEHA node

On the 2nd SEHA node, we need to create the Windows service manually, set its startup mode to manual, and change the password (use an actual password):

Set the permissions to full control on service dbvagentmanager for “Service Logon User” and “Interactively logged-on user”:

2.5  Creating dbvagentmanager Cluster Resource

Make sure the dbvagentmanager service is stopped on both SEHA nodes. Now we can finally create the dbvagentmanager action script and test VIP + dbvagentmanager relocation:

Try to start dbvagentmanager via crsctl and check the service status afterward (must be RUNNING):

Test relocation of the VIP address back and forth:

After each relocation of the VIP address, check that the dbvagentmanager service is running on that respective node and that it’s stopped on the other node. 

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

3.  Dbvisit Software Setup on Standby Cluster

3.1  Creating Dbvisit Dedicated VIP Address

Same as on the primary SEHA cluster, Before starting with Dbvisit Installation, we need to create a dedicated VIP address mentioned in the "1.3 Prerequisites". Our pre-allocated VIP for our standby SEHA cluster is "172.16.17.254" and we decided to assign DNS name "dbvisit-vip12". To create a new VIP address, you need to execute:

Verify VIP is correctly created:

3.2  Installing Dbvagentmanager on Standby Cluster

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 dbvagentmanager. We need first to create the directory which will contain Dbvisit installation DBVISIT_BASE:

Continue by starting the dbvagentmanager installer and specifying this directory as DBVISIT_BASE (installation file agent-v11.6.0.msi was downloadded to C:\dbvisit\sw):

go for next to set passphrase:

Use the same passphrase as on the primary cluster, then on the next page make sure to install in C:\dbvisit\app:

Once installation is completed, edit the dbvagentmanager configruation file and set FileTransferListenAddress to DBVISIT-VIP12.DBVISIT.CZ and save the file

Restart dbvagentmanager service:

Set it to manual start mode:

Set the permissions to full control on service dbvagentmanager for “Service Logon User” and “Interactively logged-on user”:

3.3  Installing Dbvcontrol on Standby Cluster

You can skip this section if you will deploy the controlcenter elsewhere.

Start dbvcontrol installation:

There’s nothing to change throughout the whole installer except the passphrase - use the same passphrase as before:

And make sure to install it in C:\dbvisit\app:

Once installation is completed, edit the dbvagentmanager configruation file and set FileTransferListenAddress to DBVISIT-VIP12.DBVISIT.CZ and save the file

Set all three properties to DBVISIT-VIP12.DBVISIT.CZ

Restart dbvcontrol service:

set it to manual start mode:

Set the permissions to full control on service dbvcontrol for “Service Logon User” and “Interactively logged-on user”:

3.4  Creating Cluster Action Script for dbvagentmanager and dbvcontrol

We will use exactly the same action script as on the primary cluster. Download again from GiHub repository:

https://github.com/dbvisitsoftware/standby/blob/main/cluster-action-scripts/dbvcrs.bat

Copy it into C:\dbvisit\app\bin on standby cluster.

3.5  Creating dbvagentmanager and dbvcontrol service on 2nd SEHA node

On 2nd SEHA node, we need to create the Windows service manually, set its startup mode to manual, and change the password (use an actual password):

Set the permissions to full control on service dbvagentmanager for “Service Logon User” and “Interactively logged-on user”:

If you installed dbvcontrol as well, continue to perform the same steps for dbvcontrol:

Set the permissions to full control on service dbvcontrol for “Service Logon User” and “Interactively logged-on user”:

3.6  Creating dbvagentmanager and dbvcontrol Cluster Resources

Skip the dbvcontrol part if dbvcontrol isn’t installed. Make sure the dbvagentmanager service is stopped on both SEHA nodes. Now we can finally create the dbvagentmanager action script and test VIP + dbvagentmanager relocation:

Try to startup dbvagentmanager via crsctl and verify the service status (must be RUNNING):

Add the dbvcontrol resource:

Try to startup dbvcontrol via crsctl and verify the service status (must be RUNNING):

Test relocation of the VIP address back and forth:

After each relocation of the VIP address, check that dbvagentmanager and dbvcontrol service is running on that respective node and that it’s stopped on the other node. 

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

4.  Creating Dbvisit Database Configuration (DDC) with GUI

Prerequisites:

  • You need to manually modify privileges for user which runs dbvagentmanager service to Windows registry:

In our case, dbvagentmanager is run by domain account dbvisit\oracle, so we need to add it to two Registry Keys: “Oracle” (HKEY_LOCAL_MACHINE\SOFTWARE\Oracle) and “KEY_OraDB19Home1” (HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\KEY_OraDB19Home1). The privileges needed are “Full Control”

  • Make sure the key “KEY_OraDB19Home1” contains value “ORACLE_SID”

Once done, proceed with the next steps.

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)

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

Step 3: Select the Source database Instance name (in this example TEST01):

Step 4:  Next step is to select the Standby Host; in this example DBVISIT-VIP12

Step 5.1:

Once the Primary and Standby hosts are selected, you will be presented with the SEHA cluster(s) details. Ensure to correctly enter all SEHA cluster details (nodenames and ASM instances).

Make sure the option “Do you want to setup SEHA environment for Your destination Database” is selected if your standby is SEHA as well.

Step 5.2:

Continue to fill in the required details. Make sure to correctly set ARCHSOURCE (1) and ARCHDEST (2) - they should ideally be the same directory and exist on primary & standby.

 

Continue changing the rest of the details if needed. In our example, we left everything to the suggested values:

  • Standby Oracle SID

  • Oracle Database Home on the Standby server

  • DB Unique Name (db_unique_name) of the standby if required

  • Dbvisit Base location on the Standby server if different

Finalize by setting the DDC name, and license key and click on “Create Configuration”:

 

6.  Setup Disaster Recovery Database

Once the configuration is created, you can create the SEHA standby 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 applicable.

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.

Step 3: skip these fields and leave blank as we did create services manually previously:

Step 4: 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. Optionally ceate template from your choices (3) and finally, click on “Create standby dabase” (4).

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

Check the task result and make sure the standby database is correctly configured:

6. Perform Graceful Switchover

Primary Server: dbvisit-vip12

Standby Server dbvisit-vip23

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

https://dbvisit.atlassian.net/wiki/spaces/DSMP/pages/3297312770

Step 1: Navigate to DASHBOARD, click on the TEST01 (1) configuration and Select Graceful switchover (2), wait for prechecks to complete and select start (3)

Step 2: Primary and Standby server roles are swapped

Step 3: Switchback:

 

7.  Summary

Standby cluster now hosts SEHA standby database, which is also registered within OCR. You can check by executing the command below on the primary and standby cluster:

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

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

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

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