Best tactic to migrate recovery catalog

#Recovery Catalog
Oracle9i 9.2.0.1.0
Windows 2003 Server - 32 bit
Our recovery catalog is an old one, we will upgrade this to 11g, but we will need to make a new server for him as well.
Correct me if i am wrong but one way should be just to create a new server, install oracle and database, and re-connect all recovery catalog users to this one, and make new backups on them to get information about backup in the new catalog.
However, should'nt it be possible to export the data from old recovery catalog , to new recovery catalog?
Please guide me to the best tactic
Regards,

migrate catalog from 9i to 10g
Read the link.
Regards
Asif Kabir

Similar Messages

What is the best way to migrate PSE6 Catalog (Wxp) to new computer W7, PSE11?

What is the best way to migrate PSE6 Catalog (Wxp) to new computer W7, PSE11? Previous PSE6 recovery (Wxp) after a failed HD resulted in pictures showing but not opening due to connection issues. Had to restore pictures from backup and rebuild the catalog and albums. Found a third party fix afterwards that has no support past PSE8. Trying to make this migration to PSE11 painless.

William47 wrote:
What is the best way to migrate PSE6 Catalog (Wxp) to new computer W7, PSE11? Previous PSE6 recovery (Wxp) after a failed HD resulted in pictures showing but not opening due to connection issues. Had to restore pictures from backup and rebuild the catalog and albums. Found a third party fix afterwards that has no support past PSE8. Trying to make this migration to PSE11 painless.
That's a very common and classical situation :
http://helpx.adobe.com/photoshop-elements/kb/backup-restore-move-catalog-photoshop.html
Just make sure that your backup to the external drive is ok : you should find a 'backup.tly' file in the folder.
Use the PSE11 organizer to restore from the PSE7 backup : the first step restores all your media files, the second automatically does a catalog conversion to the PSE11 format.
Read the note in the above link about restoring from XP to ulterior Win OS. You can also restore to a 'custom' location. For instance in a 'C:\My new library' folder. Make sure that master folder is accessible to all users, and if you want, you can move the catalog (database) itself from that location to the default location : catalog manager, option to move catalogs to location accessible to all users.

Recovery catalog best practice

Hi there,
I want to ask you about your recovery catalog best practices
should it be separate server, how to backup it, should I have standby recovery catalog, etc. ?
we have dc and rdc and about 20 databases, we do backups to tapes and we use recovery catalog (in dc 11.2.0.3) on separate lpar on aix 7.1
I mostly wonder how to protect it
regards!

for recovery catalog you also do rman backup and put it in tape or Disk (if it is small database) so that at the time of server failure you can get all information and make a schedule to try to recover recovery database backup on diffrent server to check its creadibility.

Oracle 10g express edition recovery catalog

whether oracle 10g express edition spoort recovery catalog?

Yes you can; the answer is in the manual.
>
In general, the rules of RMAN compatibility are as follows:
<li>You can create 8.X or 9.X RMAN catalog schema in any Oracle database release 8.1.X (or higher) and Release 10g RMAN catalog schema in any Oracle database release 9.0.1 (or higher).</li>
<li>The recovery catalog schema version must be greater than or equal to the RMAN client version.</li>
<li>Ideally, the versions of the RMAN client and the target database should be the same (although there are other legal combinations, listed in Table B-1).</li>
<li>While backing up a Release 10g database using the 9.X RMAN client, you cannot include a controlfile that was created using compatible=10.0.0 in a datafile backupset. The workaround is to turn controlfile autobackup ON.</li>
>
http://download.oracle.com/docs/cd/B12037_01/server.101/b10770/compat.htm
http://download.oracle.com/docs/cd/B25329_01/doc/admin.102/b25107/backrest.htm#i1004902
XE questions are best answered here {forum:id=251}
Regards,
Phiri
Edited by: phiri on 02-Apr-2010 01:36

Backup policy on Grid, using RMAN and Recovery Catalog.

Hello Gurus,
I'm trying to move ahead the new features of Oracle 10g in my company. So I've already created Grid Control and will deploy Agents/Targets during the next week. I also want to switch the backup process from the archaic exp/imp to RMAN with the Recovery Catalog.
My question is such: could anybody suggest the best book or text with solutions and descriptions of backup policy, using the Grid, RMAN and Catalog? What I want to do is to create eventually the powerful and centralized storage of every database in a company and do all daily routine from there. But as long as I'm only in the very beginning I want to gain some knowledge before the bad experience, like crashed recovery catalog and no backups for all databases :-)))
Definitely I'll keep existing imp/exp and hotbackup for a long time. I'm not going to substitute all our backup strategy with one catalog. I just want to understand what will be the best practice in the backup perspective.
And at all, I wonder if you please could give me very brief answer to this question: Let's say I have a huge monster with 5 disks by 500Gb RAD0+1. Is it a bad idea to store all of them in one physical machine before they will tape to backup or it could make sense? For me it sounds a bit scary, but probably if all made with the brain it's not a bad idea?
Please, send me to some valuable and good source (like Tom Kyte or Don Burleson) Unfortunately, I didn't find anything regard the backups itself. Only pretty much general thought.
Thanks a lot in advance.
M.

great!
thanks a lot!
this is definitely valuable info and I'll read right away. but as far as understand they suggest to use Data Guard, Standby and RAC which are the best ways to prevent your environment from crash. But in reality (I mean in my company) nobody is going to move to RAC at this point and I'm not sure, that they will have a chance to do in the next year. they just aren't up to it.
what I'm looking for is probably some tips and hints about backups in more or less big environment, but not as big as Oracle itself :-) unfortunately, i'm the only DBA in my surrounding. i mean, i have no friends or mentors DBAs that could seat with me in a pub and pass theirs knowledge from generation to generation :-)))
but anyway, I'll devote this week-end to this link.
thanks a lot!

Resync recovery catalog with controlfile

Oracle :10.2.0.2
os : solaris 5.10
When doing stage refresh with production using RMAN a small pitfall happen.
By mistake i have connected to the stage database and production recovery catalog. This was done after changing the db name for stage database. Recovery catalog has taken this as new incarnation. The stage database opened with resetlogs after refresh. The db id's of both the incarnations are same.
DB_KEY DBID DBINC_KEY NAME CUR
1 3582966461 2 PRD NO
1 3582966461 578463 STG YES
Could anyone help me to resync the recovery catalog with old incarnation with production database.
Help needed ASAP.
Thanks

Hi,
We are following the rename datafile and then switching and opening the db with resetlogs. In this scenario we are only changing the db name not the dbid.
If it is not for a restore test the duplicate command previously mentioned does everything for you. If you want to proceed manually change the DBID manually after the restore.
Any further suggetions to resolve my issue.
The suggested unregister/register failed ? Catalog is just an optional help, losing data from the catalog does not compromise the possibilities of restorations.
Best regards
Phil

Why Recovery Catalog

Why I cant use control file to make repeated TSPITR unless use recovery catalog ?
If I use recovery catalog, can I use backups of tablespace before created recovery time ?
Best Regards

1 Because of mandatory open resetlogs after TSPITR. This creates a new 'incarnation' of the database, invalidating the previous incarnation.
2 Yes
Sybrand Bakker
Senior Oracle DBA

Migrate Rman Catalog over cross platform's

I need some suggestion for migrating Rman Catalog...
Current Rman Catalog: 10gR2 on HPUx and would like to migrate and upgrade to 11g on Linux....Any suggesions...
My thoughts: exp and import schemas from hpux to linux 10g -10g and upgrade 10g catalog to 11g on new linux server....
Any help would be appreciate.....

There is "NO UNREGISTER" option...
NO UNREGISTER Forces RMAN to keep imported database IDs in the source catalog schema. By default, the imported database IDs are unregistered from source recovery catalog schema.
-------------------------------------------------------------------------

Backup and restore to the other database with Recovery Catalog

Dear All,
i need your help about recovery catalog.
I have 3 databases, 2 databases version are 8.1.7.3 (HostA and HostB) and other database is 9.2.0.6 (as Catalog Database)
I want to backup files from HostA with Catalog Database into tape, then restore the backup files into HostB.
Please suggest me how to do this.
Best Regards,
abip

