RE: REPOST: RMAN Image Copies

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_at_freelists.org&subject=unsubscribe 
To read recent messages - http://freelists.org/archives/oracle-l/09-2004