Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

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

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.

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'"

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.

4.  Using the Central Console

4.1. Adding hosts and DDC file creation

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 host details - 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 moves between them.

Step 4:  Add dbvisit-vip2223 host


Step 5:  Review hosts

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

4.2.  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 DEV --csd"

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

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


Step 2.1:  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 2.2: 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.


4.3 Send logs from Primary to Standby

Navigate to Database actions, click on send log button

Apply Archive logs to Standby database




































  • No labels