Dbvisit – Standby Database Technology Blog

A good location for the Disaster Recovery (DR) site could be current primary site. The primary site then becomes the remote location.

The reason for this is, that in the event of a disaster at the primary site (housed in the remote location), your current staff will be on hand and available to manage the standby site (which will now become the primary site).

Distance between primary and disaster recovery sites: How Far Away is Far Enough?
An interagency white paper by the SEC, Federal Reserve and other agencies that came out after 9/11 suggested a 200-mile or 320-km plus separation between the primary and secondary facilities. The two locations should be in a geographically different location. So if one location is prone to earth quakes or floods, then the other location should not be prone to the same conditions. Ideally they should be on a different power grid.

One of the first things to go when a disaster strikes is cellphones or mobile phones. Even if the cellular infrastructure is still intact, there will be some many cellphone calls made, that the system could easily be overloaded. So make sure your DR plan has sufficient contigencies in place without the use of mobile phones.

One of our successful partners in South America – Palacios Software has organised a number of presentations on interesting topics including fusion middleware, JDeveloper, ADF, Jheadstart and Disaster Recovery. The Disaster Recovery topic focuses on how Dbvisit can assist companies with business continuity (BC) and high availability (HA) in case of a disaster, outage or failure.

To view our Dbvisit power point presentation (in English) please see Dbvisit presentation.

Dbvisit 5.2.14 has been released for all platforms.

New features:

1. Provide the ability to logon with sys user and password. This can be used when sysdba logon without password cannot be used or when SQLNET.AUTHENTICATION_SERVICES= (NTS) cannot be set.
2. Improve message for error 837, sqlplus not found.
3. Improve message for ORA-01031: insufficient privileges.

Dbvisit can be downloaded from http://www.dbvisit.com/download.php.

Overview of all the latest changes: http://www.dbvisit.com/changes.php

Every time I use Perl, I am amazed at this programming language created by Larry Wall. I have used several languages in the past, but Perl is now my favourite. It takes a little getting used to, but once you are used to it, it is great.

What makes it so great

• CPAN site. Small and large Perl modules that can be easily plugged into your code to make life easier. Some of the modules available are: logging, email, html template engines etc. There are over 70,000 modules.
• Runs on Windows, Linux, Mac and Unix as well as other OS. It is truly a multi-platform language. For each OS you do have to take certain precautions, but there are CPAN modules that allow you to deal with each OS’es peculiarities like file name conventions.
• It can be used in OO style but also conventional style.
• It is very efficient. With very few lines of code, a lot can be achieved.

I have read the following negative things being said about Perl:
- “Good for little programs, but not for large programs because you get spaghetti code.”
I think this is not true, in any language you can write spaghetti code. This is not due to the programming language but due to the programming style.

- “Things can be done in more than one way”
I think this can be a good thing or a bad thing. With Perl, I consider this a good thing as it demonstrates the power and flexibility of the language.
True this can mean that Perl can be a bit cryptic as you may be used to seeing things solved another way. However it is a great language if you are a perfectionist and always keen to learn new things. With Perl there is almost always a better way to do things and you learn all the time. At least I do.

True, Perl is not so trendy anymore as say Python, Ruby or Java. It is also cometimes difficult to compare different languages as some are more suited to a particular application than others. You also have to look at how well the language is known and how many resources are available. For example to build a website I would probably choose PHP over Perl as there are so many more PHP programmers in the world than Perl programmers ( I also like PHP).

If you are an Oracle DBA that likes to automate specific tasks, I would highly recommend using Perl. I used to do everything in Korne Shell, and I thought it was a great language. But once you learn Perl, you realise your hands are no longer tied behind your back!

Perl is great to automate some of the tasks that may be required in your disaster recovery plan. This can be changing tnsnames.ora entries, or DNS entries.

You are not in isolation if you use Perl in your organisation. Oracle 11g uses Perl to write some of their interfaces. For example asmcmd (and asmcmdcore) are witten in Perl. Vmware uses Perl for their installation routine.

CPAN

To install a cpan module, type cpan (in Windows use PPM. Start cmd and type ppm):

CPAN>i /mailer/

The i is for information, this will list all modules with the word “mailer”.

To install a particular module, you have to specify the name exactly as it appears:

CPAN> install Mail::Mailer
That’s it and you can use it.

How to learn Perl

The best way to learn Perl is to start with a small project. For example write a little Perl program that scans the Oracle alert log and send an email if an error appears. You will probably have Perl installed already because Perl comes pre-installed on Unix and Linux. On Windows go to activestate.com and download Perl.

The best Perl book in my opinion is Programming Perl by Larry Wall, Tom Christiansen, Jon Orwant.

So thanks to Larry Wall and all the great people that help support Perl and CPAN.

One of the questions we get asked a lot is:
In terms of ORACLE licensing, do we need a separate Orcacle license for the DR / Standby database?

Yes, you require a separate Oracle license for the DR / Standby database. This license has to be the same license metric as the primary database. This means that if you license the primary database per CPU, then the standby database must also be licensed per CPU (although it does not have to be the same number of CPU).

Or if the primary database is licensed per user then the standby database must also be licensed per user.

It must be the same license type, so if your primary database is Standard Edition, then the standby database must also be Standard Edition.

We might go for Standard Edition Processor based licensing option, which allows us to have up to 4 CPU in total. If we have a production / primary server with 4 CPU, will the licensing work with standby database?

You will require a separate Oracle Standard Edition license for the standby database which is also processor based. With Dbvisit we include the standby database with the Dbvisit license for the primary database.

How would the licensing work for Multiple standby databases?
Oracle is licensed per server not per database, so you can have as many databases as you wish on the same server. With Dbvisit we have 2 types of licenses, Single Instance or Multiple Instance (or server license). If you have Dbvisit for 1 primary database, then the Single Instance license is needed. If you have Dbvisit for more than 1 primary database on the same server, then the Multiple Instance license is required. With all Dbvisit licenses you can have unlimited standby databases.