Re: Multi terabyte dbses and issues with dataguard

To start with the obvious first:
Oracle Version? OS?

Other questions:

Is all of the data volatile? Or just a small part of it? Can you make large parts of the data read only? If so, you do not have to restore that after a failure.
If you have relatively few transactions, you might test the 10gR2 flashback features. It can help you to recover a failed primary as a valid standby.

Loss of archive logs should be monitored. Don't delete archives on the primary if they have not arrived at the standby yet. On a multi-terabyte system it shouldn't be a problem to keep archives for a couple of days or even weeks online.

I hope you still create backups. Data Guard is not an alternative for backups. You can restore a backup on the 'new' standby, create a standby controlfile on the primary, ship that to the standby, start the instance, mount it as a standby database and start the managed recovery process. It will start recovering, and requesting the missing archives from the primary (your monitoring system refused to delete them because the standby didn't receive them yet).

How long will it take to make the backup and ship it to the DR site, load the tapes and restore them to disk? Will this take shorter than sending the data through the network?

It's all about risk mitigation, planning and trade-offs. If you can afford to go without a standby database for a couple of days during the transfer of the database thruogh the network, and you have an automated procedure to do so, that might be a safe way to go. Be careful: you probably cannot afford to go without a standby if you haven't at least two standby's. You might think you can afford this, but what if disaster strikes during this 36, 42, 48 hour 'standby-reenabling' timeframe? Remember, Murphy will pick the right moment. That is probably not the right moment for you. How will the business react? Are they really forgiving if they are out of business for a couple of days, or worse, forever, because you failed over to the DR site and lost the database there before you could instantiate a new standby?

You are going the right way. Setting up an HA environment is preparing for disaster: plan A. Running Data Guard is part of your plan A. When disaster strikes, plan B has to be activated: 'How do we get back to normal as soon as possible'. This starts, as every plan, with a list of requirements. How long can you afford to run without a DR site? If the primary site burnt down, and we are running on the DR site, there might be no extra site to act as a DR site. This requires you to have proper restore and backup procedures in place at the DR site in the first place. They should be there now already. If there is no other standby, the backup tapes are your only resort in case of a new disaster. You won't have time to set up backup procedures in failover time. You have other problems to worry about by then. It's all about proper planning. And remember, you should have a problem for every solution. If you run out of problems, think harder. If you're still out of problems, ask a collegue to think for problems. If no more problems can be created, you might be pretty safe.

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Fri, 2006-03-31 at 13:39 -0800, David Turner wrote:

> We have several databases running dataguard without any major problems for some time. However, the databases have grown considerably and I'm concerned about our ability to restore a standby after a failover or a loss of archive logs that breaks the relationship between the two databases. Is anyone out there running a geo redundant multi terabyte configuration with dataguard? If so how are you restoring the standby database to the other datacenter?
>
> We've been simply copying the files over the network to the other data center. I have thought at some point it may be faster to just mail a tape backup to the other data center, restore, recover, and start standby, but was wondering how other people are dealing with this or other issues that I may want to look out for with large dataguard installations.
>
> Thx, Dave
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l