Duplicate failed

Duplicate failed with below error.
The catalog database is up and running
"rman_Dup_full.log_DEVDB_2013-01-20_21_11_32" 1600 lines, 71681 characters
switch clone datafile all;
RMAN-08162: executing Memory Script
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 01/20/2013 06:36:34
RMAN-03015: error occurred in stored script Memory Script
RMAN-06004: ORACLE error from recovery catalog database: ORA-03114: not connected to ORACLE
RMAN-06004: ORACLE error from recovery catalog database: ORA-03114: not connected to ORACLE

Please provide the full script of duplication, and also check the SQLNET.EXPIRE_TIME value to be configured less than TCP/IP time out on the firewall If catalog database is connected over network, check with System administrator
Naga

Similar Messages

RMAN duplicate failed

Hi all,
have below doubts.
IF RMAN duplicate failed in the middle of the process due to disk full or any other reason.
Do I start from the beginning again or is there anyway to sort of "resume" from where it stopped?
Please consider what need to do in 9i or in 10G.
Please also reply what need to do for FS or for ASM.
Please also share if you have any doc or link.

Hi,
IF RMAN duplicate failed in the middle of the process due to disk full or any other reason.See always perform fresh duplicate.
it will overwrite the existing files... so you need to check in alert log file like how many files restored & recovered during duplicate..
sybrand_b wrote:
Duplicate database is a quite robust command.
It will automatically skip what has already been done, so you can safely re-execute it without problems.
Been there, done that.
Sybrand Bakker
Senior Oracle DBA@sybrand
What it automatically skips?
1)did RMAN duplicate knows about earlier restores...
2)if i restored system,sysaux,users,undo datafiles of another database and again I'm performing another database in same location.. so it will skip?
are you sure...
Thanks
*Manual Completion of a Failed RMAN Duplicate [ID 360962.1]*
Edited by: CKPT on Dec 11, 2010 12:40 PM

DUPLICATE fails after recovery due to ORA-01861

I issued the following duplicate command:
DUPLICATE TARGET DATABASE TO dev2 UNTIL TIME '2006-09-16 04:30:00';It actually goes through the 8-hour task of restoring datafiles and recovering from archive logs. It then creates the control file and then executes the SET NEWNAME commands when it fails with this error
executing command: SET NEWNAME
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 09/18/2006 08:17:07
RMAN-03015: error occurred in stored script Memory Script
ORA-01861: literal does not match format stringThe only possible cause I can think of is that, as of 16 Sep 2006, I hadn't yet set my NLS_DATE_FORMAT parameter. It is now set (to YYYY-MM-DD HH24:MI:SS) so that I can specify the date format for my PITR duplication.
Does my diagnosis make any sense? If I unset NLS_DATE_FORMAT and say UNTIL TIME '16-SEP-06' does that mean '16-SEP-06 00:00:00'? That would work for me as well. However since each failed attempt means 8 hours lost I'd like to know that kind of thing ahead of time, and if my diagnosis is even correct.

Normally we do have two senarios while cloning. One, you clone to an existing instance by removing the control and datafiles. Two, take a copy of spfile from target DB and clone to auxiliary DB. In the first case there can be chances that NLS is different than your target. But in second case it will be same because you are cloning from one parent setting.
In your case if I am not wrong it was the first scenario ( This scenario I normally face in my UAT database clones when cloning from production). Its always better to keep same NLS but some situations u cant do that. In that case you can use “to_date” and it’s a very well proven method.
And your question why your clone failed after all the restore operation. I personally think the database when tried to reset your logs after restoration it found format difference and shouted about that. As simple as that.

LR 4.2: "Don't import suspected duplicates" fails repeatedly

After import from CF card, then next import with "don't import suspected duplicates'' checked, failed many times. You must close and reopen the import window, repeating the operation (one or two times) to make it work properly.

Victoria Bampton wrote:
CuriousBystander wrote:
So what you are saying is this:
if filename equals "existing" AND date/time equals "existing" AND file size equals "existing" THEN its a match.
Yep. And I agree it needs to be better. You might want to add a feature request at the Official Feature Request/Bug Report Forum
At the risk of necroing a thread, I want to disagree that "it needs to be better" if that translates to "ignores files with small differences in the filename but otherwise the same." From the standpoint of file management, we never, ever want software thinking about this too much. I have encountered multiple situations where i was able to recover from a corrupt file precisely because the software was extremely strict on what it considered to be a duplicate. Put differently, it does not hurt us to have two copies of an important photo, while it can be devastating to have no copies—or one corrupted copy—of an important photo. When importing hundreds or thousands of shots, we absolutely want Lightroom insisting that filename, sixe, and capture date/time be identicial to be considered a duplicate. Otherwise, we want these sorts of decisions left to us. After all, there is a reason that file is different, and it could well be that an atuomated process elsewhere failed and two copies of photo allows us to choose what was the correct image to retain.
Again, sorry for the necro, but I felt this needed to be said.

BUG: "Don't Import Suspected Duplicates" FAILS for two identical files (same name, same MD5)

Using LR 4.4, I'm seeing duplicate files not detected when the files have the same name and identical content (same MD5).
Adobe support takes me here, although I'd rather file a bug.
I've isolated a small test case where I have a directory with a small number of images (taken at the same time with the same camera.)
I can copy this directory to a different location, then try to import it and one of the files will not be detected as a dupe.
I've tried re-reading the metadata for the existing library file.
Files have the same name and same checksums.

According to the Lightroom documentation
Lightroom determines a photo is a duplicate of another file in the catalog if it has the same, original filename; the same Exif capture date and time; and the same file size
Please confirm that your "duplicate" files meet this criterion

Point in Time Duplicate failing

Attempting to Duplicate database from a backup taken 3 weeks ago and received the following:
printing stored script: Memory Script
switch clone datafile all;
executing script: Memory Script
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/26/2009 14:19:14
RMAN-03015: error occurred in stored script Memory Script
RMAN-00600: internal error, arguments [7002] [0] [7886] [] []
RMAN command looks like:
RMAN> run
2> {
3> set until time "to_date('08-10-2009 15:00:00','dd-mm-yyyy hh24:mi:ss')";
4> duplicate target database to <aux db>;
5> }
haven't seen much info on the above error... Just looking for a next step.
Thanks

Primary:
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 3600
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS_1
SQL> select * from dba_data_files where file_id = 14;
FILE_NAME
FILE_ID TABLESPACE_NAME BYTES BLOCKS STATUS
RELATIVE_FNO AUT MAXBYTES MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS
/u02/oradata/vprd2/undotbs_1.dbf
14 UNDOTBS_1 2097152000 256000 AVAILABLE
14 YES 3.4360E+10 4194302 1 2097086464 255992
Oracle version is 9.2.0.4
I believe I have followed the procedures correctly. db_file_name_convert and log_file_name_convert parameters are set on auxiliary db:
Auxiliary:
SQL> show parameter convert
NAME TYPE VALUE
db_file_name_convert string /u02/oradata/vprd2, /u02/orada
ta/vcost
log_file_name_convert string /u03/redo/vprd2, /u02/oradata/
vcost, /u02/oradata/vprd2, /u0
2/oradata/vcost
I am trying to restore from backup taken on October 8th. Full backup on October 2nd, Incrementals nightly and archive log backups hourly from primary.
Only problem with duplicate is with the alter database open resetlogs.

RMAN DUPLICATE FAIL

hi guru's
i am duplicating database using RMAN from ORCL to DUP
i having the following error
RMAN-03002: failure of Duplicate Db command at 11/05/2007 11:38:34
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
i used the command for duplicate as follows
DUPLICATE TARGET DATABASE TO DUP;
please help me....gurus

hi,
I assume you are using a recovery catalog?
Have you created proper password files on both servers?
what connection string are you using to connect to the recovery catalog
something similar to
connect to the recovery catalog as follows: -
rman catalog_name rman/password@rman_name target system/password auxiliary internal/chef@$SID
regards
ALan

Look for duplicates fails

From various merges I have done, i have about a thousand(s) duplicates in my address book that I am trying to zap. When I run the look for duplicates feature, it searches for a while but eventually the whole thing crashes. I've tried about 20 different times to run it.
Any advice?
Much appreciated.

Hello Caryn:
The only thing I can think of that might work is to trash a couple of preference files and restart:
com.apple.addressbook.plist
com.apple.addressbook.abd.plist
Barry

Open resetlogs after RMAN duplicate fails

Hi,
I wonder if anybody else has come across this issue, or is able to shed any light on it.
I have done a duplicate database to a new host with RMAN.
At the point where the duplicate opens the new database with resetlogs
I get this error in the alert log:
alter database open resetlogs
Tue Apr 7 02:10:06 2009
Errors in file /oracle/admin/udump/db1_ora_13931.trc:
ORA-00367: checksum error in log file header
ORA-00305: log 1 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 1 thread 1: '/oracle/oradata/redo/db1_REDO_01A.log'
additional info: Oracle 10.2.0.4, Linux o/s.
thanks.