you can achieve this with the rman duplicate command.
if you have the same directory structure then it is a relatively simple task, if the directory structure is different then you need to use the
'set newname' syntax.
regards
Alan

Create a recovery catalog by using the Enterprise Manager Console

Dear Sirs:
I am using the Oracle9i database release 2. After installing the management server and running the Enterprise Manager Configuration Assistant, there was no recovery catalog and no CATTBS tablespace created. According to the Help and to your documentation entitled Oracle Enterprise Manager Configuratrion Guide this recovery catalog and CATTBS tablespace should be created automatically.
Of course I am not running any target database on the same machine.
How can I create a recovery catalog by using the Enterprise Manager Console, and not by using the rman command prompt?
Please its urgent and I need an answer as soon as possible.
Thank you in advance with best regards

Dear Sir:
Thank you very much for your reply, but unfortunately it didnt help me. This article is repeating what is mentioned in the Help and the documents that I downloaded earlier. As I said earlier I know how to setup the recovery catalog by using the rman command prompt, but I couldnt do it by using the Oracle Enterprise Manager Console. By using the wizards it is supposed to be created automatically but nothing of this happened.
Please I need help urgently.

Recovery catalog Manitenance

Crosscheck all, catalog files, delete expires, obsoletes, these are some thing to maintain recovery catalog,
Is there any other things to manage recovery catalog .

You can find them all described here:
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmrepos.htm#441628
Best Regards
Krystian Zieja / mob

Connecting to recovery catalog

i want to clear my concept, when we are connect with target & recovery catalog like this
rman target / catalog rman/rman@rman1are we only accession the target or recovery catalog DBs.
How i can connect to catalog only & check the staus of all my backups?

You need to connect to target database to use
LIST or REPORT commands. But you can connect
to recovery catalog from SQL*Plus and query manualy Recovery Catalog Views.
<This is only example>
[email protected]> select * from rc_backup_set;
Best Regards
Krystian Zieja / mob

Recovery of Recovery Catalog

Hi.
I am going to have to explain to our boss of bosses what I think we should do in order to "optimize" our Oracle databases and how to reach closer to HA.
I will recommend three possible moves:
Dataguard (probable, since its my uunderstanding this in much cheaper and easier to configure than the next point)
RAC
and RMAN
I expect to have to explain more about all of these, but what does concern me is this (actually a worry of a DBA here who wants to stop us using rman for some reason):
ALl information about backups, rman scripts etc, are stored in the REcovery Catalog repository. What are the common measures in backing up the recovery catalog, and what are the dangers when we have to do recovery on it?
I am asking this, since I know the DBA here will tell us "I am concerned with recovery. If production database needs recovery, then we find the recovery catalog is lost, then we will have to do x2 recoveries. With our present system, we just recover from the back up disks"
I dont share his opinions, I just need to know how I can best argue for the cause of RMAN!
Thanks

Dan A wrote:
Yes but isnt that information erased after a default setting?A default setting of what? As stated, the control file is the primary repository of the information rman needs to track backups and effect recovories. Nothing need be erased and I'd think it would take some rather extraordinary measures to 'accidentally' erase the rman info from the control file.
If your senior DBA is resisting the use of rman for backups, he is in some severe need of re-education. Actually, he is in some severe need of attitude readjustment. An attitude of resisting new knowledge, new features, new techniques will not serve his career well.

Recommendations for recovery catalog database backup

Hi
We are using IBM Tivoli Storage Manager for our 9i db on AIX 5.2.
I would like us to consider using rman but I am not sure of the best way we would go about backing up the database we would use for our recovery catalog.
This database that hold all the metadata would need to be backed up after every rman backup. The rman backup would go to tape, so I am assuming that the recovery catalog would be backed up on tape also.
What are the common procedures for this in other shops ?

