10.2.0.4 RMAN Fails on Recover Database on New Host
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: 10.2.0.4 RMAN Fails on Recover Database on New Host

Hybrid View

  1. #1
    Join Date
    Oct 2008
    Posts
    4

    10.2.0.4 RMAN Fails on Recover Database on New Host

    Hey all,

    I have been testing a script using RMAN to backup my Oracle Enterprise 10.2.0.4 databases at work. One of our objectives is to be able to backup one server, decommission the hardware, and restore the backup on a newer box. I have tried testing this process using other machines and I keep running into an issue.

    My restore script:
    Code:
    # rman target / nocatalog
    RMAN> run {
    RMAN> allocate channel ch 1 type disk;
    RMAN> alter database mount;
    RMAN> restore database;
    RMAN> recover database; }
    These steps work until recover database, which fails with:
    Code:
    ...
    starting media recovery
    
    archive log thread 1 sequence 372 is already on disk as file /u01/oradata/mael1/archive/1_372_685295039.dbf
    archive log thread 1 sequence 373 is already on disk as file /u01/oradata/mael1/archive/1_373_685295039.dbf
    archive log thread 1 sequence 374 is already on disk as file /u01/oradata/mael1/archive/1_374_685295039.dbf
    archive log filename=/u01/oradata/mael1/archive/1_372_685295039.dbf thread=1 sequence=372
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 05/08/2009 12:57:36
    ORA-00283: recovery session canceled due to errors
    RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/oradata/mael1/archive/1_372_685295039.dbf'
    ORA-00283: recovery session canceled due to errors
    ORA-00313: open failed for members of log group 1 of thread 1
    ORA-00312: online log 1 thread 1: '/u01/oradata/mael1/redo01.log'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    If I copy the redo##.log files from the source database to the new database, this recover step works flawlessly. However, it seems to me that this should work without having to manually copy these files over. For instance, what if I were faced with a true hardware failure? Is there something wrong with how I'm taking the backups or restoring the backups? I'm very new to using RMAN, so any tips would be appreciated.

    My backup script:
    Code:
    # Backup spfile
    BACKUP
    DEVICE TYPE DISK
    TAG = 'MONTHLY_FULL_SP'
    FORMAT '/u02/backup/monthly_full_sp_%U'
    SPFILE;
    
    # Backup database and archivelogs
    BACKUP
    INCREMENTAL LEVEL = 0
    DEVICE TYPE DISK
    TAG = 'MONTHLY_FULL_DATABASE'
    FORMAT '/u02/backup/monthly_full_database_%U'
    DATABASE;
    
    # full archivelog backup
    change archivelog all validate;
    sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
    
    BACKUP
    TAG = 'MONTHLY_ARCHIVELOG'
    FORMAT '/u02/backup/monthly_full_archivelog_%U'
    ARCHIVELOG ALL DELETE ALL INPUT;
    
    # Remove old backups
    DELETE BACKUP COMPLETED BEFORE 'SYSDATE-28' DEVICE TYPE DISK;
    DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-3';
    
    #*** Maintenance steps
    CROSSCHECK COPY;
    CROSSCHECK BACKUP;
    CROSSCHECK ARCHIVELOG ALL;
    DELETE NOPROMPT OBSOLETE;
    DELETE NOPROMPT EXPIRED COPY;
    DELETE NOPROMPT EXPIRED BACKUP;
    DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
    
    BACKUP
    DEVICE TYPE DISK
    TAG = 'MONTHLY_FULL_CONTROL'
    FORMAT '/raidman6/oraprod02Backup/monthly_full_control_%U'
    CURRENT CONTROLFILE;
    
    EXIT;
    Thanks!

  2. #2
    Join Date
    Sep 2002
    Location
    England
    Posts
    7,333
    you have told it to recover the database, it expects ALL files to be able to recover

    If you dont want that you need to specify a point to recover too

  3. #3
    Join Date
    Oct 2008
    Posts
    4
    Shouldn't it be able to recover all files up to the last backup? In this situation the source server was fine through the completion of the previous night's backup.

    Then I'm faking the catastrophic failure and trying to reload the database elsewhere, so I would expect that it should be able to reload all of the files up to the backup time, right?

  4. #4
    Join Date
    Apr 2009
    Posts
    21
    If I copy the redo##.log files from the source database to the new database, this recover step works flawlessly. However, it seems to me that this should work without having to manually copy these files over. For instance, what if I were faced with a true hardware failure? Is there something wrong with how I'm taking the backups or restoring the backups? I'm very new to using RMAN, so any tips would be appreciated.
    If you don't want to copy the redo logs over to the destination server, you'll have to rename all your redo logs before you run your rman restore:

    for example:

    sql> alter database rename file '/u03/oradata/orcl/redoa1.log' to '/u03/oradata/orcl/redoa1.log';

  5. #5
    Join Date
    Sep 2002
    Location
    England
    Posts
    7,333
    Quote Originally Posted by revzalot View Post
    If you don't want to copy the redo logs over to the destination server, you'll have to rename all your redo logs before you run your rman restore:

    for example:

    sql> alter database rename file '/u03/oradata/orcl/redoa1.log' to '/u03/oradata/orcl/redoa1.log';
    what?

    to the OP - you have asked the database to include them, if you dont want to - choose the right retore commands

  6. #6
    Join Date
    Apr 2009
    Posts
    21
    I have done a successful rman restore on a new host based on this link:

    http://www.dba-oracle.com/t_rman_clo...y_database.htm

    Step 9 is what I'm talking regarding redo logs are not needed during an RMAN restore. I hope this clarifies my previous post.

  7. #7
    Join Date
    Sep 2002
    Location
    England
    Posts
    7,333
    that step has nothing to do with the OP's problem

Posting Permissions

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


Click Here to Expand Forum to Full Width