I am planning a migration for this ancient-but-critical Oracle database from one Windows Server 2003 cluster to another.

The database has many data files and they are all getting new paths on the destination cluster. The only paths that are staying the same are for the backup files.

The migration plan I have is as follows:

  1. Backup the database on the source cluster using our nightly RMAN backup script:

    run {  
        allocate channel Channel1 type disk format 'F:\backup\folder\%d_%T_%s_%U.bak';
        allocate channel Channel2 ... 
        backup check logical ( database );
        backup check logical ( archivelog all  not backed up 2 times );
        backup check logical ( current controlfile );
    allocate channel for maintenance device type disk;
    delete archivelog until time 'sysdate - 2' backed up 2 times to disk;
    delete obsolete device type disk;

    Our RMAN retention policy on both clusters is set to redundancy 2, and the control file is being used as the recovery catalog.

  2. Copy the backup files to F:\backup\folder on the destination cluster.

  3. Restore the database on the destination cluster using this RMAN script:

    run {
        allocate channel Channel1 type disk;
        allocate channel Channel2 ...
        set until sequence <sequence number> thread 1;
        restore database;
  4. Update the data file paths in the control file, recover the database to the appropriate sequence, and open it with resetlogs.

This works great with the following exception:

When I ask RMAN to delete obsolete files on the destination cluster, it names all of the just-restored data files as obsolete!

RMAN> delete obsolete device type disk;
Deleting the following obsolete backups and copies:
Type                 Key    Completion Time    Filename/Handle
-------------------- ------ ------------------ --------------------
Datafile Copy        1      02-JUL-12          New\Path\FILE01.DBF

Well, RMAN is correct to recognize these data files as copies.

However, since this is a database migration, these copies are intended to be the new originals, so I certainly don't want RMAN to delete them as part of its maintenance!

Is it possible to tweak this migration process so that RMAN treats the restored database as the new original?

  • I am familiar with RMAN's DUPLICATE command and its possible utility in this scenario. If possible, I would like to avoid using it as I understand it imposes many restrictions and additional requirements. Commented Jul 2, 2012 at 23:51
  • Can you add show all and list backup summary RMAN output from the migrated DB please?
    – Philᵀᴹ
    Commented Jul 3, 2012 at 3:56
  • @Phil - Looks like Gaius's solution below did it for me. Was there anything in particular you were looking for in those outputs? Commented Jul 5, 2012 at 16:27
  • Nope - it's just always my first line of investigation when dealing with rman issues
    – Philᵀᴹ
    Commented Jul 5, 2012 at 16:37

1 Answer 1


Issue switch to copy, then crosscheck.

  • Ah, that looks to be what I need. Do I run the SWITCH after the restore but before the recover? Commented Jul 3, 2012 at 18:34
  • Without having tested it, mind, I would say yes
    – Gaius
    Commented Jul 4, 2012 at 15:46
  • 2
    Yep. I added a SWITCH DATAFILE ALL; after the RESTORE but before the RECOVER and that did exactly what I needed. Commented Jul 5, 2012 at 16:26
  • FYI: The "switch to copy" link is now dead. Commented Feb 7, 2017 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.