i have used the logfile keyword in the duplicate script to tell the duplicate
location and size of redologs.
duplicate target database to db1
logfile
group 1 ('/oracle/oradata/redo/db1_REDO_01A.log'
,'/oracle/oradata/redo/db1_REDO_01B.log') SIZE 200M REUSE,
group 2 ('/oracle/oradata/redo/db1_REDO_02A.log'
,'/oracle/oradata/redo/db1_REDO_02B.log') SIZE 200M REUSE,
group 3 ('/oracle/oradata/redo/db1_REDO_03A.log'
,'/oracle/oradata/redo/db1_REDO_03B.log') SIZE 200M REUSE,
group 4 ('/oracle/oradata/redo/db1_REDO_04A.log
','/oracle/oradata/redo/db1_REDO_04B.log') SIZE 200M REUSE;
my thoughts are that the resetlogs will make automatically recreate the redo logs.
there were pre-existing ones in this location, but REUSE should overcome this issue?

Cleaning up ASM disk group after failed rman duplicate session?

I am using rman duplicate to create a clone of a production database. The rman duplicate failed in phase 1 (retoration of datafiles) and my datafile are being restored to an ASM diskgroup.
I read in the metalink note Manual Completion of a Failed RMAN Duplicate [ID 360962.1] the following...
Note : From 10g onwards, if duplicate failed during step 1, which is the restore of datafiles, it is probably best to restart the duplicate process. Any files that have already been restored will be skipped and the duplicate process can continue without manual intervention
So I followed the advice in the note and started the rman duplcate script over again from the beggining. I am hoping it will have the intelligence to skip any files that have already been restored but if it is not since this is 10.1.0.3 and I cannot use the asmcmd command to connect to the ASM instance to delete any files that have been created then how can I delete and of the files since the database instance never got created correctly and cannot open?
Any thought on how I can now cleanup the files in the ASM disk group? Also, has anyone started an rman duplicate again after it has previously failed and did it actually skip the files that are already there as stated in the metalink note?
Thanks.

Unfortunately the v$asm_file does not have the entire file name or path it just gives you the follwing...
SQL> desc v$asm_file
Name Null? Type
GROUP_NUMBER NUMBER
FILE_NUMBER NUMBER
COMPOUND_INDEX NUMBER
INCARNATION NUMBER
BLOCK_SIZE NUMBER
BLOCKS NUMBER
BYTES NUMBER
SPACE NUMBER
TYPE VARCHAR2(64)
REDUNDANCY VARCHAR2(6)
STRIPED VARCHAR2(6)
CREATION_DATE DATE
MODIFICATION_DATE
This really stinks I wish I didn't have to work with 10gr1 at all but the database I am trying to move to a ew server and new storage is running this version and we did not want to upgrade the existing database first before attempting the migration because it is reliant upon tape backups which I do not have alot of confidence in...

RMAN Restoration failed from ASM to non asm

While restoring the database, we are getting this error frequently, updated the media center they said media is intact, but there is some "NO POLICY" NO SCHEDULE" error. what does this mean.
Could some one please help us why and how to resolve this issue. We are stuck in between our restoration.
ORA-19870: error reading backup piece ROCT_rman_db_weekly_20110719_2jmhrat3_1_1
ORA-19507: failed to retrieve sequential file, handle="ROCT_rman_db_weekly_20110719_2jmhrat3_1_1", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
Failed to process backup file <ROCT_rman_db_weekly_20110719_2jmhrat3_1_1>

784786 wrote:
While restoring the database, we are getting this error frequently, updated the media center they said media is intact, but there is some "NO POLICY" NO SCHEDULE" error. what does this mean.
Could some one please help us why and how to resolve this issue. We are stuck in between our restoration.
ORA-19870: error reading backup piece ROCT_rman_db_weekly_20110719_2jmhrat3_1_1
ORA-19507: failed to retrieve sequential file, handle="ROCT_rman_db_weekly_20110719_2jmhrat3_1_1", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
Failed to process backup file <ROCT_rman_db_weekly_20110719_2jmhrat3_1_1>where is No policy/no schedule errors?
Error reading backup piece can occur even the handle was corrupt (or) handle was unable to read (or) did tapes loaded in MML ?
*RMAN Duplicate fails with ORA-19870, ORA-19507, ORA-27029 and ORA-19511 [ID 562780.1]*

Failure of duplicate - ORA -06054

Hi,
After a backup, we have a duplicate script running to copy it over to other server.
Sometimes, when there is extra activity on the db and the backup takes longer, the duplicate fails with this:
RMAN-03002: failure of Duplicate Db command at 04/08/2009 03:06:52
RMAN-03015: error occurred in stored script Memory Script
RMAN-06054: media recovery requesting unknown log: thread 1 seq 35238 lowscn5968228973373
Can someone explain the meaning of this error? Is it as simple as delaying the timing of the duplicate for much later in the morning ?
Thanks,
DA

The short answer is probably yes, you ought to be able to confirm by querying the primary for when that log was generated.
You don't say what your script actually does, but when I've done this in the past the duplicate has been
run {
set until time '<Some well known time eg 6am>'
duplicate target to ....
}rather than
run {
duplicate target to ....
}what then you need to watch out for is when the backup fails and you spend most of the day applying yesterdays archives to the duplicate!
Niall Litchfield
http://www.orawin.info/
Dan A wrote:
Hi,
After a backup, we have a duplicate script running to copy it over to other server.
Sometimes, when there is extra activity on the db and the backup takes longer, the duplicate fails with this:
RMAN-03002: failure of Duplicate Db command at 04/08/2009 03:06:52
RMAN-03015: error occurred in stored script Memory Script
RMAN-06054: media recovery requesting unknown log: thread 1 seq 35238 lowscn5968228973373
Can someone explain the meaning of this error? Is it as simple as delaying the timing of the duplicate for much later in the morning ?
Thanks,
DA

Database Refresh Failed

Hi All,
I am working on a database refresh and it failed with the following errors
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/15/2011 16:27:41
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 '/srv/database/arch2/1_65508_689972797.dbf'
ORA-00283: recovery session canceled due to errors
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 256 change 43879018791 time 04/12/2011 04:30:54
ORA-00334: archived log: '/srv/database/arch2/1_65508_689972797.dbf'
Do you have any idea of how to solve this error.
Please help.

Hi;
What is your OS? If its solaris than please see:
Duplicate Fails with Corruption Errors on Solaris QFS Filesystem [ID 764113.1]
Regard
Helios

"Segmentation fault" during tns rman active duplicate

Hello. I am trying to do an active duplicate using tns connectivity and just after restoring the controlfile the process fails with the error "Segmentation fault". However if I start the rman using Ezconnect everything goes smoothly. Restarting the databases did not help. What could be the reason? Here is the output with the error:
rman target sys/oracle@EN9 auxiliary sys/oracle@EN910
Recovery Manager: Release 11.2.0.3.0 - Production on Thu Jun 13 17:41:15 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: EN9 (DBID=529480944)
connected to auxiliary database: EN910 (not mounted)
RMAN> duplicate target database to EN910 from active database nofilenamecheck;
Starting Duplicate Db at 13-JUN-13
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=24 device type=DISK
contents of Memory Script:
   sql clone "alter system set control_files =
''+DATA/en910/controlfile/current.271.818012497'' comment=
''Set by RMAN'' scope=spfile";
   sql clone "alter system set db_name =
''EN9'' comment=
''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set db_unique_name =
''EN910'' comment=
''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   backup as copy current controlfile auxiliary format '+DATA/en910/controlfile/current.275.818012497';
   sql clone "alter system set control_files =
''+DATA/en910/controlfile/current.275.818012497'' comment=
''Set by RMAN'' scope=spfile";
   shutdown clone immediate;
   startup clone nomount;
   alter clone database mount;
executing Memory Script
sql statement: alter system set control_files =   ''+DATA/en910/controlfile/current.271.818012497'' comment= ''Set by RMAN'' scope=spfile
sql statement: alter system set db_name = ''EN9'' comment= ''Modified by RMAN duplicate'' scope=spfile
sql statement: alter system set db_unique_name = ''EN910'' comment= ''Modified by RMAN duplicate'' scope=spfile
Oracle instance shut down
Oracle instance started
Total System Global Area     242208768 bytes
Fixed Size                     2227176 bytes
Variable Size                184550424 bytes
Database Buffers              50331648 bytes
Redo Buffers                   5099520 bytes
Starting backup at 13-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK
channel ORA_DISK_1: starting datafile copy
copying current control file
Oracle instance started
Segmentation fault
tnsnames.ora of target db:
EN9 =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora9)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = EN9)
tnsnames.ora of aux db:
EN910 =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora10)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = EN910)
EN9 =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora9)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = EN9)
listener.ora of aux db:
SID_LIST_LISTENER =
        (SID_LIST =
                (SID_DESC =
                        (GLOBAL_DBNAME=EN910)
                        (ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)
                        (SID_NAME=EN910)

if you have access to MOS:
Rman Duplicate Fails With Segmentation Fault [ID 744717.1]
Rman Duplicate Failing With A Segmentation Fault [ID 1092423.1]

Duplicate database for standby from active database

I'm running 11.1.0.7. Has anybody ever duplicated a standby database from active database and the active database being a physical standby open for read only with active dataguard instead of a primary dataguard database?
The key here is location. The primary is located at a remote site where network bandwidth is inadequate for fast copy of database. The active standby database is at same site where I would like to build the new physical standby.

I don't think you can, because "You cannot CONNECT RMAN to the standby database and then use DUPLICATE ... FOR STANDBY to create an additional standby database " and you can't fake it out by getting a controlfile from the primary because the controlfile has to match up with the backup and can't be a standby.
But I'm wondering if you could failover to the standby, duplicate, fail back, then... oh well, that will never work either, incarnation problem.
Snapshot standby? Could one back it up, then flashback restored new standby, change dbid? I would guess there would be an SCN problem, but don't know enough about it.

Duplicate failed

Similar Messages

Maybe you are looking for