Results 1 to 4 of 4
  1. #1
    Join Date
    Sep 2008
    Posts
    41

    Red face Unanswered: Different DBNAME, same DBID "accident" - RMAN HELP - RMAN-20004

    FYI, already logged this with Oracle Support, but I know responses from the FORUM are a lot quicker ...

    Not really sure what to do next or what I should have done instead. I think the loooonnnng hours must have affected my way of thinking ... aaarrrggghhh

    Sequence of events as below:

    01. Catalog DB = C01
    02. Database DB02 was cloned from DB01 using RMAN duplicate and connecting to DB01 as nocatalog
    03. DB02 RMAN duplicate was not a total successful, but we are able to OPEN RESETLOGS DB02
    04. We ran a RMAN backup of DB02 using the RMAN catalog C01 which is successful.
    SIDEBAR:
    - We think this is when the problem started. Had this backup failed, we wouldm't be having this problem
    - At this stage, the database name is the same but the DBID are the same, which we failed to notice until
    the DB01 backup started
    05. FYI, DB01 and DB02 uses the same RMAN catalog C01
    06. Now DB01 started to fail with errors below:

    RMAN-00571: ================================================== =========
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ================================================== =========
    RMAN-03002: failure of backup command at 09/25/2009 20:33:31
    RMAN-03014: implicit resync of recovery catalog failed
    RMAN-06004: ORACLE error from recovery catalog database: RMAN-20004: target database name does not match name in recovery catalog
    RMAN>

    07. We checked DB02 and found out that the DBID for DB01 and DB02 are the same.
    08. We shutdown DB02 and generate a new DBID for DB02 using NID, re-register DB02 to C01, now DB02 is backing up with the new DBID
    09. DB01 still cannot do backup to C01, we tried to resync the catalog, but that fails as well
    10. As a last resort, we then decided to unregister the DB01 database and re-register database. This works, but unfortunately, by doing this,
    we lost some of our older backup information that we may or may not need later.

    FYI, we noticed that if RMAN managed to complete the whole RMAN duplicate with no errors where it managed to stop and start the
    database, it generates a new DBID and create the TEMPFILE as well, but if it fails to do the recovery for any reason, like for
    example, missing archivelogs, it does not generate a new DBID. This is what we had failed to verify.

    ================================================== =============================
    Anyway, questions below please as some note to take note about for the future:
    ================================================== =============================

    Q01 - Can you please advise what we should have done instead, i.e. should we have connect to the catalog but to the DB02 target instead and then
    unregister DB02, then re-run the DB01 backup or should we have connected to the DB01 target but unregister database DB02 instead of just
    unregister database?

    Q02 - Is there any way to restore or re-catalog the backup information of the DB01 database if we are to restore an old backup of the
    C01 catalog and merge those old backup information that we require with the current backup information? We cannot restore the
    whole C01 catalog database as that C01 catalog database is shared amongst several databases as well, not just DB01 and DB02.

    Q03. - If we cannot re-catalog and sync the old and new backup information of DB01, we should still be able to restore to an old backup
    if we can restore an old copy of the RMAN catalog database as a new C02 database, is this a correct assumption?

    There should be no issue with the RMAN backup script and we cannot change the RMAN script anyway because that is generated by the Commvault Media Management layer. In any case, the RMAN script that it generates and run is as below:


    Code:
    Rman Script:
    [run {
    allocate channel ch1 type 'sbt_tape'
    PARMS="SBT_LIBRARY=/opt/galaxy/Base64/libobk.a(shr.o),BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1,ThreadCommandLine=BACKUP -jm 45 -a 2:1892 -cl 238 -ins 393 -at 22 -j 576865 -jt 576865:4:1 -bal 1 -bap 0 -rap 0 -rcp 0 -mav 0 -ms 1 -logs -cn gphlyaix03 -vm Instance001)"
    TRACE 0;
    setlimit channel ch1 maxopenfiles 8;
    sql "alter system archive log current";
     backup
     filesperset = 32
     diskratio = 0 (archivelog  all   delete input );
    }
    exit;
    ]
    Rman Log:[
    Recovery Manager: Release 11.1.0.6.0 - Production on Fri Sep 25 20:33:27 2009
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    RMAN>
    connected to recovery catalog database
    RMAN>
    connected to target database: HLYPKGP (DBID=3563923996)
    RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10>
    allocated channel: ch1
    channel ch1: SID=52 device type=SBT_TAPE
    channel ch1: CommVault Systems for Oracle: Version 7.0.0(Build76)
    sql statement: alter system archive log current
    Starting backup at 25-SEP-09
    current log archived
    released channel: ch1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of backup command at 09/25/2009 20:33:31
    RMAN-03014: implicit resync of recovery catalog failed
    RMAN-06004: ORACLE error from recovery catalog database: RMAN-20004: target database name does not match name in recovery catalog
    RMAN>
    Recovery Manager complete.
    ]

  2. #2
    Join Date
    Sep 2008
    Posts
    41
    Hi,

    FYI, reading thru the RMAN documentation and found an IMPORT command on Oracle11g. Will try that and hopefully that will work like it said on the manual.

    From what's written there, it looks like the one that I needed. Luckily this is Oracle11g I suppose ... :-)

    Wish me luck. Will keep everyone posted.

    Still no update from Metalink ... had asked them to raise it as SEV2.

    Found a Metalink Note of an example on using Oracle RMAN Import for 11g but it was very simple. So I think it is better to read the doc itself.

  3. #3
    Join Date
    Sep 2008
    Posts
    41
    Hi all,

    FYI, this has now been fixed.

    The Oracle11g RMAN import command works like a charm using a restore of a backup of the catalog database prior to the problem. FYI, this is what I ended up doing:

    - Restore catalog to another database to point-in-time prior to the problem
    - Connect to the LIVE catalog and unregister the database
    - Still on the LIVE catalog, run RMAN import from the restored catalog database, knock on wood, cross your toes and fingers, import reported successful
    - Run list backup, I got my old backup information including the current ones, so I assume the import also did the resync
    - Run FULL database backup, all good ...

    Boy was I lucky, all this started because of that RMAN UNTIL TIME cloned not managing to do the full recovery in the process. I will post that story later on ...

    FYI, still no word from Oracle Support ... I even got a quicker response or advice from another DBA forum !!!

  4. #4
    Join Date
    Jul 2003
    Posts
    2,296
    FYI - you really don't need the catalog.
    All you need is a controlfile (ie: a controlfile backup from any point in time).
    With a controlfile it knows what backups have occurred and the backup names.
    - The_Duck
    you can lead someone to something but they will never learn anything ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •