RMAN delete

[Thomasps]

RMAN delete script fails with following error. (Oracle RMAN 8.1.7 with TSM)

RMAN-03022: compiling command: change
RMAN-03025: performing implicit partial resync of recovery catalog
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-03023: executing command: DELETE
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03006: non-retryable error occurred during execution of command: change
RMAN-07004: unhandled exception during command execution on channel delete
RMAN-10035: exception raised in RPC: ORA-19509: failed to delete sequential file, handle="IESLIVEX_526809905.alb", parms=""
ORA-27027: sbtremove2 returned error
ORA-19511: ANS1301E (RC1)    Server detected system error
RMAN-10031: ORA-19509 occurred during call to DBMS_BACKUP_RESTORE.CHANGEBACKUPPIECE

Recovery Manager complete.

Any ideas will be much helpfull!

[SANJAY_G]

this might be helpful..
http://metalink.oracle.com/metalink/...&p_id=198158.1

[Thomasps]

Sanjay,

I saw that document, but looking for an option to avoid shutdown since this is a 24X7 system. Many Thanks.

[julian]

Look at 442982.999

[Thomasps]

Many Thanks Julian.

The core advise is

This problem is comming from the Media Managment layer. According to document: 227517.1 Main Index of Common Causes for ORA-19511. You will need to upgrade Tivoli TDP to version 2.2.1. You will want to contact Tivoli for any further questions regarding this issue.

The document 227517.1 is not describing the problem and my TDP version is

Tracing started for:
-----------------------------------------------------------
Application Client : TDP Oracle AIX
Version : 5.2.0.0

More over most of my databases are running in 8.1.7 without any issues. Finally SYSADMIN confirmed that there are 3 tapes got corrupted. I assume that is making the issue.

[Axr2]

Originally posted by julian
Look at 442982.999

What is this #? I can't find any Note ids on metalink. Is this a tar#? bug#?

[Axr2]

Thomas -

Can you try the below? (excerpt from a metalink article). This should theoretically do the job.

"Workaround
-----------

Delete the files through Tivoli

run an RMAN crosscheck backup

which will then mark the backup pieces , available, expired or unavailable.

Then a delete expired will clean up the repository."

[Thomasps]

Hi All,

Finally I did it. We are using TSM with tape backups and RMAN catalog database. Retention policy of the backup is 31 days and record keep time in control file is also same, 31 days. So I unregister the database from the catalog (so it deleted all the entries from the catalog and the tape backups untocuhed!) and re-registered again. I was able to re-register the database to the catalog with all the bacups since the record keep time (parameter value) is 31 days. Ran TDPOSYNC to sync the TSM with RMAN. Thats it.

Thanks to all!

[Axr2]

Originally posted by Thomasps
Finally I did it.

Define "it". In your initial post you said you made it seem like you had a problem deleting bs/bps from tape. You made no mention of retention policies or anything. Nor did you specify what you were actually trying to accomplish. No details, nothing. We aren't mind readers. Not even jmodic is.

Now you come up with some mumbo jumbo about successfully re-registering your target, and say "I accomplished it".

We are using TSM with tape backups and RMAN catalog database. Retention policy of the backup is 31 days and record keep time in control file is also same, 31 days. So I unregister the database from the catalog (so it deleted all the entries from the catalog and the tape backups untocuhed!) and re-registered again. I was able to re-register the database to the catalog with all the bacups since the record keep time (parameter value) is 31 days. Ran TDPOSYNC to sync the TSM with RMAN.

FYI - just coz your controlfile_record_keeptime is set to 31, it doesn't mean you'll automatically have 31 days worth of stuff in your controfile. It is also proportional to the size of your database and # of datafiles.

Thats it.

There's the "it" again. What was the "it" that you were trying to accomplish? Cleanup your catalog?

[Thomasps]

Sorry for the "it". Will try to minimise the usage!

Originally posted by Axr2

FYI - just coz your controlfile_record_keeptime is set to 31, it doesn't mean you'll automatically have 31 days worth of stuff in your controfile. It is also proportional to the size of your database and # of datafiles.

Will you please refer some document explaining this feature? Very much appreciated.

Many Thanks.