dinsdag, oktober 25, 2011

Cost reduction using Oracle SE and dbvisit standby

Often we get to hear that Oracle is so expensive. First thing that popup into my mind is: are you using the Oracle in a smart way? Sure, Oracle EE licenses have a price and it is quickly more than I can afford. However, if you use it for a site that earns you a Million per day, it is cheap compared to the loss you make during an hour of downtime, planned or unplanned.

One of the reasons people are going for EE - Enterprise Edition - is DataGuard.

DataGuard simplifies the management of a standby database but it is surely not the only option to keep a healthy standby database running as an option for DR. It is the most known option. One other option is to home brew a solution to manage the DR site. In the meantime we learned that a custom built solution might look like a good and cheap option at first sight, in the long run the hours spent on debugging and upgrading quickly make it a costly choice, especially compared to a third option I will show here. dbvisit standby

Dbvisit Standby works on SE - Standard Edition - and does the things DataGuard does for EE but for a much more attractive price. So if the only reason to go to EE is DataGuard, checkout dbvisit standby, it can safe you big money.

I tested dbvisit on Linux (vm) (dbvisit-standby6.0.08_linux.zip a whopping 43,1 MB download from http://www.dbvisit.com/dbvisit_download_register.php) and it does look good. It has a nice web based GUI that feels snappy. Just unlike Grid Control does. The interface is nice, fresh looking and responsive. It also has a few quirks that might popup or not, depending on the configuration where it is used. In my test environment I have a few Oracle installations and was testing using an ORACLE_HOME that was not the first one in the oratab. Despite the fact that the GUI did ask the right questions to ask for the correct ORACLE_HOME's, ORACLE_SID's, server name etc. it did not use them as I expected. Maybe this is because of using nearly the correct terminology.

When the GUI asks for a ORACLE_SID I assume it uses it to find the correct ORACLE_HOME and use that to connect to the Oracle Instance using a local connection. During the test this seemed to be different, the tool kept using the first ORACLE_HOME in my oratab. In a simple system with only one ORACLE_HOME installed this will not be a problem.

Database name, service name and ORACLE_SID are mixed in their use, this is confusing and can be wrong.

I ended up using the command line tool to get it all running. It was easy to create a valid standby database using dbvisit standby. It copied all needed files to the remote site, configured log transport and applied the logs without any problems. For some reason it did not detect that I already had a valid standby database running on the remote system. Could be my fault but when I specify a service name to connect to the standby database I expected a check for the presence of the standby database and at least give me the option to copy a new one or to use/register the existing standby database. The option to register an existing standby database does exist in the command line tool but I expected a little more help here from the tool. In the GUI tool I did not find it at all.

The product is usable but can be made slightly better. Maybe for someone who dives into the manuals first it would be no problem. For a MAC user who picks a manual when all other options failed it can be made better. The improvements needed are not fundamentally changing the product, just make it easier to use. One thing that surprised me is the inability to create a local standby database. For some reason, the standby database must be on a separate server. I think there is no real reason for this limitation.

The dbvisit site is full of screen shots and also a few pricing examples. If you need a standby database and if you not have a reason for other Oracle options, dbvisit is a good and valid option, that helps to reduce the cost running Oracle because you no longer are forced to use EE just to be able to use DataGuard. dbvisit does nicely fill in the gap here.

FWIW: I got great support from dbvisit and did not pay them anything to get things done. The support was accurate and responsive.