/
Standard Edition High Availability

Standard Edition High Availability

Owned by Jan Klinke
Last updated: May 30, 2022 by Shalini Anbu
20 min read

On this page:

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.

SEHA feature is available only on version 19.7 and onwards

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

When using NFS shared volume, mount it with "noac" option

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

[oracle@czrlin0217 ~]$ . oraenv ORACLE_SID = [SOLO] ? +ASM1 The Oracle base has been set to /u01/app/21.0.0/grid_base [oracle@czrlin0217 ~]$ srvctl config database -d SOLO Database unique name: SOLO Database name: ... Database instance: SOLO Configured nodes: czrlin0217,czrlin0218 ...

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

$ cat /etc/oratab | grep ASM # a database or ASM Configuration Assistant while creating ASM instance. +ASM1:/u01/app/21.0.0/grid:N

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:

. oraenv [+ASM1] appvipcfg create -network=1 -ip=192.168.8.12 -vipname=dbvisit-vip2178 -user=root crsctl setperm resource dbvisit-vip2178 -u user:oracle:r-x crsctl setperm resource dbvisit-vip2178 -u user:grid:r-x crsctl start resource dbvisit-vip2178 -n czrlin0217

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:

ssh dbvisit-vip2178 crsctl relocate resource dbvisit-vip2178 -f ssh dbvisit-vip2178 crsctl relocate resource dbvisit-vip2178 -f

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

 

Before starting installation make sure to provision shared volume to your SEHA cluster (for example ACFS shared volume or NFS volume).  The size needs to be at least 15GB. In this example our shared volume is provided by ACFS and is mounted on /dbvisit

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:

mkdir /dbvisit/app

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

$ ./install-dbvisit Enter a custom value or press ENTER to accept default [/usr/dbvisit]: > /dbvisit/app DBVISIT_BASE = /dbvisit/app

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

Choose component(s): 1 - Core Components (Dbvisit Standby Cli, Dbvnet, Dbvagent) Your choice: 1

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

>>> Please specify the Local host name to be used by Dbvnet on this server. ... Enter a custom value or press ENTER to accept default [czrlin0217]: > dbvisit-vip2178 ... ----------------------------------------------------------- Summary of the Dbvisit DBVNET configuration ----------------------------------------------------------- DBVISIT_BASE /dbvisit/app1 DBVNET_LOCAL_HOST dbvisit-vip2178 DBVNET_LOCAL_PORT 7890 DBVNET_PASSPHRASE heslo123

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

>>> Please specify the IPv4 address or host name to be used for the Dbvisit Agent. ... Enter a custom value or press ENTER to accept default [czrlin0217]: > dbvisit-vip2178 ... ----------------------------------------------------------- Summary of the Dbvisit DBVAGENT configuration ----------------------------------------------------------- DBVISIT_BASE /dbvisit/app1 DBVAGENT_LOCAL_HOST dbvisit-vip2178 DBVAGENT_LOCAL_PORT 7891 DBVAGENT_PASSPHRASE heslo123 DBVAGENT_WEBSERVER_HOST DBVAGENT_WEBSERVER_PORT

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:

mkdir /dbvisit/scripts

Upload dbvnet and dbvnet action scripts to this directory.

If you will use our sample scripts, do NOT change the script names. If you do change the name, you need to change the contents of the script as well.

You can easily create also action script for dbvserver component by simply taking dbvnet or dbvagent script and only replacing “dbvagent” string with “dbvserver”

Once files are uploaded set correct privileges:

cd /dbvisit/scripts chmod +x *sh

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

$ ./dbvnet_action.sh start | grep Run Running start dbvnet resource with return code 0 $ ./dbvnet_action.sh check | grep Run Running check dbvnet resource with return code 0 $ ./dbvnet_action.sh stop | grep Run Running stop dbvnet resource with return code 0 $ ./dbvnet_action.sh check | grep Run Running check dbvnet resource with return code 1

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

