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 (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).
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.
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 be able 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 instance A and B run on SEHA node 1 and database instance C runs on node 2. Such deployment is currently NOT supported by Dbvisit Standby. Dbvisit Standby can be active only on one of the SEHA cluster nodes, not on both.
Currently, SEHA is supported only for Linux environments. |
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:
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.
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.
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.
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 Standby Multiplatform
In this example we’ll be aiming for Dbvisit configuration as follows:
Nodes | Associated VIP (active only on one SEHA node) | Installed Dbvisit component |
|---|---|---|
czrlin0217, czrlin0218 | dbvisit-vip2178 | Dbvagentmanager |
czrlin0222, czrlin0223 | dbvisit-vip2223 | Dbvagentmanager, Dbvcontrol |
We will first start on primary SEHA cluster. We need first to create directory which will contain Dbvisit installation DBVISIT_BASE:
mkdir /dbvisit/app |
Continue by starting the dbvagentmanager installer and specifying this directory as DBVISIT_BASE:
$ ./install-agent-v11.1.0
Welcome to Dbvisit StandbyMP setup version v11.1.0.
? Please carefully read the end-user license agreement at https://dbvisit.com/eula. Do you agree to the terms of this agreement? Yes
? Which directory should the software be installed into? /dbvisit/app
- - - You are now configuring the Dbvisit StandbyMP Agent - - -
The Agent will listen on the following discovered addresses:
- 127.0.0.1
- 10.0.2.15
- 192.168.8.12
- 192.168.8.217
- 192.168.8.220
- 192.168.8.219
- 192.168.200.21
- 169.254.20.72
? Agent File Transfer Port: 7890
? Fully Qualified Domain Name for this host: dbvisit-vip2178
? Fully Qualified Domain Name for the Control Center: dbvisit-vip2223
? Agent Communications Port: 5533
Each Dbvisit StandbyMP Agent and the Dbvisit StandbyMP Control Center must
be configured with the same passphrase. This is how we know that they are all
intended to be part of the same system. Please specify a strong passphrase - we
suggest at least 12 characters, containing at least 2 numbers and 2 symbols.
? Passphrase: ********
? Confirm Passphrase: *********
- - - Dbvisit StandbyMP Agent configuration finished - - -
- - - Ready to perform installation - - -
? Do you wish to proceed with the setup using the supplied configuration options? Proceed with setup
- - - Performing installation - - -
Copying software files to '/dbvisit/app'...
Writing Agent configuration file '/dbvisit/app/standbymp/conf/dbvagentmanager.ini'...
- - - Installation successful! - - -
To enable the installed Dbvisit StandbyMP components to run as system services, you will need to execute some commands as the "root" user in order to complete the setup.
To install the system service(s), you can run, substituting the name of the user to run as if it is different from the current user:
sudo /dbvisit/app/standbymp/bin/dbvagentmanager service install --user oracle
To start the system service(s), you can run:
sudo /dbvisit/app/standbymp/bin/dbvagentmanager service start
- - - Configuration Summary - - -
Install Directory: /dbvisit/app
Fully Qualified Domain Name for this host: dbvisit-vip2178
Fully Qualified Domain Name for the Control Center: dbvisit-vip2223
Agent Communications Port: 5533
Agent File Transfer Port: 7890
- - - Installation Summary - - -
The following actions have been performed:
- Installed Dbvisit StandbyMP Agent software into: /dbvisit/app/standbymp
- Agent settings are available in the configuration file: /dbvisit/app/standbymp/conf/dbvagentmanager.ini
- Generated new security certificates in: /dbvisit/app/standbymp/certificates
- - - INSTALLATION SUCCESSFUL - - - |
Do not create systemctl service. There’s no dbvcontrol component on this SEHA cluster - installation of the product on primary cluster is hence finished.
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:
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:
cd /dbvisit/app/standbymp/bin chmod +x dbvcrs.sh |
Do NOT change the script name nor script location. If you do, you will have to make on your own adjustments in the script and in the cluster commands. |
You need to check that the scripts are working properly. For checking run:
$ ./dbvcrs.sh start dbvagentmanager Starting Dbvisit dbvagentmanager Submitted check for dbvagentmanager with result running correctly, return 0 $ ./dbvcrs.sh check dbvagentmanager Submitted check for dbvagentmanager with result running correctly, return 0 $ ./dbvcrs.sh stop dbvagentmanager $ ./dbvcrs.sh check dbvagentmanager Submitted check for dbvagentmanager with result not running correctly, return 1 $ ./dbvcrs.sh start dbvagentmanager Starting Dbvisit dbvagentmanager Submitted check for dbvagentmanager with result running correctly, return 0 $ ./dbvcrs.sh clean dbvagentmanager $ ./dbvcrs.sh check dbvagentmanager Submitted check for dbvagentmanager with result not running correctly, return 1 |
You should get the exact output as displayed.
Now we can finally create resource for dbvagentmanager. As root user execute:
# . oraenv ORACLE_SID = [root] ? +ASM1 # crsctl add resource dbvagentmanager -type generic_application -attr "START_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh start dbvagentmanager',STOP_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh stop dbvagentmanager',CHECK_PROGRAMS='/dbvisit/app/standbymp/bin/dbvcrs.sh check dbvagentmanager',CLEAN_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh clean dbvagentmanager', CHECK_INTERVAL=10,START_DEPENDENCIES='hard(dbvisit-vip2178) pullup(dbvisit-vip2178) attraction(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 $ crsctl start resource dbvagentmanager CRS-2672: Attempting to start 'dbvagentmanager' on 'czrlin0217' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0217' succeeded $ ps -ef | grep dbv oracle 775722 1 2 15:25 pts/1 00:00:00 /dbvisit/app/standbymp/bin/dbvagentmanager service run oracle 775736 775722 1 15:25 pts/1 00:00:00 /dbvisit/app/standbymp/bin/dbvhelper -agentManagerId 3mjle6nxu8vau -directorId 2hsc7yqop5ora -hostAddress dbvisit-vip2178 -natsAddress dbvisit-vip2223 -natsPort 5533 -configurationType Oracle -helperProcessKey oracle:3mjle6nxu8vau oracle 775772 715926 0 15:25 pts/1 00:00:00 grep --color=auto dbv |
Test relocation of the VIP address back and forth:
$ crsctl relocate resource dbvisit-vip2178 -f CRS-2673: Attempting to stop 'dbvagentmanager' on 'czrlin0217' CRS-2677: Stop of 'dbvagentmanager' 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 'dbvagentmanager' on 'czrlin0218' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0218' succeeded $ crsctl relocate resource dbvisit-vip2178 -f CRS-2673: Attempting to stop 'dbvagentmanager' on 'czrlin0218' CRS-2677: Stop of 'dbvagentmanager' 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 'dbvagentmanager' on 'czrlin0217' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0217' succeeded |
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
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.
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:
$ ./install-agent-v11.1.0
Welcome to Dbvisit StandbyMP setup version v11.1
? Please carefully read the end-user license agreement at https://dbvisit.com/eula. Do you agree to the terms of this agreement? Yes
? Which directory should the software be installed into? /dbvisit/app
- - - You are now configuring the Dbvisit StandbyMP Agent - - -
The Agent will listen on the following discovered addresses:
- 127.0.0.1
- 10.0.2.15
- 192.168.8.222
- 192.168.8.225
- 192.168.8.224
- 192.168.8.13
- 192.168.200.23
- 169.254.17.228
? Agent File Transfer Port: 7890
? Fully Qualified Domain Name for this host: dbvisit-vip2223
? Fully Qualified Domain Name for the Control Center: dbvisit-vip2223
? Agent Communications Port: 5533
Each Dbvisit StandbyMP Agent and the Dbvisit StandbyMP Control Center must
be configured with the same passphrase. This is how we know that they are all
intended to be part of the same system. Please specify a strong passphrase - we
suggest at least 12 characters, containing at least 2 numbers and 2 symbols.
? Passphrase: ********
? Confirm Passphrase: ********
- - - Dbvisit StandbyMP Agent configuration finished - - -
- - - Ready to perform installation - - -
? Do you wish to proceed with the setup using the supplied configuration options? Proceed with setup
- - - Performing installation - - -
Copying software files to '/dbvisit/app'...
Writing Agent configuration file '/dbvisit/app/standbymp/conf/dbvagentmanager.ini'...
- - - Installation successful! - - -
To enable the installed Dbvisit StandbyMP components to run as system services, you will need to execute some commands as the "root" user in order to complete the setup.
To install the system service(s), you can run, substituting the name of the user to run as if it is different from the current user:
sudo /dbvisit/app/standbymp/bin/dbvagentmanager service install --user oracle
To start the system service(s), you can run:
sudo /dbvisit/app/standbymp/bin/dbvagentmanager service start
- - - Configuration Summary - - -
Install Directory: /dbvisit/app
Fully Qualified Domain Name for this host: dbvisit-vip2223
Fully Qualified Domain Name for the Control Center: dbvisit-vip2223
Agent Communications Port: 5533
Agent File Transfer Port: 7890
- - - Installation Summary - - -
The following actions have been performed:
- Installed Dbvisit StandbyMP Agent software into: /dbvisit/app/standbymp
- Agent settings are available in the configuration file: /dbvisit/app/standbymp/conf/dbvagentmanager.ini
- Generated new security certificates in: /dbvisit/app/standbymp/certificates
- - - INSTALLATION SUCCESSFUL - - -
|
Do not create systemctl service. Afterwards, install dbvcontrol:
$ ./install-control-v11.1.0
Welcome to Dbvisit StandbyMP setup version v11.1.0
? Please carefully read the end-user license agreement at https://dbvisit.com/eula. Do you agree to the terms of this agreement? Yes
? Which directory should the software be installed into? /dbvisit/app
- - - You are now configuring the Dbvisit StandbyMP Control Center - - -
The Control Center will listen on the following discovered addresses:
- 127.0.0.1
- 10.0.2.15
- 192.168.8.222
- 192.168.8.225
- 192.168.8.224
- 192.168.8.13
- 192.168.200.23
- 169.254.17.228
? Control Center Web Server Port: 4433
? Agent Communications Port: 5533
Each Dbvisit StandbyMP Agent and the Dbvisit StandbyMP Control Center must
be configured with the same passphrase. This is how we know that they are all
intended to be part of the same system. Please specify a strong passphrase - we
suggest at least 12 characters, containing at least 2 numbers and 2 symbols.
? Passphrase: ********
? Confirm Passphrase: ********
- - - Dbvisit StandbyMP Control Center configuration finished - - -
- - - Ready to perform installation - - -
? Do you wish to proceed with the setup using the supplied configuration options? Proceed with setup
- - - Performing installation - - -
Copying software files to '/dbvisit/app'...
Writing Control Center configuration file '/dbvisit/app/standbymp/conf/dbvcontrol.ini'...
- - - Installation successful! - - -
To enable the installed Dbvisit StandbyMP components to run as system services, you will need to execute some commands as the "root" user in order to complete the setup.
To install the system service(s), you can run, substituting the name of the user to run as if it is different from the current user:
sudo /dbvisit/app/standbymp/bin/dbvcontrol service install --user oracle
To start the system service(s), you can run:
sudo /dbvisit/app/standbymp/bin/dbvcontrol service start
- - - Configuration Summary - - -
Install Directory: /dbvisit/app
Control Center Web Server Port: 4433
Agent Communications Port: 5533
- - - Installation Summary - - -
The following actions have been performed:
- Installed Dbvisit StandbyMP Control Center software into: /dbvisit/app/standbymp
- Control Center settings are available in the configuration file: /dbvisit/app/standbymp/conf/dbvcontrol.ini
- Generated new security certificates in: /dbvisit/app/standbymp/certificates
- - - INSTALLATION SUCCESSFUL - - - |
Do not create systemctl service. We have installed both components on standby cluster, installation of the product is hence finished.
Upload the action script from primary cluster from to directory /dbvisit/app/standbymp/bin and set correct privileges:
cd /dbvisit/app/standbymp/bin chmod +x dbvcrs.sh |
Do NOT change the script name nor script location. If you do, you will have to make on your own adjustments in the script and in the cluster commands. |
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:
# . oraenv ORACLE_SID = [root] ? +ASM1 # crsctl add resource dbvagentmanager -type generic_application -attr "START_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh start dbvagentmanager',STOP_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh stop dbvagentmanager',CHECK_PROGRAMS='/dbvisit/app/standbymp/bin/dbvcrs.sh check dbvagentmanager',CLEAN_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh clean dbvagentmanager', CHECK_INTERVAL=10,START_DEPENDENCIES='hard(dbvisit-vip2223) pullup(dbvisit-vip2223) attraction(dbvisit-vip2223)',STOP_DEPENDENCIES='hard(dbvisit-vip2223)',ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--',PLACEMENT='favored',HOSTING_MEMBERS='czrlin0222 czrlin0223'" # crsctl add resource dbvcontrol -type generic_application -attr "START_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh start dbvcontrol',STOP_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh stop dbvcontrol',CHECK_PROGRAMS='/dbvisit/app/standbymp/bin/dbvcrs.sh check dbvcontrol',CLEAN_PROGRAM='/dbvisit/app/standbymp/bin/dbvcrs.sh clean dbvcontrol', CHECK_INTERVAL=10,START_DEPENDENCIES='hard(dbvisit-vip2223) pullup(dbvisit-vip2223) attraction(dbvisit-vip2223)',STOP_DEPENDENCIES='hard(dbvisit-vip2223)',ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--',PLACEMENT='favored',HOSTING_MEMBERS='czrlin0222 czrlin0223'" |
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 $ crsctl start resource dbvagentmanager CRS-2672: Attempting to start 'dbvagentmanager' on 'czrlin0222' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0222' succeeded $ crsctl start resource dbvcontrol CRS-2672: Attempting to start 'dbvcontrol' on 'czrlin0222' CRS-2676: Start of 'dbvcontrol' on 'czrlin0222' succeeded $ ps -ef | grep dbv oracle 3298903 1 1 16:58 ? 00:00:00 /dbvisit/app/standbymp/bin/dbvagentmanager service run oracle 3299218 1 28 16:58 ? 00:00:01 /dbvisit/app/standbymp/bin/dbvcontrol service run oracle 3299257 3298903 3 16:58 ? 00:00:00 /dbvisit/app/standbymp/bin/dbvhelper -agentManagerId 20wbe93nuve76 -directorId 1uxzm2u9rxt5o -hostAddress dbvisit-vip2223 -natsAddress dbvisit-vip2223 -natsPort 5533 -configurationType Oracle -helperProcessKey oracle:20wbe93nuve76 oracle 3299296 3297547 0 16:58 pts/1 00:00:00 grep --color=auto dbv |
Test relocation of the VIP address back and forth:
$ crsctl relocate resource dbvisit-vip2223 -f CRS-2673: Attempting to stop 'dbvagentmanager' on 'czrlin0222' CRS-2673: Attempting to stop 'dbvcontrol' on 'czrlin0222' CRS-2677: Stop of 'dbvagentmanager' on 'czrlin0222' succeeded CRS-2677: Stop of 'dbvcontrol' on 'czrlin0222' succeeded CRS-2673: Attempting to stop 'dbvisit-vip2223' on 'czrlin0222' CRS-2677: Stop of 'dbvisit-vip2223' on 'czrlin0222' succeeded CRS-2672: Attempting to start 'dbvisit-vip2223' on 'czrlin0223' CRS-2676: Start of 'dbvisit-vip2223' on 'czrlin0223' succeeded CRS-2672: Attempting to start 'dbvagentmanager' on 'czrlin0223' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0223' succeeded CRS-2672: Attempting to start 'dbvcontrol' on 'czrlin0223' CRS-2676: Start of 'dbvcontrol' on 'czrlin0223' succeeded $ crsctl relocate resource dbvisit-vip2223 -f CRS-2673: Attempting to stop 'dbvagentmanager' on 'czrlin0223' CRS-2673: Attempting to stop 'dbvcontrol' on 'czrlin0223' CRS-2677: Stop of 'dbvagentmanager' on 'czrlin0223' succeeded CRS-2677: Stop of 'dbvcontrol' on 'czrlin0223' succeeded CRS-2673: Attempting to stop 'dbvisit-vip2223' on 'czrlin0223' CRS-2677: Stop of 'dbvisit-vip2223' on 'czrlin0223' succeeded CRS-2672: Attempting to start 'dbvisit-vip2223' on 'czrlin0222' CRS-2676: Start of 'dbvisit-vip2223' on 'czrlin0222' succeeded CRS-2672: Attempting to start 'dbvagentmanager' on 'czrlin0222' CRS-2676: Start of 'dbvagentmanager' on 'czrlin0222' succeeded CRS-2672: Attempting to start 'dbvcontrol' on 'czrlin0222' CRS-2676: Start of 'dbvcontrol' on 'czrlin0222' succeeded |
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
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/standbymp/oracle ./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.
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 |
------------------------------------------------------------------------------ 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 |
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.
DDC file create on CLI must be imported in Control Center first before proceding with Standby Database Creation |
In our example we use Dbvcontrol Center on standby SEHA cluster czrlin0222 and czrlin0223. You can install Dbvcontrol Center there or on any other machine separated from SEHA clusters. |
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-vip2178 from the discovered host list.
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
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 |
Step 6: Fill in the below-required details
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
Review and update the Oracle SID. In this example, we are going to keep same as primary
Review the Oracle Database Home on the Standby server
Review and update the DB Unique Name (db_unique_name) of the standby if required - default value recommended
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.
Review and update the Dbvisit Base location on the Standby server if different
Specify the Dbvisit Standby Configuration (DDC) name
Provide the license key for the configuration.
Create New Configuration
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. |
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:
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:
Primary Server: dbvisit-vip2178
Standby Server dbvisit-vip2223
Please refer the below link for the pre-requisites steps to be performed before switchover.
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
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.