1 2 3 Previous Next 41 Replies Latest reply: May 15, 2013 3:33 AM by okKarol RSS

    RMAN-05501: aborting duplication of target database

    okKarol
      Hi,

      I've a little problem with my Standby duplication.
      The stupif thing is I've created the standby with this script firts time and after I decided to recreate in a diferent folder
      and since then I get this Error message in the end of the process.


      starting media recovery

      archived log for thread 1 with sequence 13143 is already on disk as file /archives/CMOVP/archivelogs/1_13143_810397891.arc
      archived log for thread 1 with sequence 13144 is already on disk as file /archives/CMOVP/archivelogs/1_13144_810397891.arc
      archived log for thread 1 with sequence 13145 is already on disk as file /archives/CMOVP/archivelogs/1_13145_810397891.arc
      archived log for thread 1 with sequence 13146 is already on disk as file /archives/CMOVP/archivelogs/1_13146_810397891.arc
      archived log file name=/archives/CMOVP/archivelogs/1_13143_810397891.arc thread=1 sequence=13143
      released channel: prm1
      released channel: stby1
      RMAN-00571: ===========================================================
      RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
      RMAN-00571: ===========================================================
      RMAN-03002: failure of Duplicate Db command at 05/01/2013 23:39:32
      RMAN-05501: aborting duplication of target database
      RMAN-03015: error occurred in stored script Memory Script
      ORA-00283: recovery session canceled due to errors
      RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
      ORA-00283: recovery session canceled due to errors
      ORA-00354: corrupt redo log block header
      ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
      ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'


      I've followed all steps to create the standby, as I said, I've created a first time

      What did change the second time is I insert the following parameters in my init.ora

      db_file_name_convert='/oradata/oradata/cmovelprodco/cmovelprodco','/oradata/oradata/cmovelproddr/cmovelproddr'
      LOG_FILE_NAME_CONVERT='/oradata/oradata/cmovelprodco/cmovelprodco','/oradata/oradata/cmovelproddr/redolog'


      The script I run to duplicate the db:

      run
      {
      allocate channel prm1 type disk;
      allocate auxiliary channel stby1 type disk;
      DUPLICATE TARGET DATABASE
      FOR STANDBY
      FROM ACTIVE DATABASE
      DORECOVER
      NOFILENAMECHECK;
      }

      But every time I got this archivelog corruption,
      But When I Validate the archives (Validate archivelog all) they are [OK]

      Any clues ?
      Thxs for your help
        • 1. Re: RMAN-05501: aborting duplication of target database
          Mahir M. Quluzade
          okKarol wrote:
          Hi,

          I've a little problem with my Standby duplication.
          The stupif thing is I've created the standby with this script firts time and after I decided to recreate in a diferent folder
          and since then I get this Error message in the end of the process.


          starting media recovery

          archived log for thread 1 with sequence 13143 is already on disk as file /archives/CMOVP/archivelogs/1_13143_810397891.arc
          archived log for thread 1 with sequence 13144 is already on disk as file /archives/CMOVP/archivelogs/1_13144_810397891.arc
          archived log for thread 1 with sequence 13145 is already on disk as file /archives/CMOVP/archivelogs/1_13145_810397891.arc
          archived log for thread 1 with sequence 13146 is already on disk as file /archives/CMOVP/archivelogs/1_13146_810397891.arc
          archived log file name=/archives/CMOVP/archivelogs/1_13143_810397891.arc thread=1 sequence=13143
          released channel: prm1
          released channel: stby1
          RMAN-00571: ===========================================================
          RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
          RMAN-00571: ===========================================================
          RMAN-03002: failure of Duplicate Db command at 05/01/2013 23:39:32
          RMAN-05501: aborting duplication of target database
          RMAN-03015: error occurred in stored script Memory Script
          ORA-00283: recovery session canceled due to errors
          RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
          ORA-00283: recovery session canceled due to errors
          ORA-00354: corrupt redo log block header
          ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
          ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'


          I've followed all steps to create the standby, as I said, I've created a first time

          What did change the second time is I insert the following parameters in my init.ora

          db_file_name_convert='/oradata/oradata/cmovelprodco/cmovelprodco','/oradata/oradata/cmovelproddr/cmovelproddr'
          LOG_FILE_NAME_CONVERT='/oradata/oradata/cmovelprodco/cmovelprodco','/oradata/oradata/cmovelproddr/redolog'


          The script I run to duplicate the db:

          run
          {
          allocate channel prm1 type disk;
          allocate auxiliary channel stby1 type disk;
          DUPLICATE TARGET DATABASE
          FOR STANDBY
          FROM ACTIVE DATABASE
          DORECOVER
          NOFILENAMECHECK;
          }

          But every time I got this archivelog corruption,
          But When I Validate the archives (Validate archivelog all) they are [OK]

          Any clues ?
          Thxs for your help
          Your archived log is corrupted.
          Do you have backup of corrupted archived log?

          I think you can do following steps on primary side.
          RMAN> backup database; -- not plus archivelog
          RMAN> crosscheck archivelog all; 
          RMAN> delete archivelog all; 
          RMAN>run
          {
          allocate channel prm1 type disk;
          allocate auxiliary channel stby1 type disk;
          DUPLICATE TARGET DATABASE
          FOR STANDBY
          FROM ACTIVE DATABASE
          NOFILENAMECHECK;
          }
          
          
          Paste result please.
          
          Regards
          Mahir M. Quluzade                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    
          • 2. Re: RMAN-05501: aborting duplication of target database
            okKarol
            The archivelog is not Corrupted.

            When I validate m archivelogs on Primary Site
            RMAN > crosscheck archivelog all;
            RMAN> validate archivelog all;

            I Get the REsult : [OK]
            for tall archives log including that one which is causing problems.
            "archives/CMOVP/archivelogs/1_13143_810397891.arc"

            So how can it be possible ?

            Rgds
            Carlos
            • 3. Re: RMAN-05501: aborting duplication of target database
              Hemant K Chitale
              Are you running the VALIDATE ARCHIVELOG on the Primary or on the Auxiliary ?

              The "ORA-00354: corrupt redo log block header" error is being reported at the standby.


              Hemant K Chitale
              • 4. Re: RMAN-05501: aborting duplication of target database
                okKarol
                I Validate the archivelogs on Primary Site before start doing the duplication.

                The Error appears in the end of the duplication Process when it starts doing the "DORECOVER"

                starting media recovery

                archived log for thread 1 with sequence 13143 is already on disk as file /archives/CMOVP/archivelogs/1_13143_810397891.arc
                archived log for thread 1 with sequence 13144 is already on disk as file /archives/CMOVP/archivelogs/1_13144_810397891.arc
                archived log for thread 1 with sequence 13145 is already on disk as file /archives/CMOVP/archivelogs/1_13145_810397891.arc
                archived log for thread 1 with sequence 13146 is already on disk as file /archives/CMOVP/archivelogs/1_13146_810397891.arc
                archived log file name=/archives/CMOVP/archivelogs/1_13143_810397891.arc thread=1 sequence=13143
                released channel: prm1
                released channel: stby1
                RMAN-00571: ===========================================================
                RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
                RMAN-00571: ===========================================================
                RMAN-03002: failure of Duplicate Db command at 05/01/2013 23:39:32
                RMAN-05501: aborting duplication of target database
                RMAN-03015: error occurred in stored script Memory Script
                ORA-00283: recovery session canceled due to errors
                RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                ORA-00283: recovery session canceled due to errors
                ORA-00354: corrupt redo log block header
                ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'

                I've tried to start the Recovery process manually in the standby site doing :
                SQL>alter database recover managed standby database;

                It stops exactly with same error message.

                But If I manually transfert the archivelog "1_13143_810397891.arc" from the Primary site to the Standby site and re-run the recovery it apply the log
                but gives me the same error (Corrupted log) with the next log "1_13144_810397891.arc" !!!!!

                How do we understand this!!!!

                Edited by: okKarol on May 2, 2013 2:04 AM
                • 5. Re: RMAN-05501: aborting duplication of target database
                  Hemant K Chitale
                  You've copied the archivelogs to the standby (auxiliary) site ? Any chance that the file got corrupted during the copy ?

                  (e.g. one common error is executing an FTP in ASCII mode instead of BINARY mode, resulting in a corrupt file)

                  Hemant K Chitale
                  • 6. Re: RMAN-05501: aborting duplication of target database
                    okKarol
                    No,
                    The files are copied automatically when running the duplication command below :
                    RMAN>
                    run
                    {
                    allocate channel prm1 type disk;
                    allocate auxiliary channel stby1 type disk;
                    DUPLICATE TARGET DATABASE
                    FOR STANDBY
                    FROM ACTIVE DATABASE
                    DORECOVER
                    NOFILENAMECHECK;
                    };
                    • 7. Re: RMAN-05501: aborting duplication of target database
                      Hemant K Chitale
                      oh. Didn't see that you were running "FROM ACTIVE DATABASE" It should be copying the Archivelogs as required.

                      Hemant K Chitale
                      • 8. Re: RMAN-05501: aborting duplication of target database
                        Mahir M. Quluzade
                        It means : 1_13144_810397891.arc archived log is corrupted.

                        Can you paste here on both side ?
                         select max(sequence#)  from v$archived_log; 
                        Is transport service runnig?

                        If duplicate finished success, I think not need 1_13144_810397891.arc archived log for standby database.

                        Mahir M. Quluzade
                        • 9. Re: RMAN-05501: aborting duplication of target database
                          okKarol
                          Here's what I get from my Alert.log in the Secondary Site :

                          .
                          .
                          .
                          alter database recover if needed
                          standby start until change 1524266570
                          Media Recovery Start
                          started logmerger process
                          Wed May 01 23:39:29 2013
                          Managed Standby Recovery not using Real Time Apply
                          Parallel Media Recovery started with 8 slaves
                          ORA-279 signalled during: alter database recover if needed
                          standby start until change 1524266570
                          ...
                          alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                          Media Recovery Log /archives/CMOVP/archivelogs/1_13143_810397891.arc
                          Incomplete read from log member '/archives/CMOVP/archivelogs/1_13143_810397891.arc'. Trying next member.
                          Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc (incident=320315):
                          ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                          ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                          Incident details in: /app/oracle/diag/rdbms/cmovpdg/CMOVP/incident/incdir_320315/CMOVP_pr00_4486_i320315.trc
                          Recovery interrupted!
                          Media Recovery failed with error 354
                          Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc:
                          ORA-00283: recovery session canceled due to errors
                          ORA-00354: corrupt redo log block header
                          ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                          ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                          Slave exiting with ORA-283 exception
                          Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc:
                          ORA-00283: recovery session canceled due to errors
                          ORA-00354: corrupt redo log block header
                          ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                          ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                          ORA-283 signalled during: alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'...
                          Wed May 01 23:39:32 2013
                          Sweep [inc][320315]: completed
                          Wed May 01 23:39:32 2013
                          Dumping diagnostic data in directory=[cdmp_20130501233932], requested by (instance=1, osid=4486 (PR00)), summary=[incident=320315].
                          Thu May 02 00:39:33 2013
                          • 10. Re: RMAN-05501: aborting duplication of target database
                            Mahir M. Quluzade
                            okKarol wrote:
                            Here's what I get from my Alert.log in the Secondary Site :

                            .
                            .
                            .
                            alter database recover if needed
                            standby start until change 1524266570
                            Media Recovery Start
                            started logmerger process
                            Wed May 01 23:39:29 2013
                            Managed Standby Recovery not using Real Time Apply
                            Parallel Media Recovery started with 8 slaves
                            ORA-279 signalled during: alter database recover if needed
                            standby start until change 1524266570
                            ...
                            alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                            Media Recovery Log /archives/CMOVP/archivelogs/1_13143_810397891.arc
                            Incomplete read from log member '/archives/CMOVP/archivelogs/1_13143_810397891.arc'. Trying next member.
                            Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc (incident=320315):
                            ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                            ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                            Incident details in: /app/oracle/diag/rdbms/cmovpdg/CMOVP/incident/incdir_320315/CMOVP_pr00_4486_i320315.trc
                            Recovery interrupted!
                            Media Recovery failed with error 354
                            Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc:
                            ORA-00283: recovery session canceled due to errors
                            ORA-00354: corrupt redo log block header
                            ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                            ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                            Slave exiting with ORA-283 exception
                            Errors in file /app/oracle/diag/rdbms/cmovpdg/CMOVP/trace/CMOVP_pr00_4486.trc:
                            ORA-00283: recovery session canceled due to errors
                            ORA-00354: corrupt redo log block header
                            ORA-00353: log corruption near block 2048 change 1524092704 time 05/01/2013 22:18:20
                            ORA-00334: archived log: '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                            ORA-283 signalled during: alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'...
                            Wed May 01 23:39:32 2013
                            Sweep [inc][320315]: completed
                            Wed May 01 23:39:32 2013
                            Dumping diagnostic data in directory=[cdmp_20130501233932], requested by (instance=1, osid=4486 (PR00)), summary=[incident=320315].
                            Thu May 02 00:39:33 2013
                            Did you try ?
                            alter database recover logfile '/archives/CMOVP/archivelogs/1_13143_810397891.arc'
                            Mahir
                            • 11. Re: RMAN-05501: aborting duplication of target database
                              Hemant K Chitale
                              You can run "cksum <filename>" to compute the checksums of the same file on both sites and compare the checksums. If they are different, it would mean that the archivelog file is getting corrupted in the transfer.


                              Hemant K Chitale
                              • 12. Re: RMAN-05501: aborting duplication of target database
                                Mahir M. Quluzade
                                I think you can use following steps.

                                1. Remove corrupted file from OS, on standby side.
                                2. Start MRP (Media Recovery Process) Redo Apply process
                                  SQL> alter database recover managed standby database disconnect from session;
                                 
                                3. If need this corrupted archived redo log, then standby will request this archive log from primary database.
                                4. Transport Service (ARCH) will transport this archived log form primary (if this archived log is not corrupted on primary)


                                Regards
                                Mahir M. Quluzade
                                • 13. Re: RMAN-05501: aborting duplication of target database
                                  okKarol
                                  1. Remove corrupted file from OS, on standby side.
                                  >> R: But there ar no corrputed logfiles in standby site

                                  2. Start MRP (Media Recovery Process) Redo Apply process
                                  R: I start the MRP process but only manually copy of archivelogs are applied.
                                  When the copy are made by Dataguard process the recovery process stop and I can check the DGMGRL :
                                  Redo apply stopped$
                                  SQL> alter database recover managed standby database disconnect from session;
                                  Done
                                  3. If need this corrupted archived redo log, then standby will request this archive log from primary database.
                                  R: That's the case
                                  4. Transport Service (ARCH) will transport this archived log form primary (if this archived log is not corrupted on primary)
                                  Yes in fact, but when the log is tranfered using this process the standby does not apply the log with error : Log Corrupted
                                  • 14. Re: RMAN-05501: aborting duplication of target database
                                    Mahir M. Quluzade
                                    okKarol wrote:
                                    1. Remove corrupted file from OS, on standby side.
                                    R: But there ar no corrputed logfiles in standby site
                                    2. Start MRP (Media Recovery Process) Redo Apply process
                                    R: I start the MRP process but only manually copy of archivelogs are applied.
                                    When the copy are made by Dataguard process the recovery process stop and I can check the DGMGRL :
                                    Redo apply stopped$
                                    SQL> alter database recover managed standby database disconnect from session;
                                    Done
                                    3. If need this corrupted archived redo log, then standby will request this archive log from primary database.
                                    R: That's the case
                                    4. Transport Service (ARCH) will transport this archived log form primary (if this archived log is not corrupted on primary)
                                    Yes in fact, but when the log is tranfered using this process the standby does not apply the log with error : Log Corrupted
                                    If log is corrupted, then transport service is cannot transport this archived log.
                                    You have 2 case, #1 when you have archived log backup, restore archived log form backup.
                                    #2 Manually redo gap resolution.

                                    Can you paste here:
                                     select max(Sequence#) from  v$archvied_log;  -- on both 
                                     select max(Sequence#) from  v$archvied_log where applied = 'YES'; -- on standby 
                                    
                                     select process  from  v$managed_standby; - on both 
                                    
                                     select error from  v$archive_dest;  -- on primary 
                                     select *  from  v$archive_gap; -- on standby
                                     
                                     select *  from v$dataguard_status; - on both
                                    Regards
                                    Mahir M. Quluzade
                                    1 2 3 Previous Next