$ ./dbvagent_action.sh start | grep Run Running start dbvagent resource with return code 0 $ ./dbvagent_action.sh check | grep Run Running check dbvagent resource with return code 0 $ ./dbvagent_action.sh stop | grep Run Running stop dbvagent resource with return code 0 $ ./dbvagent_action.sh check | grep Run Running check dbvagent resource with return code 1

Again, you should get the exact output as displayed.

Now we can finally create resources for dbvnet and dbvagent. As root user execute:

# . oraenv ORACLE_SID = [root] ? +ASM1 # crsctl add resource dbvnet -type cluster_resource -attr "ACTION_SCRIPT=/dbvisit/scripts/dbvnet_action.sh, RESTART_ATTEMPTS=3, START_TIMEOUT=60, STOP_TIMEOUT=60, CHECK_INTERVAL=10,START_DEPENDENCIES='hard(dbvisit-vip2178) pullup(dbvisit-vip2178)',STOP_DEPENDENCIES='hard(dbvisit-vip2178)',ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--',PLACEMENT='favored',HOSTING_MEMBERS='czrlin0217 czrlin0218'" # crsctl add resource dbvagent -type cluster_resource -attr "ACTION_SCRIPT=/dbvisit/scripts/dbvagent_action.sh, RESTART_ATTEMPTS=3, START_TIMEOUT=60, STOP_TIMEOUT=60, CHECK_INTERVAL=10,START_DEPENDENCIES='hard(dbvisit-vip2178) pullup(dbvisit-vip2178)',STOP_DEPENDENCIES='hard(dbvisit-vip2178)',ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--',PLACEMENT='favored',HOSTING_MEMBERS='czrlin0217 czrlin0218'"

If you would like to add resource for dbvserver, the crsctl command is exactly the same (only change the name of the script)

As oracle user start resources and verify processes are started:

$ . oraenv ORACLE_SID = [SOLO] ? +ASM1 The Oracle base has been set to /u01/app/21.0.0/grid_base [oracle@czrlin0217 ~]$ crsctl start resource dbvnet CRS-2672: Attempting to start 'dbvnet' on 'czrlin0217' CRS-2676: Start of 'dbvnet' on 'czrlin0217' succeeded [oracle@czrlin0217 ~]$ crsctl start resource dbvagent CRS-2672: Attempting to start 'dbvagent' on 'czrlin0217' CRS-2676: Start of 'dbvagent' on 'czrlin0217' succeeded [oracle@czrlin0217 ~]$ ps -ef | grep dbv | grep -v grep oracle 868350 1 0 19:19 ? 00:00:00 ./dbvagent -d start oracle 871371 1 0 19:25 ? 00:00:00 ./dbvnet -d start

Test relocation of the VIP address back and forth:

$ crsctl relocate resource dbvisit-vip2178 -f CRS-2673: Attempting to stop 'dbvagent' on 'czrlin0217' CRS-2673: Attempting to stop 'dbvnet' on 'czrlin0217' CRS-2677: Stop of 'dbvagent' on 'czrlin0217' succeeded CRS-2679: Attempting to clean 'dbvagent' on 'czrlin0217' CRS-2677: Stop of 'dbvnet' on 'czrlin0217' succeeded CRS-2681: Clean of 'dbvagent' on 'czrlin0217' succeeded CRS-2673: Attempting to stop 'dbvisit-vip2178' on 'czrlin0217' CRS-2677: Stop of 'dbvisit-vip2178' on 'czrlin0217' succeeded CRS-2672: Attempting to start 'dbvisit-vip2178' on 'czrlin0218' CRS-2676: Start of 'dbvisit-vip2178' on 'czrlin0218' succeeded CRS-2672: Attempting to start 'dbvagent' on 'czrlin0218' CRS-2676: Start of 'dbvagent' on 'czrlin0218' succeeded CRS-2672: Attempting to start 'dbvnet' on 'czrlin0218' CRS-2676: Start of 'dbvnet' on 'czrlin0218' succeeded $ crsctl relocate resource dbvisit-vip2178 -f CRS-2673: Attempting to stop 'dbvagent' on 'czrlin0218' CRS-2673: Attempting to stop 'dbvnet' on 'czrlin0218' CRS-2677: Stop of 'dbvagent' on 'czrlin0218' succeeded CRS-2679: Attempting to clean 'dbvagent' on 'czrlin0218' CRS-2677: Stop of 'dbvnet' on 'czrlin0218' succeeded CRS-2681: Clean of 'dbvagent' on 'czrlin0218' succeeded CRS-2673: Attempting to stop 'dbvisit-vip2178' on 'czrlin0218' CRS-2677: Stop of 'dbvisit-vip2178' on 'czrlin0218' succeeded CRS-2672: Attempting to start 'dbvisit-vip2178' on 'czrlin0217' CRS-2676: Start of 'dbvisit-vip2178' on 'czrlin0217' succeeded CRS-2672: Attempting to start 'dbvagent' on 'czrlin0217' CRS-2676: Start of 'dbvagent' on 'czrlin0217' succeeded CRS-2672: Attempting to start 'dbvnet' on 'czrlin0217' CRS-2676: Start of 'dbvnet' on 'czrlin0217' succeeded

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:

