A while ago I made a promise to take a look at the product Dbvisit, found out this is not the product, but just the firm Dbvisit. The product I’m about to install is called officially ‘Dbvisit Standby‘. There’s also a product called ‘Dbvisit replicate’.
I didn’t really know about the product, not related to it, but it was buzzing around that it’s a cheap and a well working alternative for a high available environment with Oracle Standard Edition in stead of the Enterprise Edition with Data Guard.
So my first project (this post) is just to install a lab environment and get it working. The second project should be the real thing, testing the availability and the easiness of administration and monitoring.

What will I do for this part of the project (working from scratch with the latest versions – at the time of writing – of Oracle Linux and VirtualBox…):

1. Create two VM’s (VirtualBox with Oracle Linux 6)
2. Install Dbvisit Standby
3. Configure Dbvisit Standby
4. Get it going!

And not surprisingly, the preparation took most of the time:

1. Creating two VM’s (named SE1 and SE2) with VirtualBox

 

Creating one VM with Oracle Standard Edition 11.2.0.3 software and a running database
And Creating the other one just with the Oracle Standard Edition 11.2.0.3 software on it, and no database.

I’ve got a Windows 7 computer as host, and will use Virtualbox 4.2.8. As working from scratch, I will mention the steps to do this, while some things did not went that smoothly as I hoped (when does it ever do…).

– Download / install Virtual Box and the extension pack (two downloads!) : https://www.virtualbox.org/wiki/Downloads
– Download Oracle Linux 6 : https://edelivery.oracle.com/linux (have to sign in)
Version: Oracle Linux Release 6 Update 3 Media Pack v2 for x86_64 (64 bit) –> 3,5 GB
– Install Linux, used : http://www.oracle-base.com/articles/11g/oracle-db-11gr2-installation-on-oracle-linux-6.php
Don’t forget to assign an ip-adress to your Linux, and make a connection to the internet.
– Setting up yum:
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol6.repo

# yum install oracle-rdbms-server-11gR2-preinstall  –> Aahhhh…. a problem I never ran in to:

Another app is currently holding the yum lock; waiting for it to exit…

That other application is: PackageKit .

In /etc/yum/pluginconf.d/refresh-packagekit.conf you can disable the refresh of PackageKit that happens after every yum invocation that actually does something.  For now, just killed the service after this disabling. Have to wait for a minute or so, than it’s gone.

– Then use the pre-configured oracle-package:  # yum install oracle-rdbms-server-11gR2-preinstall
– Edit /etc/hosts : # vi /etc/hosts (filled in ip-adress and name)
– Install vbox-additions (4.2.8-83876), restart service ‘haldaemon’.
– Disable secure linux by editing the “/etc/selinux/config” file, making sure the SELINUX flag is set as follows: SELINUX=disabled
– Create the directories in which the Oracle software will be installed.
mkdir -p /u01/app/oracle/product/11.2.0/db_1
chown -R oracle:oinstall /u01
chmod -R 775 /u01
– Login as the oracle user and add the following lines at the end of the “.bash_profile” file.

# Oracle Settings
TMP=/tmp; export TMP
TMPDIR=$TMP; export TMPDIR
ORACLE_HOSTNAME=SE1.jobacle.nl; export ORACLE_HOSTNAME
ORACLE_UNQNAME=SE; export ORACLE_UNQNAME
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1; export ORACLE_HOME
ORACLE_SID=SE; export ORACLE_SID
PATH=/usr/sbin:$PATH; export PATH
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH

– Download 11.2.0.3: https://updates.oracle.com/download/10404530.html (have to sign in My Oracle Support)
– Install the Oracle Software.
– Clone SE1 to SE2 with VirtualBox.
– After cloning, give SE2 another IP-address and change hostname:

Changing ip-address:
find the macaddress and the network that’s active: ifconfig -a |grep eth
edit /etc/sysconfig/network_script/ifcfg-eth2 : change IPADDR and HWADDR with the values found above.
restart network through “/etc/init.d/network restart”
Changing hostname:
edit /etc/sysconfig/network. Change HOSTNAME.  reboot

– Create database SE on node SE1.
– As an Oracle user configure user equivalence by isuing the following sequence of commands. Generate keys on both servers.

# Accept all defaults for the following.
ssh-keygen
cd $HOME/.ssh
Copy the keys between servers.
# Run on Primary only: in this case SE1.
scp oracle@SE2:/home/oracle/.ssh/id_rsa.pub /home/oracle/.ssh/authorized_keys
# Run on Standby only: in this case SE2.
scp oracle@SE11:/home/oracle/.ssh/id_rsa.pub /home/oracle/.ssh/authorized_keys
Check this by ‘ssh SE1 ls -al’. check /var/log/secure when you’re having problems.

And.. I did have a problem.. it didn’t work, some permission-problems…
A simple ‘chmod g-w /home/oracle‘ did the trick for me.

Other solutions /checks when it does not work:
chmod 700 .ssh
cd .ssh
chmod 600 *
chmod 644 authorized_keys
chmod 644 known_hosts
chmod 644 config
restorecon -R -v ../.ssh

Now we should be ready to install Dbvisit….

2. Install Dbvisit

However it’s possible to use a GUI to setup Dbvisit, the line-mode will be used in this post. All from the user Oracle.

Just a little bit more preparation on node SE1:

Create directories to hold logs and archive files on both servers.

mkdir /u01/app/oracle/dbvisit
chown oracle:oinstall /u01/app/oracle/dbvisit

mkdir -p /u01/app/oracle/admin/SE/dbvisit
mkdir -p /u01/oracle/oraarch/SE

On the standby server SE2, set up the directories necessary to run the standby database. This is essentially any paths reverenced in the spfile of the primary database.

mkdir -p /u01/app/oracle/admin/SE/adump
mkdir -p /u01/app/oracle/data/SE
mkdir -p /u01/app/oracle/fast_recovey_area/SE
mkdir -p /u01/app/oracle/diag/rdbms/prod/SE/trace
mkdir -p /u01/app/oracle/diag/rdbms/prod/SE/cdump

Download dbvisit : http://www.dbvisit.com/products/downloads (registration required)
Version: 6.0.44 (26 feb 2013)
Size: 33 MB

Unzip and install the Dbvisit Standby software on both servers. Something like this:

cd /host/software/oracle/dbvisit
unzip -d /usr/local dbvisit-standby6.0.16_linux.zip
cd /usr/local
tar -xvf dbvisit-standby6.0.16.tar
cd dbvisit
chmod 750 dbvisit_install
# Accept all defaults for the following (maybe ‘No’ to ‘Turn on automatic email to Dbvisit support’ :-)
./dbvisit_install

Now we’ve installed dbvisit.

3. Configuring Dbvisit Standby

Run the following command on node SE1:

/usr/local/dbvisit/standby/dbvisit_setup
log-file: dbvisit_install.log – in the same directory
trace-file: <pid>_dbvisit_install_<yyyymmddhh24mi>.trc

Choose Option 1: New Dbvisit Database setup

Then: a lot of questions, nevertheless well documented.. (don’t know yet if it’s possible to do a silent install).

Chose for ‘quick setup’ (a lot of questions still..). All your answers will be saved in a so-called DDC file, and default it is named dbv_<oracle_sid>.env. It is a kind of init.ora file for dbvisit.

The question of what tablespace: USERS (when you forgot to create a seperate tablespace like I did, create it in another session and ‘refresh list’)

Option 7: Create Standby Database (and template)

And there it goes.. ahhhh, almost:

Fault: Problem with calculating checksum for /var/temp/dbvisit/standby/dbv_functions: Permission Denied
… Return code = 126

Solution (in my case): chmod 775 on directory standby on node SE2.
Cause:  undoubtedly will be an inheretence problem or something like that, or sloppiness of me.

Option 7 again

And there it goes….

It works! By copying the database files and update parameter-files the standby database will be created.

Something to take in mind when you’ve got a very busy server:
– The instance on SE1 is not going down, but it goes in backup-mode in the old-fashioned way, per tablespace:
Alter tablespace XXX begin backup
copy the datafile to SE2
Alter tablespace XXX end backup … and so on.

Once complete, run the following command on each server to make sure they are in sync.

/usr/local/dbvisit/standby/dbvisit SE

This wil make use of the service ‘dbvserverd’.

On SE2: manually fill in /etc/oratab, it’s left empty. Choose ‘N’ as automatic startup – option.

To configure the service to start automatically on server startup, simply copy the sample script provided in the software directory using the following commands, issued as the “root” user.

But… Don’t forget to check the script dbvserverd if the path of DBVISIT is correct (almost forgot)!!
cp /usr/local/dbvisit/dbvserver/etc/init.d/redhat/dbvserverd /etc/init.d
chkconfig –add dbvserverd

In addition to start automatically on server startup, the service can be manually stopped and started with the following commands issued by the “root” user.

service dbvserverd stop
service dbvserverd start

4. Get it going

And then you have to schedule Dbvisit, and I will guote the documentation here, which will give a pretty good idea of the concept of Dbvisit Standby:

Archived redo logs are transported from the primary to the standby server when the dbvisit command is called.
So this must be scheduled on the both the primary and standby servers.
The frequency you choose depends on a number of factors including server and network load etc.
If you want to transfer the files every 10 minutes you might use the following schedule in the crontab for the “oracle” user on the primary server.

 

00,10,20,30,40,50 * * * * /usr/local/dbvisit/standby/dbvisit SE >>/dev/null 2>&1

 

 

You need to configure the same call on the standby server, but it makes sense to run it a little later to allow for time it takes to ship the logs.

 

05,15,25,35,45,55 * * * * /usr/local/dbvisit/standby/dbvisit SE >>/dev/null 2>&1

 

 

The dbv_oraStartStop command is used to stop, start or restart the primary or standby database on the relevant server.

 

$ /usr/local/dbvisit/standby/dbv_oraStartStop stop SE
$ /usr/local/dbvisit/standby/dbv_oraStartStop start SE
$ /usr/local/dbvisit/standby/dbv_oraStartStop restart SE

 

 

It is also used to check the status of the database.

 

$ /usr/local/dbvisit/standby/dbv_oraStartStop status SE

So the concept is just shipping redo logs on a particular time, and catch them on the other side, quite a  straightforward approach. Which is not bad, this kind of software will be bought to get the most out of the availability of your Oracle Standard Edition database for a low price. But don’t forget that you have to pay licenses for the standby database. So it should be a win-win-win situation: Oracle is selling more (cheap) Standard Editon licenses, Dbvisit is selling some (cheap) licenses with his product, and, most importatnt, the customer gets a high available environment which is quite easy to install and transparent. I’m still curious about the process of releasing / bugfixing and the certification against Oracle- / O.S – versions. Next time…

For now, this is all. Next post I’ll try to do more fun things. Failover, network-failure etc., when my spare time in the evening is stretching the right way…

Regards..

m4s0n501