RE: REPOST: RMAN Image Copies
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 2 Sep 2004 13:30:32 -0400
The beauty of RMAN is three fold (at least, but these three always make me
smile)
1) Reading the database blocks via the RDBMS rather than via OS utilities
which know about OS blocks, not Oracle Blocks means no "fractured" or
"fuzzy" block issues and therefore no whole block redo i/o for the first
touch while in "hot" backup, and no issues of even being in hot backup for
"I didn't really reload the file anyway" instance recovery having been in
hot backup.
2) Incremental backup support.
3) RMAN keeps track of the pieces you need so think time at recovery should
be reduced and finding the pieces you need is reduced.
However, if you don't trust RMAN (your premise, and I won't argue with a DBA
saying they don't trust something about recovery. Until time 42 that's not a
winnable argument) then I'm not sure what would move you to trust RMAN with
the bookkeeping to keep track of the pieces for cold backups.
Also, I have not experimented with image copies, but I was really addressing
the fragment of your post
>>One requirement is the ability to schedule cold backups, especially if
where
>>is any reluctance to trust RMAN. It seems that an image copy fits
>>requirement. From what I see, you could recover the database from image
>>copies just as if they were created by copying the files (not use RMAN),
and
>>I can use this to fulfill the cold backup requirement. Has anyone tried
>>this?
By the way, has anyone had any RMAN "catalog" failure of recent vintage such
that there was no way to figure out what pieces you needed to recover, or
even a catalog failure at all? I don't mind if you have to intervene with
manual workarounds, just the condition where you can't recover something
RMAN would have led you to believe you could recover.
That logical issue has given me the willies ever since there was this
"stacker" program that spread blocks from multiple files across multiple
tape drives to minimize the source and destination queuing. It maintained a
catalog so that it could reconstruct files from the tapes. The catalog was
of proprietary structure, so basically all you could do with it was a "cold"
backup. So when the catalog silently went splat keeping track of things, you
didn't find out until you wanted things back that you couldn't get them.
Unless you were paranoid enough to routinely do test restores. Even then you
had to get something past "object number" 1024. Nasty, it was.
I've never seen RMAN fail, personally, but I've also never ridden it hard
and put it away wet. (That's horse riding, and the reference is to uncareful
use of resources where you stress out the horse and then don't take care of
it.)
Is reliability of the RMAN catalog and routine maintenance of the RMAN
catalog in the FMs somewhere?
mwf
---
To unsubscribe - mailto:oracle-l-request@xxxxxxxxxxxxx&subject=unsubscribe
To read recent messages - //freelists.org/archives/oracle-l/09-2004
Other related posts:
