| 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: How to validate RMAN backup
On 05/25/2006 11:21:49 PM, Mark Brinsmead wrote:
> I don't think that's the kind of "faith" that Mladan was referring to. ;-)
No, I believe that there is a god and that Larry Wall is his prophet. Our sacred book is so called "Camel Book", but this is not an appropriate forum to convert people to my religion, despite the fact that the former forum owner is of the same faith as me.
> And to that end, DUPLICATE DATABASE is incredibly tough to beat.
I agree. I believe that I mentioned that in my post.
>
> Does VALIDATE BACKUP actually guarantee that you have all of the datafiles
> you need? Or just that the
> datafiles included in the last backup? (Sadly, that particular question is
> not rhetorical; I've never bothered
> to check.)
Actually, "RESTORE DATABASE VALIDATE" simulates restoring the database and does validate that you have all the data files. If used correctly, it even verifies recoverability until time:
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> restore database validate
2> until time "to_date('05/25/06 17:00:00','MM/DD/RR HH24:MI:SS')";
Starting restore at 26-MAY-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=61 devtype=DISK
channel ORA_DISK_1: starting validation of datafile backupset channel ORA_DISK_1: reading from backup piece /data/orabck/backup/dbs0jhjtdbf_1_1.bak channel ORA_DISK_1: restored backup piece 1piece handle=/data/orabck/backup/dbs0jhjtdbf_1_1.bak tag=TAG20060524T212359 channel ORA_DISK_1: validation complete, elapsed time: 00:00:47 Finished restore at 26-MAY-06
RMAN> alter database open;
database opened
RMAN>
>
> Does VALIDATE BACKUP assure you that you have all of the archived redo
> necessary?
Yup. It does.
> Or that your
> files are actually on *tape*. (Lots of people these days seem to backup
> first to disk, then migrate
> to tape.)
That, of course, cannot be done without MML. Disks are cheap and fast and tape robots are expensive and slow. Using NetBackup or OmniBackup as a cataloging tool can be done without an expensive media management library. It doesn't take a visionary to envision quick extinction of magnetic tapes. I used RMAN on my last 4 gigs, but I haven't used or configured MML. When asked what woult that get me, my answer is normally: nothing special, it would synchronize RMAN and NetBackup (or OmniBackup) catalogs and make sure that those catalogs are in sync. As the last backup was always on the disks, together with all the archived logs, database was always recoverable. I found people very reluctant to spend few grands just to keep things clean when that can be more easily achieved by yelling at the DBA. It's cheaper and provides loads of fun to directors. Disks are only twice as expensive per GB as magnetic tapes and much, much faster. Magnetic tapes only make sense with multi-TB databases which were hard to assemble with smaller disks. Look at this:
Maxtor DiamondMax 10, 7200rpm 16MB Cache FDB, 300GB UATA/133 Hard Drive #6L300R0
Our Price: $104.99
Availability: Usually Ships in 24 Hours
Product Code: 6L300R0
http://www.supergooddeal.com/ProductDetails.asp?ProductCode=6L300R0&Click=17583
So, I can get 3GB for a buck or even cheaper if I go EIDE. Unfortunately, EIDE is much more limited with the number of drives then USB or SATA. Let's see tapes:
ADIC 110 / 220 GB SDLT Tape Media, 5 Pack
110 GB (native) / 220 GB (compressed), Storage, 5 pack, Serpentine Linear
39-1062-11 $307.99
http://www.superwarehouse.com/DLT_&_Super_DLT_Tapes/c3/2376
If you calculate the price of tape robot, which is usually rather pricey, you will see that the ratio doesn't justify use of cumbersome and slow tapes. Tapes and MML are things of the past, just like i486/66, 56k modems, chariots or flint axes. Move over David Bowman.
>
> Does VALIDATE BACKUP assure you that the tapes are actually READABLE on your
> recovery
> server and/or with the tape drives at your disaster recovery site? (I've
> seen things that can prevent
> both.)
Well, a tape cartridge that is readable when the backup is finished doesn't necessarily remain so when it reaches "secure off-site storage facility". Remember the aforementioned solar flares? There is no guarantee. Without RAID, there is no guarantee that the backup on disk will be readable tomorrow, either. That's what RAID-5 is good for.
>
> Does VALIDATE BACKUP guarantee that you have backups of your controlfiles,
> SPFILE, etc? (Well,
> I guess it might, but I bet it doesn't.)
>
> Does VALIDATE BACKUP actually make you (or your junior DBAs or operators)
> perform mock
> recoveries, thus ensuring that your recovery procedures are A) well
> documented, and B) well
> understood by those who will need to do them?
Nobody can make sure that the instructions are well understood. There is no
protection against idiots. Idiots are too inventive. At one of the companies that I
know of, IT was ordered to cut costs. VP in charge immediately canceled maintenance
of the backup generator claiming that it just devours money and fuel for test runs
and is never used anyway.
There was a nice and expensive RAC database to ensure 24x7 availability. Then hurricane
Floyd came and drenched Connecticut really well, flooding Danbury and knocking out
power for two days. I will leave the rest to your imagination. Single point of failure
wasn't so hard to find, after all. Army people says that not even the best plans can
survive contact with the enemy. Same applies to the database recovery. If you have
only one bozo in the whole department, he will be in charge of things when disaster
strikes. The only hope for a successful database recovery is to have people around who
can do it when push comes to shove. Professionals who know how to do recovery and who
have practiced with your particular system are the key. Unrelated to that, I'm still
waiting for the first data recovery stories from New Orleans to appear.
-- Mladen Gogala http://www.mgogala.com -- http://www.freelists.org/webpage/oracle-lReceived on Fri May 26 2006 - 00:22:10 CDT
 |
 |