Unfortunately DIY projects don’t always stick to plan (or budget) and can be somewhat experimental, often costing more to manage and support than originally anticipated. When it comes to disaster recovery, if your data is critical to the business continuing to function it is essential to to have the best solution you can afford in place. If you’re weighing up DIY versus ‘off the shelf’, here are some important considerations to look at:

• Has the DBA covered all the bases? (bearing in mind it is very difficult to test and simulate all the issues that can go wrong).
• Is it going to be reliable, stable and easy to support in the long run?
• What happens when the DBA that developed the script leaves your organisation, is there someone else who knows how it works?
• Will a new DBA understand how the script works and be confident enough to use it (and fix it) when things go wrong?
• What will happen when you upgrade or patch Oracle? Will you be confident that it still works?
• What will happen if you migrate to another platform?
• What happens if there is a temporary glitch. Will it automatically recover and continue without intervention from the DBA?
• Does it support the Oracle features such as RAC, OMF, ASM?
• Does it create the standby database automatically?

Using a proven, reliable and stable solution like Dbvisit can really pay off in the long term. Dbvisit works on most platforms that are supported by Oracle including Windows, Linux and Unix and is backed by world class support. The team behind Dbvisit specialises in Oracle Disaster Recovery and as such are fully committed to ensuring you have full confidence in your Disaster Recovery solution.

Whichever path you decide to take, the most important things to think about are: Have I really done the right thing by my data? Does my solution tick all the boxes and protect my data the way it needs to be  protected? Have I thought about the long term effect of my decision on my departmental budget?

www.dbvisit.com

However Dbvisit came to our rescue, and the functionality we have been recommending to our customers for a number of years now actually saved us! We employed Dbvisit to successfully recreate our primary and standby databases.

We have the following development servers:
Dev servers 1
dbvisit11 – primary database server
dbvisit12 – standby database server for dbvisit11

Dev servers 2
avisit31 – primary database server
avisit32 – standby database server for avisit31

Dev servers 2 are a clone of dev servers 1 with the same databases.
Due to the deletetion of the datafiles, the databases on dbvisit11 and dbvisit12 were gone.

Here is what we did to get the databases back on dbvisit11 and dbvisit12:

1. Logged onto avisit32 and used dbvisit_setup to automatically create a new standby database on dbvisit12.
2. Activated the standby database on dbvisit12 to become a new primary database.
3. Used dbvisit_setup on dbvisit12 to create a new standby database on dbvisit11.
4. Used graceful switchover to switch the roles between dbvisit12 and dbvisit11.

And so in 4 easy steps we had our databases back on our Dev servers 1: dbvisit11 (primary database) and dbvisit12 (standby database).

It is very rewarding to be able to use our own technology to recover a primary and standby database.

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.

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.

Maintenance overheads aside, think about the opportunity costs in lost productivity. Now imagine a 16 hour downtime. Will your company operations be hurt because of inaccessibility to critical data? In the US, 43% companies never reopen after a major disaster*, and only 7% survive for an additional 5 years**.

While we cannot control external forces – natural, human or technical; we can control the impact they have on our businesses. No company is immune to such catastrophes. Companies are protecting their data against disruptions more seriously today with contingency plans and standby servers, because of our excessive dependencies on machines.

Time or data loss has huge costs in terms of overheads and lost opportunities. Loosing integral data to disasters not only impacts the security and finances of your business, it jeopardizes its existence completely.

So the question is, how prepared are you to face such unforeseen situations? Do you have the peace of mind that no matter what happens, your company’s data will be protected and your business will continue without stalling even for a moment?

Your business success, bottom line, and growth depend on how prepared and secure your systems and processes are at all times.

You won’t ever have to recover from disasters, if you are ready for them.

(* US Small Business administration)
(** US Bureau of Labour)

Microlistics is a successful privately owned Australian Company focused on delivering Warehouse Management systems throughout the Asia Pacific and Middle East regions. We are proud to be one of their technology partners.

In North America Fiserv have bundled Dbvisit with their Credit Union platform. One-third of US credit unions depend on Fiserv to deliver technologies that serve as the backbone for their daily operations.

Alcatel-Lucent have bundled Dbvisit with their Next Generation Operational Maintenance Centre. Their senior software developer has this to say about Dbvisit: “The solution takes a complex problem and distils it down to reliable, cost effective, and easy to use product.”

Software vendors are starting to realise the importance of offering a complete solution to their customers which includes disaster recovery. Dbvisit is seen as a best-of-breed solution to offer Oracle disaster recovery.

A standby database is far superior to a normal backup as it is instantly available in the event of a disaster or failure. To restore a backup takes time, and during the restore time the system is not available. A restore may also cause too much impact on other systems. With a standby database there is nothing to restore in the event of a disaster or failure as the standby database is always available. It is possible to switch applications over to the standby database in a matter of minutes to allow business continuity.

There are several replication mechanisms to keep a standby database up to date:

1. Physical Standby using redo or archive logs
2. Logical Standby using SQL
3. Oracle replication using streams

Physical standby is the most commonly used for disaster recovery or failure. Conceptually the mechanism for keeping the standby database updated is not difficult, but putting this into practice to get a robust solution is complex and requires a lot of work. The reason is that there are so many things that can go wrong at each step of the process and you have to ensure that the standby database keeps up to date no matter what. And if it is not keeping up to date then alerts should be raised. The last thing you want to happen is that the standby database is old, when you need it most.

We have seen instances where the companies have used home grown solutions to keep the standby database up to date, but when the DBA left that wrote them, the new DBA’s were too scared to touch it incase it broke. So no DR test was even done. In the case of an actual hard disk failure, the DBA recommended to restore from backup, rather than switch to the standby database, because they were not sure if it was kept up to date and how the process could be reversed once the primary server was operational again. At another company, the standby database was last updated 2 years ago!

The standby database can be used for other purposes other than just for disaster recovery:

1. Reporting database. READ ONLY queries can be performed on the standby database to offset loads from the primary database.
2. Shadow environment which can be used to investigate issues like database bugs or inconsistencies that arise on the primary database and the primary database can continue to run risk free while the issues are investigated on the shadow database.
3. Capturing snapshots for batch transactions (point in time). The standby database can be used for rollback purposes in case of errors during batch processing.
4. Perform backup on the standby database rather than the primary database to offset loads to the primary server. Backups can be done in the middle of the day to ensure staff are available to resolve any backup issues.

Oracle licenses
You will need a full Oracle license for the standby database. This needs to be the same metric as the primary database. So if you primary database is Enterprise Edition, then your standby database also needs to be Enterprise Edition. If the primary database is licensed per CPU, then the standby database aslo needs to be licenced per CPU.

Are you prepared for a data disaster?

43% of business never reopen after an loss of data disaster*
29% close after 2 years*
93% of companies that suffer significant data loss are out of business within 5 years**

These are statistics to be taken seriously. Some of these statistics could have been prevented if they had installed Dbvisit.

For many businesses their database is their lifeblood, without it, there is no business. Yet in most instances businesses are NOT sufficiently protected in case of an unforseen emergency such as hardware failures, power outages, network issues, bomb threats, fires, earthquakes, disgruntled employees and floods.

Having a data recovery strategy in place is absolutely critical whether you are in Manufacturing, Health care, Governmental, IT, or Financial.
Business continuity is now a CEO and boardroom level concern.

Making sure you have a disaster recovery strategy in place is absolutely critical. Having a dedicated Oracle disaster recovery solution for your Oracle databases is crucial for the future of your business.

(* US Small Business administration)
(** US Bureau of Labour)