. oraenv [+ASM1] appvipcfg create -network=1 -ip=192.168.8.13 -vipname=dbvisit-vip2223 -user=root crsctl setperm resource dbvisit-vip2223 -u user:oracle:r-x crsctl setperm resource dbvisit-vip2223 -u user:grid:r-x crsctl start resource dbvisit-vip2223 -n czrlin0222

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:

ssh dbvisit-vip2223 crsctl relocate resource dbvisit-vip2223 -f ssh dbvisit-vip2223 crsctl relocate resource dbvisit-vip2223 -f

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:

cd /dbvisit/app/standby ./dbvctl -o setup

Answer initial prompts and accept licence agreement:

=>dbvctl only needs to be run on the primary server. Is this the primary server? <Yes/No> [Yes]: [enter = accept default] The following Dbvisit Database configuration (DDC) file(s) found on this server: DDC === 1) Create New DDC 2) Cancel Please enter choice [] : 1 Is this correct? <Yes/No> [Yes]: [enter = accept default] Continue ? <Yes/No> [No]: yes

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

========================================================= Dbvisit Standby setup begins. ========================================================= The following Oracle instance(s) have been found on this server: SID ORACLE_HOME === =========== 1) SOLO /u02/app/oracle/product/21.0.0/dbhome_1 2) Enter own ORACLE_SID and ORACLE_HOME Please enter choice [] : 1 Is this correct? <Yes/No> [Yes]: [enter = accept default] =>ORACLE_SID will be: SOLO =>ORACLE_HOME will be: /u02/app/oracle/product/21.0.0/dbhome_1 Next is the source hostname, in this case we need to use the VIP which we already created when preparing the environment: =>SOURCE is []: dbvisit-vip2178 Your input: dbvisit-vip2178 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is dbvisit-vip2178

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

Archsource is Dbvisit archivelog temporary staging directory which must be never set to any database-related directory (like FRA etc ..). This directory also must not contain any subdirectories, not even lost+found. On primary server this directory won’t contain any permanent files.

=>ARCHSOURCE is [/u01/app/oracle/dbvisit_arch/SOLO]: /dbvisit/dbvisit_arch/SOLO Your input: /dbvisit/dbvisit_arch/SOLO Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is /dbvisit/dbvisit_arch/SOLO

 in this example we chosen location on shared drive as ARCHSOURCE. If you choose local directory, you must ensure this directory exists also no 2nd SEHA node

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

------------------------------------------------------------------------------ Enter primary node 1. =>RAC1_HOST is [czrlin0217]: [enter = accept default] Your input: czrlin0217 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is czrlin0217 ------------------------------------------------------------------------------ Enter primary ASM instance for node czrlin0217. Leave null for ACFS =>RAC1_SID_ASM is [+ASM1]: [enter = accept default] Your input: +ASM1 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is +ASM1 ------------------------------------------------------------------------------ Enter primary node 2. =>RAC2_HOST is [czrlin0218]: [enter = accept default] Your input: czrlin0218 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is czrlin0218 ------------------------------------------------------------------------------ Enter primary ASM instance for node czrlin0218. Leave null for ACFS =>RAC2_SID_ASM is []: +ASM2 Your input: +ASM2 Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is +ASM2

