RMAN - aborted incremental backups and recovery

Got a question on RMAN recovery with aborted incremental backups.
I suppose I can simulate this scenario..but thought I'd post the question here to get your opinion first.

Lets say I take a "Level 0" backup on Sunday; a "level 1" (cumulative or differential) on Monday and backup archivelogs by the hour.

Something goes wrong during Monday's Level 1..say the tape gets jammed. And I abort or kill the Incremental backup by doing a "kill -9" and do nothing else.

Then, say something goes wrong on Tuesday morning and I need to perform a full database recovery. When I issue a "restore database;" followed by a "recover database;" - what happens? Is RMAN intelligent enough to realize that the level1 backup was hosed, and it ought to restore Level0 followed by all the archivelogs? (Or does RMAN expect a DBA to inform the catalog about the failed backup everytime by explicitly removing the failed backup piece or something?. I would hope not!)

Thanks, Anand

If the first piece failed to write to tape, yes RMAN would know to skip that backup. However, if some pieces got written to tape oracle would not know the tape went bad. In that case, you would have to inform RMAN that the backup set was unavailable and do your restore using the archived logs.

Aargh..that sucks. How does it work in the real world? Do DBA's really keep track of backups by keeping the catalog upto date and deleting backup pieces manually everytime a backup fails? Or do they back up the rman logfiles as well and leave it at that? Come "show time" (or database recovery time), they learn it the hard way - that one of the incrementals was hosed. Then restore the backup RMAN logfiles to verify that a backup had indeed failed on such and such day. And THEN go about removing the pieces from the catalog?

Sorry about whining!

Thanks for your response Jeff.

The rman logs are emailed to me each morning.

What's the point of taking backups if they be no good?

When my backups fail (2 times last year), I fix the recovery catalog, and do a Level 0 at the next opportunity.

Yes, I expect to be notified when a backup fails as well and realize the importance of good backups. That wasn't the issue.

My concern was do you (DBA's in general) immediately follow up on a failed backup by updating the catalog? "We" (I'm the only DBA here though) managed several customers and their databases..and like everyone else, I have lots of things/projects on my plate. It is going to be a management nightmare for me to take the time to update catalogs everytime a backup fails. Backup failures are not so uncommon here..blame it on the data centre, the vendors, the storage or whoever.

IMHO, backup & recovery is the most important aspect of a DBA's role. Projects/tasks/etc. are secondary when compared to B&R.

Thanks Jeff. Got it. I guess I'm gonna have to do the same.

Am I glad I read this thread! I always assumed that RMAN knew when a backup failed midway it was bad :o . Looks like I'll be deleting backup sets in future.

Quote:

---

Originally posted by Axr2
Aargh..that sucks. How does it work in the real world? Do DBA's really keep track of backups by keeping the catalog upto date and deleting backup pieces manually everytime a backup fails? Or do they back up the rman logfiles as well and leave it at that? Come "show time" (or database recovery time), they learn it the hard way - that one of the incrementals was hosed. Then restore the backup RMAN logfiles to verify that a backup had indeed failed on such and such day. And THEN go about removing the pieces from the catalog?

Sorry about whining!

Thanks for your response Jeff.

---

DBAs are there to take care of all those deviations from scheduled routien activities.. no way you avoiding that.. 100% automation is not good and not efficient too..

Quote:

---

Originally posted by nagarjuna
DBAs are there to take care of all those deviations from scheduled routien activities.. no way you avoiding that.. 100% automation is not good and not efficient too..

---

:confused: :confused: :confused:

I strive for 100% automation as it is VERY efficient. The more manual labor that is needed to maintain my database, the more likely it will be shipped of to some country where DBA's make $5 a day...

Good points abt jobs being shifted to othe rcountries. But, I feel 100% automation is not efficient. Sometimes, automation scripts themselves take lot of time to write. I feel there should be a balance between automation and manula intervention depending on the type of activity and criticality of the set up. Offcourse, we should automate all the routine activities. We cant do the same for adhock activities. and i nthe case of exception.. writing code to capture and handle it will take lot of time. No we capturing and rectifying hardware problems..

Just an update to an old thread.

Here's an excerpt from 10g documentation. Looks like 10g might actually address my initial concern.

"Restore Tolerates Corrupt or Missing Backups
When the latest backup is not available, Recovery Manager (RMAN) now automatically uses an older backup for restore operations."

If I'm interpretting it correctly - if there's a missing piece, RMAN will now automatically look for an appropriate older piece.

===
Ooh..as I read it again, it's just the "WHOLE" backup, doesn't take into account missing pieces..:rolleyes: