Re: How to validate RMAN backup
- From: Mladen Gogala <gogala@xxxxxxxxxxxxx>
- To: Mark Brinsmead <pythianbrinsmead@xxxxxxxxx>
- Date: Fri, 26 May 2006 01:22:10 -0400
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 1
piece 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