If your primary database is using ACFS storage, don’t fill in any ASM details, simply leave empty

You need to enter node names EXACTLY as they are stored in Clusterware Registry (OCR). Don’t use IP addresses. For example run as grid “crsctl check cluster -all” to see node names

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.

=>USE_SSH is [N]: [enter = accept default] Your input: N Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is N ------------------------------------------------------------------------------ Specify the DBVNET or SSH port number on the primary server. The default value supplied is the dbvnet port 7890. If you specified the use of SSH, please specify the SSH port here. =>NETPORT is [7890]: [enter = accept default] Your input: 7890 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is 7890

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.

=>DESTINATION is []: dbvisit-vip2223 Your input: dbvisit-vip2223 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is dbvisit-vip2223 ------------------------------------------------------------------------------ Specify the DBVNET or SSH port number on the standby server. The default value supplied is the dbvnet port 7890. If you specified the use of SSH, please specify the SSH port here. =>NETPORT_DR is [7890]: [enter = accept default] Your input: 7890 Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is 7890 We need to enter the configuration details of second SEHA cluster. Enter Dbvisit Standby installation directory on the standby server =>DBVISIT_BASE_DR is [/dbvisit/app]: [enter = accept default] Your input: /dbvisit/app Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is /dbvisit/app ------------------------------------------------------------------------------ Enter ORACLE_HOME directory on the standby server =>ORACLE_HOME_DR is [/u02/app/oracle/product/21.0.0/dbhome_1]: [enter = accept default] Your input: /u02/app/oracle/product/21.0.0/dbhome_1 Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is /u02/app/oracle/product/21.0.0/dbhome_1 ------------------------------------------------------------------------------ Enter DB_UNIQUE_NAME on the standby server =>DB_UNIQUE_NAME_DR is [SOLO]:[enter = accept default] Your input: SOLO Is this correct? <Yes/No> [Yes]: Choice is SOLO

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

Enter Dbvisit Standby installation directory on the standby server =>DBVISIT_BASE_DR is [/dbvisit/app]: [enter = accept default] Your input: /dbvisit/app Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is /dbvisit/app ------------------------------------------------------------------------------ Enter ORACLE_HOME directory on the standby server =>ORACLE_HOME_DR is [/u02/app/oracle/product/21.0.0/dbhome_1]: [enter = accept default] Your input: /u02/app/oracle/product/21.0.0/dbhome_1 Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is /u02/app/oracle/product/21.0.0/dbhome_1 ------------------------------------------------------------------------------ Enter DB_UNIQUE_NAME on the standby server =>DB_UNIQUE_NAME_DR is [SOLO]:[enter = accept default] Your input: SOLO Is this correct? <Yes/No> [Yes]: Choice is SOLO

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:

------------------------------------------------------------------------------ Will the standby database be a SEHA database? =>RAC_DR is [N]:Y Is this correct? <Yes/No> [Yes]: [enter = accept default] Choice is Y

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.

=>ARCHDEST is [/dbvisit/dbvisit_arch/SOLO]:[enter = accept default] Your input: /dbvisit/dbvisit_arch/SOLO Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is /dbvisit/dbvisit_arch/SOLO ------------------------------------------------------------------------------ Enter ORACLE_SID on the standby server =>ORACLE_SID_DR is [SOLO]:[enter = accept default] Your input: SOLO Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is SOLO

Similar to Archsource: Archdest is Dbvisit archivelog directory which must be never set to any database-related directory (like FRA etc ..). This directory also must not contain any subdirectories, not even lost+found. On standby server this directory will contain all archivelogs. After database role change Archdest directory will become Archsource and vice versa.

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

