RMAN delete

Printable View

06-28-2004, 08:54 AM
Thomasps

RMAN delete

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

Code:

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!
06-28-2004, 09:27 AM
SANJAY_G

this might be helpful..
http://metalink.oracle.com/metalink/...&p_id=198158.1
06-28-2004, 12:09 PM
Thomasps

Sanjay,

I saw that document, but looking for an option to avoid shutdown since this is a 24X7 system. Many Thanks.
06-28-2004, 12:24 PM
julian

Look at 442982.999
06-28-2004, 12:51 PM
Thomasps

Many Thanks Julian.

The core advise is

Quote:

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

Quote:

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.
06-28-2004, 01:22 PM
Axr2

Quote:

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#?
06-28-2004, 01:36 PM
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."
07-27-2004, 06:12 AM
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! :)
07-27-2004, 01:07 PM
Axr2

Quote:

Originally posted by Thomasps
Finally I did it.

:rolleyes: 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".

Quote:

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.

Quote:

Thats it.

There's the "it" again. What was the "it" that you were trying to accomplish? Cleanup your catalog?
07-28-2004, 09:54 AM
Thomasps

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

Quote:

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.
07-28-2004, 02:12 PM
Axr2

Read up on the control_file_record_keep_time parameter. Control file can only expand to a certain limit. Bs, bp information is reusable.

If your database generates tons of logs and you back'em up frequently, you'll soon start seeing "denied expansion of controlfile" followed by "following controlfile record written over" messages in your alertlog.
07-28-2004, 03:23 PM
sambavan

I think these two metalink notes would give a vivid picture of what happens with the control_file_record_keep_time parameter setting. I think the controlfile will keep expanding on the circular section to satisfy the minimum record keep time condition.

Metalink note #s: 1034884.6 and 125303.1

Thanx,
Sam
07-28-2004, 03:31 PM
Axr2

Quote:

I think the controlfile will keep expanding on the circular section to satisfy the minimum record keep time condition.

A clarification - It won't expand indefinitely. It'll get circularly reused. There are hard set limits, beyond which controlfile will get overwritten. Say you set the control_file_record_keep_time to 10000 days on a large/active database. He's not gonna automatically retain 10000 days worth of information, in his controlfile a few years from now. That was the point I was trying to convey.
07-28-2004, 03:37 PM
sambavan

Quote:

Originally posted by Axr2
A clarification - It won't expand indefinitely. It'll get circularly reused. There are hard set limits, beyond which controlfile will get overwritten. Say you set the control_file_record_keep_time to 10000 days on a large/active database. He's not gonna automatically retain 10000 days worth of information, in his controlfile a few years from now. That was the point I was trying to convey.

I think the max limit is 365 :D

Cheers,
Sam
07-28-2004, 03:48 PM
sambavan

I presume that this is what you were trying to tell.

Metalinl Note:134234.1

Which talks about how oracle cautions when it cannot expand beyond the maxlog history limit.

Thanx,
Sam
07-28-2004, 05:12 PM
Axr2

> Metalinl Note:134234.1

Exactly. I often get those messages.
07-29-2004, 04:39 AM
Thomasps

Quote:

Originally posted by Axr2
A clarification - It won't expand indefinitely. It'll get circularly reused. There are hard set limits, beyond which controlfile will get overwritten. Say you set the control_file_record_keep_time to 10000 days on a large/active database. He's not gonna automatically retain 10000 days worth of information, in his controlfile a few years from now. That was the point I was trying to convey.

My values(control_file_record_keep_time = 31)is very much with with in 0 - 365. And I am not worried about the hard limit too, since

Code:

SQL> l 1* select * from v$controlfile_record_section order by RECORDS_USED SQL> / TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID ----------------- ----------- ------------- ------------ ----------- ---------- ---------- CKPT PROGRESS 4084 8 0 0 0 0 RESERVED1 56 62 0 0 0 0 RESERVED2 1 1 0 0 0 0 DATAFILE COPY 404 141 0 0 0 0 OFFLINE RANGE 180 90 0 0 0 0 BACKUP CORRUPTION 44 185 0 0 0 0 PROXY COPY 596 191 0 0 0 0 RESERVED4 1 8168 0 0 0 0 COPY CORRUPTION 40 204 0 0 0 0 DATABASE 316 1 1 0 0 0 REDO THREAD 228 8 1 0 0 0 REDO LOG 72 32 3 0 0 3 TABLESPACE 68 62 20 0 0 20 DATAFILE 428 62 21 0 0 30 FILENAME 268 127 28 0 0 0 BACKUP DATAFILE 116 1126 1126 1079 1078 4455 BACKUP PIECE 480 1140 1140 1128 1127 3354 BACKUP SET 40 1225 1225 294 293 3354 ARCHIVED LOG 328 23383 23383 11520 11519 63811 LOG HISTORY 36 26319 26319 9694 9693 80481 BACKUP REDOLOG 76 27083 27083 2622 2621 81611 DELETED OBJECT 20 28588 28588 21003 21002 80218 22 rows selected.

The records_used maximum value is nowhere near to the hard limit 65535.

Hope now you understand the re-registering is not harmfull to my backup information.

Thanks Sam and Axr2.