RE: Duplicate fails with ORA-01194
Date: Wed, 25 May 2016 03:44:12 +0000
Message-ID: <2FE2AA1C5F8DEC478F58DF8DD32BA6370CECFED9_at_HKWPIPXMB03C.zone1.scb.net>
>> but strangely one older log from the target is also applied
Which one ? What are the SEQUENCE#, FIRST_TIME and NEXT_TIME for the "older log" ?
Is SEQUENCE# 136279 really generated after the backup of the last datafile ? Can you check the FIRST_TIME and NEXT_TIME for it and relate to the datafile backup ?
Hemant K Chitale
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of De DBA
Sent: Tuesday, May 24, 2016 6:06 PM
To: oracle-l_at_freelists.org
Subject: Duplicate fails with ORA-01194
G'day.
I'm trying to duplicate a database from the active standby, but I keep running into "RMAN-06136: ORACLE error from auxiliary database: ORA-01194: file 1 needs more recovery to be consistent". As you can see below, I've raised an SR with Oracle about this, and we thought to have found it. The work-around was to place the archived log destination on a different disk group than the standby uses, so that the copy would not catalogue the archived logs of the target. Sadly, this seems to have been a fluke. When I ran the duplicate again today, the error resurfaced.
This is Oracle 11.2.0.4.5 (not patched for a while, I know), Active Data Guard on an ODA. The target is the standby database, which is open read-only with real-time apply. The auxiliary is to reside in the same ASM storage as the target. I know that it is possible, I've done it many times before without a hitch on stand-alone servers.
The duplicate fails in the recovery phase with this output:
<snip>
Starting recover at 24-05-2016 12:35
starting media recovery
archived log for thread 1 with sequence 136278 is already on disk as file +RECO/target-SB/archivelog/2016_05_24/thread_1_seq_136278.3066.912686281
archived log for thread 1 with sequence 136279 is already on disk as file +DATA/auxDB/archivelog/2016_05_24/thread_1_seq_136279.443.912688537
...
archived log file name=+RECO/target-SB/archivelog/2016_05_24/thread_1_seq_136278.3066.912686281 thread=1 sequence=136278
archived log file name=+DATA/auxDB/archivelog/2016_05_24/thread_1_seq_136279.443.912688537 thread=1 sequence=136279
...
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+RECO/auxDB/datafile/system.10055.912688507'
</snip>
All copied archived logs are applied without error, but strangely one older log from the target is also applied. This is the first place in the log where this particular log appears. It is not even mentioned in the cataloguing phase.
This is the procedure I use (it is part of a shell script - the ${} variables are never seen by RMAN):
connect target ${SYSUSER}@${__SOURCE} connect auxiliary ${SYSUSER}_at_${__REFRESH:-${__MASK}}
run{
allocate channel c1 device type disk;
allocate channel c2 device type disk;
allocate channel c3 device type disk;
allocate channel c4 device type disk;
allocate channel c5 device type disk;
allocate channel c6 device type disk;
allocate channel c7 device type disk;
allocate channel c8 device type disk;
allocate channel c9 device type disk;
allocate channel c0 device type disk;
allocate auxiliary channel a1 device type disk;
allocate auxiliary channel a2 device type disk;
allocate auxiliary channel a3 device type disk;
allocate auxiliary channel a4 device type disk;
allocate auxiliary channel a5 device type disk;
allocate auxiliary channel a6 device type disk;
allocate auxiliary channel a7 device type disk;
allocate auxiliary channel a8 device type disk;
allocate auxiliary channel a9 device type disk;
allocate auxiliary channel a0 device type disk;
duplicate
target database
to ${__REFRESH:-${__MASK}}
from active database
spfile
parameter_value_convert ( '${__SOURCE}' , '${__REFRESH:-${__MASK}}' )
set control_files = '+RECO', '+REDO'
set db_unique_name = '${__REFRESH:-${__MASK}}'
set db_create_file_dest = '+RECO'
set db_create_online_log_dest_1 = '+REDO'
####
# set db_recovery_file_dest = '+RECO'
# set db_recovery_file_dest_size = '100G'
## Work-around for bug 17877323 ORA-00600[krbi_init_fra_metadata_not_backup_ctl]: disable FRA
reset db_recovery_file_dest
reset db_recovery_file_dest_size
## SR3-12369406641: Workaround RMAN recover issue: dont use same dg as target for archived logs
## set log_archive_dest_1 = 'location=+RECO'
set log_archive_dest_1 = 'location=+DATA'
###
set local_listener = 'l_${__REFRESH:-${__MASK}}'
set parallel_degree_limit = 'IO'
set parallel_degree_policy = 'AUTO'
set parallel_adaptive_multi_user = 'FALSE'
set memory_target = '3G'
reset sga_target
reset sga_max_size
reset pga_aggregate_target
reset shared_pool_reserved_size
reset log_archive_config
reset log_archive_dest_2
reset log_archive_dest_state_2
reset log_archive_format
reset fal_server
reset dg_broker_start
reset use_large_pages
;
}
exit
___
Any thoughts?
Cheers,
Tony
-- http://www.freelists.org/webpage/oracle-l This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https://www.sc.com/en/incorporation-details.html †Ûiÿü0ÁúÞzX¬¶Ê+ƒü n– {ú+iÉ^Received on Wed May 25 2016 - 05:44:12 CEST