------------------------------------------------------------------------------ Enter standby host name 1 =>RAC1_HOST_DR is []: czrlin0222 Your input: czrlin0222 Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is czrlin0222 ------------------------------------------------------------------------------ Enter standby ASM instance on host 1. Leave empty for ACFS =>RAC1_SID_ASM_DR is []:[enter = accept default] Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is null =>RAC2_HOST_DR is []: czrlin0223 Your input: czrlin0223 Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is czrlin0223 ------------------------------------------------------------------------------ Enter standby ASM instance on host 2. Leave empty for ACFS =>RAC2_SID_ASM_DR is []:[enter = accept default] Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is null The very last choice is to name our DDC, we’ll go with default and we will not yet enter any licence key: =>ENV_FILE is [SOLO]:[enter = accept default] Your input: SOLO Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is SOLO ------------------------------------------------------------------------------ Provide license key. =>LICENSE_KEY is []:[enter = accept default] Is this correct? <Yes/No> [Yes]:[enter = accept default] Choice is null

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:

Below are the list of configuration variables provided during the setup process: Configuration Variable Value Provided ====================== ============== ORACLE_SID SOLO ORACLE_HOME /u02/app/oracle/product/21.0.0/dbhome_1 SOURCE dbvisit-vip2178 ARCHSOURCE /dbvisit/dbvisit_arch/SOLO RAC1_THREAD 1 RAC1_HOST czrlin0217 RAC1_SID SOLO RAC1_SID_ASM +ASM1 RAC2_THREAD 1 RAC2_HOST czrlin0218 RAC2_SID SOLO RAC2_SID_ASM +ASM2 USE_SSH N NETPORT 7890 DESTINATION dbvisit-vip2223 NETPORT_DR 7890 DBVISIT_BASE_DR /dbvisit/app ORACLE_HOME_DR /u02/app/oracle/product/21.0.0/dbhome_1 DB_UNIQUE_NAME_DR SOLO RAC_DR Y ARCHDEST /dbvisit/dbvisit_arch/SOLO ORACLE_SID_DR SOLO RAC1_HOST_DR czrlin0222 RAC2_HOST_DR czrlin0223 ENV_FILE SOLO Are these variables correct? <Yes/No> [Yes]:[enter = accept default]

DDC file is now created.

If you would like to use DDC file created by CLI in dbvserver GUI, you have to import it first. Go to “Manage Configurations” and select “Import”

5.  Creating Dbvisit Database Configuration (DDC) with GUI

In our example we use dbvserver on standby SEHA cluster czrlin0222 and czrlin0223. We didn’t cover installation of dbvserver in this page. You can install dbvserver also there or on any other machine separated from SEHA clusters. For more information on how to install dbvserver refer to: Installing Dbvisit Standby

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)

Step 2:   Add a new host

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

Archsource is Dbvisit archivelog temporary staging directory which must be never set to any database-related directory (like FRA etc ..). This directory also must not contain any subdirectories, not even lost+found. On primary server this directory won’t contain any permanent files.

If your primary database is using ACFS storage, don’t fill in any ASM details, simply leave empty

You need to enter node names EXACTLY as they are stored in Clusterware Registry (OCR). Don’t use IP addresses. For example run as grid “crsctl check cluster -all” to see node names


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.

If wish to create standby database on ACFS storage, don’t fill in any ASM details, simply leave empty

Similar to Archsource: Archdest is Dbvisit archivelog directory which must be never set to any database-related directory (like FRA etc ..). This directory also must not contain any subdirectories, not even lost+found. On standby server this directory will contain all archivelogs. After database role change Archdest directory will become Archsource and vice versa.

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:

$ srvctl config database -d SOLO Database unique name: SOLO Database name: Oracle home: /u02/app/oracle/product/21.0.0/dbhome_1 Oracle user: oracle Spfile: +DATA/SOLO/parameterfile/spfilesolo.ora Password file: +DATA/SOLO/password/orapwSOLO Domain: Start options: mount Stop options: abort Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: DATA,RECO Mount point paths: /u02 Services: Type: SINGLE OSDBA group: dba OSOPER group: oper Database instance: SOLO Configured nodes: czrlin0222,czrlin0223 CSS critical: no CPU count: 0 Memory target: 0 Maximum memory: 0 Default network number for database services: Database is administrator managed

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

 

Related content