A few months ago I got the exciting task to create a single instance standby for a RAC. Honestly,
I was skeptical about whether it would run properly. Additionaly, the single instance should be using
filesystem, while the Real Application Clusters is using ASM. Except for a few small stumbling blocks,
DBVisit convinced me otherwise. The installation was quite straightforward. If you’ve ever worked with
DBVisit, you will recognize that there is no big difference between creating single instance standby
for Real Application Clusters and creating single instance standby for single instance primary.
However, the RAC-specific settings shouldn’t form an obstacle for a DBA, who already worked with RAC.

You should note that both RAC Nodes, as well as the standby server, use the private hostname as default.
This is essential, since DBVisit queries the hostname to know whether it should perform a primary function
(sending logs) or a standby function (applying logs). Advantages of using private hostname, is faster and
safer shipping of logs via private network and conserving bandwidth.
Attention! You can only use the hostname, not the IP adress, as DBVisit simply queries the hostname.

If you are creating a single instance standby with normal filesystem, you should make some adjustments
in the SPFile because ASM directories like +DATA and +FRA don’t exist in classic filesystem.
Depending on the power of the standby server you would have to adapt the sga parameters, to avoid a system overload.
In my case, there was already an existing development database, which had an SGA size of 72GB,
therefore I had to reduce the SGA size dramatically.

Further it must be ensured, that the DBVisit archive log destination (dbvisit_archdest), where the archive
logs are temporarily stored on the standby server, aren’t splitted into two subdirectories for each node.
The archive logs of both nodes must be located in the same directory. It won’t work even if you specify
two different subdirectories in the DDC files. This is very dangerous, because the apply won’t issue any
errors. DBVisit would simply output „No new archive logs to apply“, even if there is an archive log gap.
You can only see in the DBVisit logfiles of the primary nodes that the archive logs from node 1
or node 2 are not visible.
So that DBVisit may apply the archive logs, you must make sure that the archive logs stay in the same
directory to be „visible“. You should also make sure that the service „dbvnetd“ is set to autostart,
so that DBVisit immediately establishes a connection between primary and standby in case of a crash
or reboot. The shipping and applying of the archive logs should be set up via cronjob every 15 minutes
with a delay of 5 minutes for every server in order to avoid parallel jobs and thus prevent associated
disorders.

Regarding Oracle’s pricing in terms of HA functionality for Standard Edition environments DBvisit is a
reliable option. It is easy to handle and runs smoothly, so that it represents a good alternative to Oracle’s Data Guard.

Specs Primary Nodes:

– 4x Intel Xeon @3.30GHz
– 128 GB Memory
– Oracle Grid Infrastructure 12.1.0.2.0
– Oracle Database Standard Edition 11.2.0.4.0
– Oracle Enterprise Linux 6

Instances on First Node:

– ORACLEPRODDB1 (11.2.0.4.0)
– +ASM1 (12.1.0.2.0)
– -MGMTDB (12.1.0.2.0)

Instances on Second Node:

– ORACLEPRODDB2 (11.2.0.4.0)
– +ASM2 (12.1.0.2.0)

Specs Standby Server:

– 4x Intel Xeon @3.30GHz
– 128 GB Memory
– Oracle Database Standard Edition 11.2.0.4.0
– DBVisit Standby 7.0
– Oracle Enterprise Linux 6

Instances on Standby Server:

– ORACLEDEVDB (11.2.0.4.0)
– ORACLEPRODDB (DBVisit Standby)