Re: Why I don't like RMAN repositories

On 12/12/2013 4:59 AM, Tim Gorman wrote:

> this happened about 10 years ago. The parameter
> CONTROL_FILE_RECORD_KEEP_TIME was still at the default of "7" (days),
> so the poor DBA kept banging into the same wall where he needed to
> recover archivelog and datafiles going back over a month, but the
> control file only had 7 days (or less) of that information. We had no
> recovery catalog database. The sysadmins for tape management said,
> "Yeah, we've got everything going back 3 months, but you gotta tell me
> the file-name so I can find it and retrieve it". No, of course we had
> no way of knowing what the RMAN-generated names were, and we didn't
> feel like wasting time figuring it out.
>

Hmmm.... Very strange. I rarely need to know the exact rman backup file name. All I need do is restore the controlfile from a suitable autobackup copy and bingo: all I need to restore anything to any point in time within that controlfile window is there, ready for the taking.

Of course, if someone wants to restore a file from months ago AND roll it forward since, things might go clunk. Then again, how on Earth was that ever missed for so long? I do run a consistency check of all dbs with RMAN every night, so I guess that would be very unlikely with us.

> Now, two things are proven in this story. The first is that you don't
> need to set CONTROL_FILE_RECORD_KEEP_TIME to a higher value, and that
> you don't need a recovery catalog database, even if you're trying to
> effect a recovery using stuff from over a month ago.
>

Provided one has backups of the controlfile that match the backups of RMAN, then all is fine. As you mentioned, lIfe gets funnier if someone forgot to turn autobackup on. One of the things I insist on seeing in every db I touch is a "show all" from rman. Surprising how much can be missed at that level...

> Augment the belt with suspenders.
>
> Or don't. It's a choice.

My record for "restore that old thing" was for the DW: someone wanted the contents of 2 years ago of a table dropped a year ago. Nothing could be easier: restore from tape the FRA of 2 years ago - including the controlfile backup - into the DR system, then restore controlfile and the entire db there and roll forward to the end of the backup. Then export the table and move it back to the current production. Throw away the rest of DR. Total time? Half a day, of which getting the tape back from archive storage was by far the biggest delay.

Hey, what can I say? Most of the dire "disaster predictions" I've heard against what I do result in clear and demonstrable examples of far superior and faster processes. Must be that "bad dba" thing all over again? :)

-- 
Cheers
Nuno Souto
dbvision_at_iinet.net.au

--
http://www.freelists.org/webpage/oracle-l