Unable to restore "inactive" oracle log archive

[GregE]

We have an Oracle DB that had "redundancy" (aka copy) set to 1. So last nights backup then ran "Delete obsolete" and set all prior log archives to "inactive_version." But they DO exist in TSM. I have not yet run expiration.

I can see them with this:
select backup_date,char(ll_name,30) as llname,char(state,20) from backups where node_name='DB01' and ll_name like 'DB01%' order by 1,3

                BACKUP_DATE     LLNAME                                                            Unnamed[3]           
---------------------------     ---------------------------------------------------     ---------------------
2013-10-17 02:25:46.000000     DB01_9momvk6t_1_1                                              INACTIVE_VERSION     
2013-10-17 02:27:51.000000     DB01_9momvk6t_1_2                                              INACTIVE_VERSION

DBA has worked some RMAN catalog magic so he can pull those files, and from his side it is working. It calls TSM server and then gives this error...

Starting restore at Oct 24 2013 15:57:28

channel t1: starting archived log restore to default destination
channel t1: restoring archived log
archived log thread=2 sequence=839
channel t1: restoring archived log
archived log thread=2 sequence=840
channel t1: restoring archived log
archived log thread=2 sequence=841
channel t1: reading from backup piece DB01_9momvk6t_1_1
channel t1: ORA-19870: error while restoring backup piece DB01_9momvk6t_1_1
ORA-19507: failed to retrieve sequential file, handle="DB01_9momvk6t_1_1", pa
rms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
   ANS1302E (RC2)    No objects on server match query

failover to previous backup

released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/24/2013 15:57:37
ORA-27191: sbtinfo2 returned error
Additional information: 3478

Any idea why we cannot restore those?
Is it the fact that they are "Inactive?" (I doubt it, but just a shot)

 

[moon-buddy]

Where was the 'delete' done - with TSM or RMAN?

If I remember correctly:

If this was done in RMAN, RMAN would not 'find' the files anymore even if you had not deleted the files in TSM. The RMAN catalog was updated after the delete. Use an older catalog to restore the files.

 

[GregE]

RMAN ran the "Delete obsolete"

DBA is using an older copy. That's how Oracle know which files to ask for. The RMAN script shows that it knows which backup piece it wants. It then reaches out to TSM and we're told TSM doesn't have it. But it does have it.

 

[moon-buddy]

RMAN ran the "Delete obsolete"

DBA is using an older copy. That's how Oracle know which files to ask for. The RMAN script shows that it knows which backup piece it wants. It then reaches out to TSM and we're told TSM doesn't have it. But it does have it.

Then try restoring an older TSM DB - a copy before the delete.

 

[MikeyD]

I think Ed's on the right track, I think the main issue is the tdp api expects the version to be active and even with the oracle catalog work your DBA did it doesn't have a way to specify inactive versions. If there's an undocumented command to update a backup object back to active you could try that as well but I haven't seen that one before.

 

[GregE]

I just put in a ticket with IBM, asking about this and how, via DB2, to update the STATE, if in fact that is what is the roadblock. This one has me curious. I think you guys are correct. I think the Oracle TDP treats "inactive_versions" in TSM server differently than inactive versions of other types of data. It's probably because it's assuming (correctly so when using the same RMAN catalog) that the data pointer has been removed from the RMAN catalog, so there would be no need to allow TSM API to get to it and cause additional issues.

 

[tariq.kaifi]

Interesting post!

Greg, did you hear anything back from IBM?