| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: 0% data loss setup ?
Prem,
0% data loss is not the same as 99.9999% availability. In fact, it is quite different...
If a CIO/CTO/CFO tells me "Never, but never ever, tell me that you lost my data", then RMAN is a big part (if not all) of the answer. I have been told this, and it is a requirement almost impossible to fulfill without RMAN. One CTO of a very low-budget company told me this, and I didn't even have to crack a smile, because 0% data loss is very achievable.
Forget about clusters, standbys, and replication -- those are for 99.9999% availability. Availability should not be confused with 0% data loss. To ensure you don't lose a single committed transaction, get the stuff onto tape, as quick as you can. Make multiple copies. Get those originals off-site and keep the copies onsite ready for use. And for god's sake, test those recoveries, as a matter of regular operations.
RMAN does several things along these lines:
With the repository (whether it resides just in the database's control files in NOCATALOG mode or in an optional "recovery catalog" database), you can create reports to tell you just how recoverable you are. I have a report that I run hourly that tells me if I am recoverable (from tape) to within XX hours of the present time. It can also tell me how redundant each component (i.e. datafiles and archived redo log files) are on backup media. RMAN is just another database application. If I find myself not able to recover to within the specified window or without the specified redundancy of backups, then I get paged. I find that I don't get paged often, but always for good reasons...
The CROSSCHECK command ensures that the repository is valid by attempting to "touch" each file out on backup media. So, this ensures that the reporting mentioned above is about as valid as it can be.
Like the bumper-sticker says, "Corruption Happens". And your boss isn't going to want to hear why something got corrupted and how it isn't your fault, because her/his instructions were simple: Don't ever lose data. RMAN puts you in the position where you can be positive that you'll never lose data to corrupted media, software, etc. Combined with Log Miner, you can even protect against rogue application programs to a great extent. This corruption-checking capability is what makes RMAN an irreplaceable part of a 0% data loss strategy. Any strategy that doesn't use RMAN has a huge hole in it for this reason.
As for the wisdom of making copies, my very first gig as a DBA is one I'll never forget. I was on the phone with Oracle Support in the UK (I work in Colorado, so that means it was 3:00am) on my first full media recovery, when I turned up a truncated archived redo log file restored from backup. The chap at the other end of the line commented, "Well, seems you should have gotten *two* backups of every file, hmmm?" If I could have reached through the phone and strangled him, I would have. RMAN allows duplexed backups, if you wish. Many tape-management systems allow you copy tapes after the fact, as well. Either is a good option.
And last, find a way to build a recovery test into your normal routine. I refer to using the VALIDATE RESTORE feature as "taking your tape drives out for a spin". Why not, if they're not otherwise busy? At two customer sites, we have built the fully-automated use of the DUPLICATE TARGET DATABASE command into normal weekly processing, so that a "scratch" or test copy of the production database is restored to another server, automatically, every week. This "scratch" database is useful for many purposes, especially tuning and testing. There is no better way to test recoverability than to actually perform a recovery. Often, the automated job completes just fine. When it doesn't, sometimes it is for a dumb reason (i.e. archived log file restores ran out of space, etc), but sometimes we have found truly frightening things (i.e. bad media, problems due to patched/upgraded software somewhere in the stack).
Use RMAN. Buy sufficient backup media capacity and integrate everything together. There is no better feeling than to find out about a recoverability problem when you are not in a recovery situation.
Just my $0.02...
-Tim
on 3/7/04 6:42 PM, Prem Khanna J at jprem_at_kssnet.co.jp wrote:
> Hi List,
>
> We will be soon having a system and it requires
> strictly 0% data loss in any case . Not even a
> single commited transaction should be lost.
>
> The setup will be 9iR2 on win2k .
>
> Standby database (max protection mode) may be a
> choice.But the primary DB tends to go down if it
> is not able to communicate with standby DB.this
> reduces the availability of my primary DB and so
> is not my option.And standby database in ( max
> availability mode) can have data loss and hence
> is ruled out.
>
> any HA suggestion ?!
> can someone let me know how it can be acheived ?
>
> Regards,
> Prem.
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sun Mar 07 2004 - 21:46:41 CST
 |
 |