Dan A wrote:
Aman. That doc does help, and indeed it does explain
Back up the recovery catalog with the same frequency that you back up the target database.
We would be doing nightly backups, so we would have to back up the catalog with the same frequency.
The doc explains that we would use rman for these backups also, but that it would be in NOCATALOG mode so that the repository is in the control file.
And then what? Just copy this to tape? Seems that with rman there is then a need to do two backups - one of the target db and one of the recovery catalog.
Thanks.I shall suggest to take an export of the underlying schema which is holding the info in the recovery catalog. That's all which is basically required to be safe. In case , everything gets burnt regarding the catalog db,you can immediately create another db, import the user back there and things are in place. This should be a quick and easy way out of the backup of recovery catalog.
Yes if you are going to take backups every night than backup of recovery catalog schema/db nightly will be a good option. Docs are meant to promote people for RMAN so indeed they would talk about it. But its not at all a compulstion to use RMAN for recovery catalog schema's backup. If its a big catalog maintaining lots of database's info than using RMAN with all its features is a good option. If a single db is a part of it than it may not be that much big and export of teh schema alone may serve the purpose too.
HTH
Aman....

Recovery Catalog showing wrong Archive Destination

Hi All,
I am using Oracle 10g on Solaris 10.
The problem I am facing is this, while taking backup using recover catalog..............
Starting backup at 27-JUL-11
current log archived
released channel: ch00
released channel: ch01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 07/27/2011 11:16:47
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /u01/oracle/product/10.2.0/db_1/dbs/arch1_56_757089402.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
This is because of the following reason
RMAN> list archivelog all;
List of Archived Log Copies
Key Thrd Seq S Low Time Name
39401 1 1567 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1567_756523261.dbf
39402 1 1568 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1568_756523261.dbf
39403 1 1569 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1569_756523261.dbf
39404 1 1570 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1570_756523261.dbf
39405 1 1571 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1571_756523261.dbf
39406 1 1572 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1572_756523261.dbf
39407 1 1573 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1573_756523261.dbf
39408 1 1574 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1574_756523261.dbf
39409 1 1575 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1575_756523261.dbf
39410 1 1576 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1576_756523261.dbf
39411 1 1577 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1577_756523261.dbf
39412 1 1578 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1578_756523261.dbf
39413 1 1579 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1579_756523261.dbf
39414 1 1580 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1580_756523261.dbf
39415 1 1581 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1581_756523261.dbf
39416 1 1582 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1582_756523261.dbf
39417 1 1583 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1583_756523261.dbf
39418 1 1584 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1584_756523261.dbf
39419 1 1585 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1585_756523261.dbf
39420 1 1586 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1586_756523261.dbf
39421 1 1587 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1587_756523261.dbf
39422 1 1588 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1588_756523261.dbf
39423 1 1589 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1589_756523261.dbf
39424 1 1590 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1590_756523261.dbf
39425 1 1591 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1591_756523261.dbf
39426 1 1592 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1592_756523261.dbf
39427 1 1593 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1593_756523261.dbf
39428 1 1594 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1594_756523261.dbf
39429 1 1595 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1595_756523261.dbf
39430 1 1596 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1596_756523261.dbf
39431 1 1597 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1597_756523261.dbf
39432 1 1598 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1598_756523261.dbf
39433 1 1599 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1599_756523261.dbf
39434 1 1600 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1600_756523261.dbf
39435 1 1601 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1601_756523261.dbf
39436 1 1602 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1602_756523261.dbf
39437 1 1603 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1603_756523261.dbf
39438 1 1604 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1604_756523261.dbf
39439 1 1605 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1605_756523261.dbf
39440 1 1606 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1606_756523261.dbf
39441 1 1607 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1607_756523261.dbf
39442 1 1608 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1608_756523261.dbf
39443 1 1609 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1609_756523261.dbf
39444 1 1610 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1610_756523261.dbf
39445 1 1611 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1611_756523261.dbf
39446 1 1612 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1612_756523261.dbf
39447 1 1613 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1613_756523261.dbf
39448 1 1614 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1614_756523261.dbf
39449 1 1615 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1615_756523261.dbf
39450 1 1616 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1616_756523261.dbf
39451 1 1617 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1617_756523261.dbf
39452 1 1618 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1618_756523261.dbf
39453 1 1619 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1619_756523261.dbf
39454 1 1620 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1620_756523261.dbf
39455 1 1621 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1621_756523261.dbf
39456 1 1622 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1622_756523261.dbf
39457 1 1623 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1623_756523261.dbf
39458 1 1624 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1624_756523261.dbf
39459 1 1625 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1625_756523261.dbf
39460 1 1626 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1626_756523261.dbf
39461 1 1627 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1627_756523261.dbf
39462 1 1628 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1628_756523261.dbf
39463 1 1629 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1629_756523261.dbf
39464 1 1630 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1630_756523261.dbf
39465 1 1631 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1631_756523261.dbf
39466 1 1632 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1632_756523261.dbf
39467 1 1633 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1633_756523261.dbf
39468 1 1634 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1634_756523261.dbf
39469 1 1635 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1635_756523261.dbf
39470 1 1636 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1636_756523261.dbf
39471 1 1637 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1637_756523261.dbf
39682 1 1638 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1638_756523261.dbf
39689 1 1639 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1639_756523261.dbf
40642 1 1640 A 26-JUL-11 /oradb2/Archive/HCSPRD91/1_1640_756523261.dbf
40643 1 1641 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1641_756523261.dbf
40644 1 1642 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1642_756523261.dbf
40645 1 1643 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1643_756523261.dbf
40646 1 1644 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1644_756523261.dbf
40647 1 1645 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1645_756523261.dbf
40648 1 1646 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1646_756523261.dbf
41310 1 1647 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1647_756523261.dbf
41317 1 1648 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1648_756523261.dbf
41373 1 1649 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1649_756523261.dbf
41374 1 1650 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1650_756523261.dbf
41375 1 1651 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1651_756523261.dbf
41383 1 1652 A 27-JUL-11 /oradb2/Archive/HCSPRD91/1_1652_756523261.dbf
*38725 1 56 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_56_757089402.dbf*
*38946 1 57 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_57_757089402.dbf*
*39000 1 58 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_58_757089402.dbf*
*39022 1 59 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_59_757089402.dbf*
*39243 1 60 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_60_757089402.dbf*
*39297 1 61 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_61_757089402.dbf*
*39703 1 62 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_62_757089402.dbf*
*39704 1 63 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_63_757089402.dbf*
*39705 1 64 A 26-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_64_757089402.dbf*
*39933 1 65 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_65_757089402.dbf*
*39991 1 66 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_66_757089402.dbf*
*40023 1 67 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_67_757089402.dbf*
*40024 1 68 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_68_757089402.dbf*
*40025 1 69 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_69_757089402.dbf*
*40254 1 70 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_70_757089402.dbf*
*40308 1 71 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_71_757089402.dbf*
*40345 1 72 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_72_757089402.dbf*
*40570 1 73 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_73_757089402.dbf*
*41329 1 74 A 27-JUL-11 /u01/oracle/product/10.2.0/db_1/dbs/arch1_74_757089402.dbf*
I dont know from where recovery catalog is getting the information in bold.
I have crosschecked and deleted archives and resynced the catalog several times. Immediatly after doing that the backup works fine, but the other day its the same thing all over again.
Can some one tell me from where the catalog is getting this wrong infomation about archivelogs???
By the way here is some more info about my target Database:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradb2/Archive/HCSPRD91
Oldest online log sequence 1651
Next log sequence to archive 1653
Current log sequence 1653
NAME TYPE VALUE
archive_lag_target integer 0
log_archive_config string
log_archive_dest string
log_archive_dest_1 string LOCATION=/oradb2/Archive/HCSPR
D91
log_archive_dest_10 string
log_archive_dest_2 string
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
NAME TYPE VALUE
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string
log_archive_dest_state_1 string enable
log_archive_dest_state_10 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_state_6 string enable
log_archive_dest_state_7 string enable
NAME TYPE VALUE
log_archive_dest_state_8 string enable
log_archive_dest_state_9 string enable
log_archive_duplex_dest string
log_archive_format string %t_%s_%r.dbf
log_archive_local_first boolean TRUE
log_archive_max_processes integer 2
log_archive_min_succeed_dest integer 1
log_archive_start boolean FALSE
log_archive_trace integer 0
remote_archive_enable string true
standby_archive_dest string ?/dbs/arch
Regards .....

Do you have any other DBs with the same DBID as the one you are backing up? Are they connect to the same RMAN catalog?
Iordan Iotzov
http://iiotzov.wordpress.com/

Best tactic to migrate recovery catalog

Similar Messages

Maybe you are looking for