Standby db ORA-10567:

Hi,
We have data guard setup in 11.2 on aix.We got the following errors in standby db.
Media Recovery Log +P10_ARCHGROUP01/P10/arch/arch_1_1763_815128087.arc
Media Recovery Log +P10_ARCHGROUP01/P10/arch/arch_1_1764_815128087.arc
Mon Jun 03 13:10:49 2013
Primary database is in MAXIMUM PERFORMANCE mode
RFS[15]: Assigned to RFS process 63504552
RFS[15]: Selected log 9 for thread 1 sequence 1779 dbid 148599395 branch 815128087
Mon Jun 03 13:10:50 2013
RFS[16]: Assigned to RFS process 37486880
RFS[16]: Selected log 10 for thread 1 sequence 1778 dbid 148599395 branch 815128087
Mon Jun 03 13:10:50 2013
Archived Log entry 2350 added for thread 1 sequence 1778 ID 0x10f38120 dest 2:
Mon Jun 03 13:11:15 2013
Errors in file /u01/app/oracle/admin/P10/diag/rdbms/P10dg/P10DG/trace/P10DG_pr0a_61079852.trc (incident=83785):
ORA-00600: internal error code, arguments: [3020], [52], [591479], [218695287], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 52, block# 591479, file offset is unknown bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 52: '+P10_DATAGROUP01/P10/undotbs03.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Is it possible to sync with primary?
Any suggestions.
Br,

972788 wrote:
Hi,
We didn't find error in primary alert log.
Br,
972788 wrote:Hi,
We didn't find error in primary alert log.
Br,
10567, 00000, "Redo is inconsistent with data block (file# %s, block# %s, file offset is %s bytes)"
// *Cause: There are two possible causes of this error: (1) A write issued
//          by Oracle was lost by the underlying OS or storage system.
//          (2) an Oracle internal error.
// *Action: Investigate why the error occurred and how important is the data
//          block. Media and standby database recovery usually can continue
//          if user allows recovery to corrupt this data block.

Similar Messages

ORA -10567 : Redo is inconsistent with data block...

Hi All !!
Two days back I installed oracle 10g on windows XP and today my database is giving problem as it's in mount state and not opening for normal operation.
When I give command 'alter database open' then it's giving error ORA-10567 : Redo is inconsistent with data block...I have no earlier backup for database
and also no backup for any datafile. I crosschecked the status of datafile and found that there are block corruption in datafile 2 & 4 (users and undotbs01)..I used blockrecover coomand too for block corruption but not able to correct those blocks..plz suggest me that how can I fix this error ORA-10567.
Thanks
With Best Regards
-avichal

Hi Ramesh,
I reckon you should try these out:
- identify the tablespace that file belongs to in the production db.
- put the that tablespace in backup mode on the prod db
- shutdown your standby database
- overwrite the problematic datafile with the corresponding datafile from production database
- put the tablespace above in end backup mode
- startup your standby database and issue the recover command.
Well, there you go. Your standby database should be all fine now.
Regards
Pranilesh Chand

Ora-10567

Hi,
i have a problem with my prod DB. due to power failure our db went down and when the power came back on some files got corupted. i had a rman backup and was able to restore most of the datafiles but one system datafile is giving me errors. the error is pasted below. how do i get rid of this and open my database?
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 12/23/2008 13:28:13
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database
ver logfile 'G:\ARCHIVE\1_1194814.ARC'
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [75503875], [1], [1194814
466], [380], [], []
ORA-10567: Redo is inconsistent with data block (file# 18, block# 6403)
ORA-10564: tablespace SYSTEM
ORA-01110: data file 18: 'D:\IMM\SYSTEM\SYSTEM_02.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 3864

a complete restore of the database solved the problem.

10g standard edition, create a manual standby without ORA-279 and ORA-308.

Hi,
I have a 10 g database 10g r2 on linux rhel 5.2. I've create a standby database from an rman backup on another server (same name, same path....).
every 10 minutes , i switch log on primary database and rsync them to the stanby path on stanby server.
every 10 minutes, i apply the new received archive to the standby database with this script :
sqlplus /nolog
connect / as sysdba
recover database until cancel using backup controlfile;
AUTO
recover database until cancel using backup controlfile;
CANCEL
exit
this script gives some ORA errors like this :
2010/03/31 Wed 11:30:03 Media Recovery Log /v4/db/oradata/LFEX/archives/1_61705_640182036.dbf
2010/03/31 Wed 11:30:03 ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
2010/03/31 Wed 11:30:04 ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel using backup controlfile ...
2010/03/31 Wed 11:40:01 ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel using backup controlfile ...
I understand this error, the script is searching the next archive, which doesn't exist at this time, that's OK.
To avoid to have this error, i believe that i can do something like that:
sqlplus /nolog
connect / as sysdba
recover database until time 'sysdate-1/(24*4)' using backup controlfile;
AUTO
exit
i'm searching to replay the archive and stop 15 minutes before sysdate, Is it possible?
when i try this, i have this message :
SQL> recover database until time 'sysdate-1/(24*4)' using backup controlfile;
ORA-01841: L'année (complète) doit être comprise entre -4713 et +9999 et être
différente de 0.
I'm trying to change nls_date_format, nls_lang without any success.
thx.
Antoine.

i found a script to do an automatic recover script like this :
recover database until time '2010-04-01:16:49:05' using backup controlfile;
ORA-00279: changement 2456430208 généré à 04/01/2010 16:31:01 requis pour thread 1
ORA-00289: suggestion : /v4/db/oradata/LFEX/archives/1_61853_640182036.dbf
ORA-00280: le changement 2456430208 pour le thread 1 se trouve au no de séquence 61853
ORA-00279: changement 2456432030 généré à 04/01/2010 16:39:01 requis pour thread 1
ORA-00289: suggestion : /v4/db/oradata/LFEX/archives/1_61854_640182036.dbf
ORA-00280: le changement 2456432030 pour le thread 1 se trouve au no de séquence 61854
ORA-00278: le fichier journal
'/v4/db/oradata/LFEX/archives/1_61853_640182036.dbf' n'est plus nécessaire pour cette récupération
So i continue to have some error like ORA-278.... but no more ORA-308 error, it's better, because ORA-278 279 and 280 are only information messages, so i can ignore it in alert.log files.
Only ORA-308 in this case interresting me, to see if an archive is really missing.
thx.
PS : the script standby_recover generate the recover.sql script :
[dblegu@dbback SQL]$ cat $PGLEGU/SQL/standby_recover.sql
connect sys/password as sysdba
set trimspool on linesize 200 head off feedback off sqlprompt "--" verify off
spool &1/SQL/recover.sql
select 'connect sys/password as sysdba'||chr(10)||
'set autorecovery on'||chr(10)||
'recover database until time '''||
to_char(sysdate - 1/(24*4),'YYYY-MM-DD:HH24:MI:SS')||''' using backup controlfile;'||chr(10)||
'exit;' from dual;
spool off
exit
the resul in recover.sql is :
connect sys/password as sysdba
set autorecovery on
recover database until time '2010-04-01:16:49:05' using backup controlfile;
exit;
i found this on site : http://erkanorclog.blogspot.com/2007/08/batch-scripts-to-set-up-asyncronous.html.
Edited by: fleuron on 1 avr. 2010 09:04

Standby instance: Ora-01033 when changing passwort

Hello
I build up an standby instance which I would like to as^dd in Grid Control. As you know, the standby instances is mounted, but not opened.
This state leads to an error when trying to change dbsnmp's password:
oracle@sksta90271 [IARTSBY]:~> sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on Mon May 26 09:13:36 2008
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> alter user dbsnmp identified by test;
alter user dbsnmp identified by test
ERROR at line 1:
ORA-01109: database not open
SQL>
I need to set dbsnmp's password to add the instance in Grid control. How to do this?
Thanks Casi

The procedure above (setting pw for dbsnmp, switching logfiles and having them
applied to standby) was not succesful.Can you be more specific at what point did it fail??
On Primary Database:
====================
SQL> alter user scott identified by scott123;
User altered.
SQL> conn scott/scott123
Connected.
SQL> conn /as sysdba
Connected.
SQL> alter system switch logfile;
System altered.
On Physical Standby Database:
=============================
SQL> conn scott/scott123
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Warning: You are no longer connected to ORACLE.
SQL> conn /as sysdba
Connected.
SQL>
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open ;
Database altered.
SQL> conn scott/scott123
Connected.

Physical Standby with ORA-19809 and ORA-19804

My 10.2.0.3 physical standby produced the below errors, although it remained up. I am wondering if I ran into Bug 6432837, except “select FLASHBACK_ON from V$DATABASE” returns “NO”. I was able to increase the size of DB_RECOVERY_FILE_DEST_SIZE to get around it. However, I fear I have only prolonged the problem, since I have not a viable work around. I’m using the Grid Control to administer both Primary and Standby. It doesn’t seem to allow me to back up the standby, nor do I know how to crosscheck archive logs.
Ideas? Suggestions?
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
****Creating archive destination file : /u06/archive/PROD/PROD1/archivelog/2008_12_05/o1_mf_1_110223_1_.arc (10244 blocks)
Fri Dec 5 17:49:04 2008
Errors in file /u01/app/oracle/product/10.2.0/admin/PROD/udump/prod_rfs_21541.trc:
ORA-00270: error creating archive log /u06/archive/PROD/PROD1/archivelog/2008_12_05/o1_mf_1_110223_%u_.arc
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 5244928 bytes disk space from 40531656704 limit
Fri Dec 5 17:49:04 2008
Errors in file /u01/app/oracle/product/10.2.0/admin/PROD/udump/prod_rfs_21541.trc:
ORA-00270: error creating archive log /u06/archive/PROD/PROD1/archivelog/2008_12_05/o1_mf_1_110223_%u_.arc
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 5244928 bytes disk space from 40531656704 limit
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[253|http://forums.oracle.com/forums/]: Assigned to RFS process 21543
RFS[253|http://forums.oracle.com/forums/]: Identified database type as 'physical standby'
Fri Dec 5 17:49:07 2008
Errors in file /u01/appORA-19815: WARNING: db_recovery_file_dest_size of 40531656704 bytes is 99.99% used, and has 5241344 remaining bytes available.
SQL> select * from v$flash_recovery_area_usage;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 100 0 7340
BACKUPPIECE 0 0 0
IMAGECOPY 0 0 0
FLASHBACKLOG 0 0 0
6 rows selected.
SQL> select * from v$recovery_file_dest;
NAME
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
/u06/archive/PROD
4.0532E+10 4.0531E+10 5241344 7340

ARCHIVELOG 100 0 7340Your FRA on the standby side is full - with archivelogs. Archivelogs transferred to the standby are not removed automatically,yourself have to take care of this. As soon as the archives are applied to the standby you can delete them (assuming you do appropriate backups on the primary side). Nevertheless you may take an additional backup on the standby:
backup archivelog all delete all input;
delete obsolete noprompt;
If retention policy is set to redundancy 1 (the default), a backup of the archivelogs is made,the backed up archivelogs are deleted and then the previous backup of older archivelogs is also deleted.
So you should no longer run out of space.
Werner

Resync standby after ORA-26040

Hi guys!
primary db was in no force logging mode :(
On standby db appears ORA-26040. So I'm trying to resync primary and standby db.
I'm doing these steps:
1. primary:
SQL> alter database force logging;
SQL> alter system archive log current;
2. standby
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL IMMEDIATE;
SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN>0;
-- got some SCN
3. primary
RMAN> BACKUP INCREMENTAL FROM SCN <I've got from 2nd step> DATABASE FORMAT '/FRA/tmp/ForStandby_%U' tag 'FOR STANDBY';
4. copy backupsets from primary to standby
5. standby
RMAN> CATALOG START WITH '/FRA/tmp/ForStandby_';
RMAN> RECOVER DATABASE NOREDO;
-- OK
6. check standby:
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0;
-- here must be no rows, BUT instead of I've got SCN. This SCN greater than SCN form 1st step, but still it here!
Why? What I did wrong?
Edited by: bas_ua on 15.02.2013 12:05
Edited by: bas_ua on 15.02.2013 12:06

in general, it looks like FORCE NOLOGGING mode doesn't turned on (but it turned). Because after steps I posted, FIRST_NONLOGGED_SCN changed to greater value, and difference between it and current_scn on primary DB much shorter.
So, I'd say that while I doing incremental backup and restoring it on standby db, NOLOGGING operations continue playing on primary db, so by the time I mount standby I have new FIRST_NONLOGGED_SCN.
I read somewhere, can't remeber exactly, but something like 'alter database force logging waits nologging operation to complete'. Is it possible that I need to restart primary db in turn to FORCE LOGGING mode take effect?

ORA-10458: standby database requires recovery

hi
kindly help me... i got error when standby open in read only mode
SQL*Plus: Release 11.2.0.3.0 Production on Sat Jan 19 14:37:46 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 5344731136 bytes
Fixed Size 2237776 bytes
Variable Size 1275071152 bytes
Database Buffers 4060086272 bytes
Redo Buffers 7335936 bytes
Database mounted.
SQL> Alter Database Recover Managed Standby Database Disconnect;
Database altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01152: file 22 was not restored from a sufficiently old backup
ORA-01110: data file 22: '/archive/data/undo01.dbf'

hi CKPT
I executed the action plan as you recommend and got below information;
SQL> recover standby database;
ORA-00279: change 5983485554580 generated at 01/01/2013 19:27:17 needed for
thread 1
ORA-00289: suggestion : /archive/PROD_1_750568044_45027.ARC
ORA-00280: change 5983485554580 for thread 1 is in sequence #45027
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
'/archive/PROD_1_750568044_45400.ARC'
ORA-00310: archived log contains sequence 45400; sequence 45027 required
ORA-00334: archived log: '/archive/PROD_1_750568044_45400.ARC'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 22 was not restored from a sufficiently old backup
ORA-01110: data file 22: '/archive/data/undo01.dbf'
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01666: control file is for a standby database
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
---------------------------------- and some other activity but still not found any solution-------------
RMAN> recover database until sequence
2> 45026;
Starting recover at 23-JAN-13
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/23/2013 16:42:47
RMAN-06556: datafile 1 must be restored from backup older than SCN 5983484595990
RMAN> recover database until sequence 45027;
Starting recover at 23-JAN-13
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/23/2013 16:42:59
RMAN-06556: datafile 22 must be restored from backup older than SCN 5983485554580
RMAN> recover database until sequence 45025;
Starting recover at 23-JAN-13
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/23/2013 16:43:09
RMAN-06556: datafile 1 must be restored from backup older than SCN 5983484160276
RMAN> alter database open resetlogs;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 01/23/2013 16:43:25
ORA-01666: control file is for a standby database

ORA-19505: failed to identify file - RMAN in creating standby DR database.

I got this error when creating standby database at remote target server.
ORA-19505: failed to identify file "/backup/dxp1p/online/DXP1P_CF_c-2027711285-20131204-01"
Here is what I did:
1.   started the listener and created corresponding tnsnames entry at remote standyb server
2. startup nomount to the standby database at remote server for an empty instance (instance name dxp1p).
3. All rman backups are in the /backup mount point at primary and the mount point is shared on the remote server as nfs.   So, whatever have in the backup we should be able to see and read from the remote as well.
4. Run the following at primary rman:
sql 'alter system archive log current';
backup current controlfile for standby;
sql 'alter system archive log current';
crosscheck backup;
crosscheck archivelog all;
exit
5.   Start the rman command from primary after connected to the standby server, as the primary DB uses ASM and the standby DB uses file system for the database files:
RUN
SET NEWNAME FOR DATAFILE 1 to '/u01/dxp1p/data/system01.dbf';
SET NEWNAME FOR DATAFILE 2 to '/u01/dxp1p/data/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 to '/u01/dxp1p/data/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 4 to '/u01/dxp1p/data/users01.dbf';
SET NEWNAME FOR DATAFILE 5 to '/u01/dxp1p/data/fxtntdata.dbf';
SET NEWNAME FOR DATAFILE 6 to '/u01/dxp1p/data/fxtntindex.dbf';
SET NEWNAME FOR DATAFILE 7 to '/u01/dxp1p/data/mlogs.dbf';
SET NEWNAME FOR DATAFILE 8 to '/u01/dxp1p/data/dts.dbf';
SET NEWNAME FOR DATAFILE 9 to '/u01/dxp1p/data/dxpsoa.dbf';
SET NEWNAME FOR DATAFILE 10 to '/u01/dxp1p/data/expresso_ts.dbf';
SET NEWNAME FOR DATAFILE 11 to '/u01/dxp1p/data/jms_ts.dbf';
SET NEWNAME FOR DATAFILE 12 to '/u01/dxp1p/data/uup_ts.dbf';
SET NEWNAME FOR DATAFILE 13 to '/u01/dxp1p/data/newpage_ts.dbf';
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
DUPLICATE TARGET DATABASE for standby
nofilenamecheck
dorecover;
========================================================================
But I got this error from the rman log:
contents of Memory Script:
   set until scn 12245784375453;
   restore clone standby controlfile;
executing Memory Script
executing command: SET until clause
Starting restore at 04-DEC-13
channel aux1: starting datafile backup set restore
channel aux1: restoring control file
channel aux1: reading from backup piece /backup/dxp1p/online/DXP1P_CF_c-2027711285-20131204-01
channel aux1: ORA-19870: error while restoring backup piece /backup/dxp1p/online/DXP1P_CF_c-2027711285-20131204-01
ORA-19505: failed to identify file "/backup/dxp1p/online/DXP1P_CF_c-2027711285-20131204-01"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
failover to previous backup
channel aux1: starting datafile backup set restore
channel aux1: restoring control file
channel aux1: reading from backup piece /backup/dxp1p/online/DXP1P_20131204_833310136_464
channel aux1: ORA-19870: error while restoring backup piece /backup/dxp1p/online/DXP1P_20131204_833310136_464
ORA-19505: failed to identify file "/backup/dxp1p/online/DXP1P_20131204_833310136_464"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
failover to previous backup
channel aux1: starting datafile backup set restore
channel aux1: restoring control file
channel aux1: reading from backup piece /backup/dxp1p/online/DXP1P_CF_c-2027711285-20131204-00
channel aux1: ORA-19504: failed to create file "/oracle/product/11g/dbs/u02/dxp1p/control/control02.ctl"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 1
ORA-19600: input file is control file (/u01/dxp1p/control/control01.ctl)
ORA-19601: output file is control file (/oracle/product/11g/dbs/u02/dxp1p/control/control02.ctl)
Finished restore at 04-DEC-13
contents of Memory Script:
   sql clone 'alter database mount standby database';
executing Memory Script
sql statement: alter database mount standby database
released channel: aux1
released channel: aux2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 12/04/2013 19:06:13
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of sql command on clone_default channel at 12/04/2013 19:06:13
RMAN-11003: failure during parse/execution of SQL statement: alter database mount standby database
ORA-00205: error in identifying control file, check alert log for more info
=========================================
Not sure why, can somebody help?   Appreciated!

I used company regular script to login to standby instance as sys user from primary DB RMAN as oracle OS user and sys DB user.   We normally run this way for years.
Like this:
$ORACLE_HOME/bin/rman target=/ auxiliary 'sys/sys0rapr321!'@dxp1p_s11 CMDFILE=${HOME}/dba/scripts/rman_cr_dr.cmd
rman_cr_dr.cmd:
RUN
SET NEWNAME FOR DATAFILE 1 to '/u01/dxp1p/data/system01.dbf';
SET NEWNAME FOR DATAFILE 2 to '/u01/dxp1p/data/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 to '/u01/dxp1p/data/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 4 to '/u01/dxp1p/data/users01.dbf';
SET NEWNAME FOR DATAFILE 5 to '/u01/dxp1p/data/fxtntdata.dbf';
SET NEWNAME FOR DATAFILE 6 to '/u01/dxp1p/data/fxtntindex.dbf';
SET NEWNAME FOR DATAFILE 7 to '/u01/dxp1p/data/mlogs.dbf';
SET NEWNAME FOR DATAFILE 8 to '/u01/dxp1p/data/dts.dbf';
SET NEWNAME FOR DATAFILE 9 to '/u01/dxp1p/data/dxpsoa.dbf';
SET NEWNAME FOR DATAFILE 10 to '/u01/dxp1p/data/expresso_ts.dbf';
SET NEWNAME FOR DATAFILE 11 to '/u01/dxp1p/data/jms_ts.dbf';
SET NEWNAME FOR DATAFILE 12 to '/u01/dxp1p/data/uup_ts.dbf';
SET NEWNAME FOR DATAFILE 13 to '/u01/dxp1p/data/newpage_ts.dbf';
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
DUPLICATE TARGET DATABASE for standby
nofilenamecheck
dorecover;
exit
==========================
Oinstall is a group.   I am not sure to use oinstall as a user?

Help for: ORA-01103: database name PRIMARY in control file is not STANDBY

Hello all, this will be my first post to the support forum. I'm an associate dba with just 6 months on the job, so if I've forgotten something or not given some infromation that is needed please let me know.
I've also combed the forums/internet, and some of the answers haven't helped. The Oracle Document ORA-1103 While Mounting the Database Using PFILE [ID 237073.1] says my init.ora file is corrupted, but creating a new init.ora file from the spfile does not help. Neither does just starting from the spfile. I have older copies of the init.ora file and the spfiles that the database was running on previously, so I believe they are good.
This standby NIRNASD1 has existed previously, I had to refresh the primary NIKNASD2, and then re-instantiate NIRNASD1 after the refresh is complete.
My env is set correctly, and my ORACLE_SID has been exported to NIRNASD1
NIKNASD2 = Primary Database
NIRNASD1 = Secondary/Standby Database
Goal: Creation of Logical Standby NIRNASD1 after creating Physical Standby from NIKNASD2
My database versions are 10.2.0.4.0, and the databases are on a Unix server. Both databases are located on separate servers.
Steps that I have taken:
I used RMAN to backup our primary database to the staging area:
$ rman target /
run {
backup database
format '/datatransa/dg_stage/%U'
include current controlfile for standby;
sql "alter system archive log current";
backup archivelog all format '/datatransa/dg_stage/%U';
I used RMAN to Create Secondary Database utilizing RMAN DUPLICATE command.
RMAN> run {
2> allocate auxiliary channel auxdisk device type disk;
3> duplicate target database for standby NOFILENAMECHECK;
4> }
On Secondary database I started Managed Recovery mode
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
(I used pfile here, thinking that I needed to mount the database to the pfile so that the database would see the change in the dataguard parameters in the init.ora file, the change from logical to physical- I commeneted out the logical and uncommented the physical line)
# Dataguard Parameters
For logical standby, change db_name to name of standby database.
db_name=NIKNASD2 ### for physical, db_name is same as primary
#db_name=NIRNASD1 ### for logical, db_name is same as unique_name
SQL> STARTUP MOUNT PFILE = /oraa/app/oracle/product/1020/admin/NIRNASD1/pfile/initNIRNASD1.ora;
ORACLE instance started.
Total System Global Area 1577058304 bytes
Fixed Size 2084368 bytes
Variable Size 385876464 bytes
Database Buffers 1174405120 bytes
Redo Buffers 14692352 bytes
Database mounted.
SQL> ALTER DATABASE recover managed standby database using current logfile disconnect;
I then verified the Data Guard Configuration by using “alter system archive log current;” on the primary database and watching the sequence number change in the secondary database.
I made sure that:
•     The primary database was in MAXIMUM PERFORMANCE MODE
•     Stopped managed recover on the standby database: alter database recover managed standby database cancel;
•     Built a logical standby data dictionary on the primary database
•     The db_name in init.ora was changed (this is in our document at my job)
•     I changed my database name (from physical to logical) in my init.ora pfile (reverse of what I did above)
# Dataguard Parameters
For logical standby, change db_name to name of standby database.
#db_name=NIKNASD2 ### for physical, db_name is same as primary
db_name=NIRNASD1 ### for logical, db_name is same as unique_name
I then went to shutdown my standby database and re-start it in a mount exclusive state, which is where I get the ORA-01103 Error (Again I used the pfile, thinking that I needed to tell the database it is now a logical standby):
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP EXCLUSIVE MOUNT PFILE = /oraa/app/oracle/product/1020/admin/NIRNASD1/pfile/initNIRNASD1.ora;
ORACLE instance started.
Total System Global Area 1577058304 bytes
Fixed Size 2084368 bytes
Variable Size 385876464 bytes
Database Buffers 1174405120 bytes
Redo Buffers 14692352 bytes
ORA-01103: database name 'NIKNASD2' in control file is not 'NIRNASD1'
From what I understand of the process, the name in the control file is correct, I want it to be NIRNASD1. But the database for some reason thinks it should be NIKNASD2. The following are the parts of my init.ora file that include the dataguard parameters:
# Database Identification
db_domain=""
#db_name=NIRNASD1
#db_unique_name=NIRNASD1
# File Configuration
control_files=("/oradba2/oradata/NIRNASD1/control01.ctl", "/oradba3/oradata/NIRNASD1/control02.ctl", "/oradba4/oradata/NIRNASD1/control03.ctl")
# Instance Identification
instance_name=NIRNASD1
# Dataguard Parameters
#db_name=NIKNASD2 ### for physical, db_name is same as prmary
db_name=NIRNASD1 ### for logical, db_name is same as unique_name
db_unique_name=NIRNASD1
dg_broker_start=TRUE
db_file_name_convert='NIKNASD2','NIRNASD1'
log_file_name_convert='NIKNASD2','NIRNASD1'
log_archive_config='dg_config=(NIRNASD1,NIKNASD2)'
log_archive_dest_1='LOCATION="/oraarcha/NIRNASD1/" valid_for=(ONLINE_LOGFILES,all_roles) db_unique_name=NIRNASD1'
#log_archive_dest_2='LOCATION="/oraarcha/NIKNASD2/" valid_for=(standby_logfiles,standby_roles) db_unique_name=NIRNASD1'
log_archive_dest_2='LOCATION="/oraarcha/NIKNASD2/" valid_for=(standby_logfile,standby_role) db_unique_name=NIRNASD1'
STANDBY_ARCHIVE_DEST='LOCATION=/oraarcha/NIKNASD2/'
# Parameters are not needed since this server will NOT become primary
#log_archive_dest_2='service=NIKNASD2
# valid_for=(online_logfiles,primary_role)
# db_unique_name=NIKNASD2'
fal_server='NIKNASD2'
fal_client='NIRNASD1'
I would appreciate any help, or pointing me in the right direction. I'm just missing something. I am reviewing the documents for building a physical and logical standby from oracle. Just not sure where to go from here.
Thank you
Edited by: 977917 on Dec 19, 2012 5:49 PM

First of all, thank you both for answering my post. I've pulled up Mr. Hesse's page and will make it a go-to staple.
We're in the process of upgrading our databases, but we have 130+ databases and only six Oracle dba's, and I'm one of them. It's a large corporation, and things move at a "slow and tested" pace.
The pfile parameters listed above are from my secondary/standby database. And I do want to create a logical standby.
I forgot to mention that we do use DataGuard Broker, but I did not think that would be the cause of why the database was starting up incorrectly, so I did not mention it. My apologies there.
As far as the db_name, here's my question on that. It's my understanding the the db_name should be the name of the primary database when you are working with a physical standby, but as soon as you convert it to logical, you should change the db_name to the secondary/standby database? Am I correct on that?
Leading from that, during the process of creating the physical standby and converting the physical standby to the logical standby, should I change the db_name in the secondary/standby database in the spfile and never use the pfile at all? For instance, when I create the physical standby I have to change the db_name in the standby to the PRIMARY database, so that makes me think I should change db_name in the spfile? (If you see above, I changed db_name in the pfile and did a startup pfile)
This morning I was able to reach out to a fellow DBA (they are were asleep when I posted this last night), and they tried a few things. We had a redirect in the standby directory /oraa/app/oracle/product/1020/dbs folder that looked like this: spfileNIRNASD1.ora -> /oraa/app/oracle/product/1020/admin/NIRNASD1/pfile/spfileNIRNASD1.ora
She removed the redirect and the startup mount exclusive then worked without the error.
Thank you again for your help Mr.Quluzade and Mr. Hesse, I appreciate you all taking the time to teach someone new to the craft. I will definitely read up on the link that you sent me.
Chris Cranford

ORA-16047: DGID mismatch between destination setting and standby

Based on the Data Guard documentation and the given example, this is what I have:
Primary init.ora:
*.db_name='wcati10'
*.db_unique_name=wcati10
*.log_archive_config='DG_CONFIG=(wcati10,npc)'
*.log_archive_dest_1='LOCATION=/webcatiprod1_db_misc/wcati10/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wcati10'
*.log_archive_dest_2='SERVICE=npc.tmo LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=npc'
*.fal_server=npc.tmo
*.fal_client=wcati10.tmo
*.db_file_name_convert=('/oracleapps_db2/','/webcatiprod1_db2')
*.log_file_name_convert=('/oracleapps_db0/','/webcatiprod1_db0/','/oracleapps_db1/','/webcatiprod1_db1')
*.standby_file_management=auto
Standby init.ora:
*.db_name='wcati10'
*.db_unique_name=npc
*.log_archive_config='DG_CONFIG=(wcati10,npc)
*.log_archive_dest_1='LOCATION=/oracleapps_db_misc/wcati10/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=npc'
*.log_archive_dest_2='SERVICE=wcati10.tmo LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=wcati10'
*.db_file_name_convert=('/webcatiprod1_db2/','/oracleapps_db2/')
*.log_file_name_convert=('/webcatiprod1_db0','/oracleapps_db0/','/webcatiprod1_db1','/oracleapps_db1/')
*.fal_server=wcati10.tmo
*.fal_client=npc.tmo
*.standby_file_management=auto
Am I missing something?
Thanks.
added more parameters.
Message was edited by:
FeNiCrC_Neil

16047, 00000, "Dependent archive log destination cannot be a standby database"
// *Cause: The parent archive log destination cannot be a standby database.
// It must be a local archive log destination.
// *Action: Change the parent archive log destination from referencing a
// standby database to referencing a local archive log repository.
Hope this Helps
Regards

Standby Database gives error ORA-03113:ORA-03114

Hi
I am using oracle 9iR2 on standby database when i recover it return errors like
SQL> recover standby database;
ORA-00279: change 8209765386 generated at 07/18/2008 12:10:41 needed for thread
1
ORA-00289: suggestion : J:\ORACLE\ORADATA\APR1\ARCHIVE\APR1T001S86548.ARC
ORA-00280: change 8209765386 for thread 1 is in sequence #86548
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 8209782309 generated at 07/18/2008 12:22:05 needed for thread
1
ORA-00289: suggestion : J:\ORACLE\ORADATA\APR1\ARCHIVE\APR1T001S86549.ARC
ORA-00280: change 8209782309 for thread 1 is in sequence #86549
ORA-00278: log file 'J:\ORACLE\ORADATA\APR1\ARCHIVE\APR1T001S86548.ARC' no
longer needed for this recovery
ORA-03113: end-of-file on communication channel
ORA-03114: not connected to ORACLE
Alert log display
Starting datafile 1 recovery in thread 1 sequence 86551
Datafile 1: 'E:\ORANT\ORADATA\APR1\SYSTEM01.DBF'
Starting datafile 3 recovery in thread 1 sequence 86551
Datafile 3: 'E:\ORANT\ORADATA\APR1\CWMLITE01.DBF'
Starting datafile 4 recovery in thread 1 sequence 86551
Datafile 4: 'E:\ORANT\ORADATA\APR1\DRSYS01.DBF'
Starting datafile 5 recovery in thread 1 sequence 86551
Datafile 5: 'E:\ORANT\ORADATA\APR1\EXAMPLE01.DBF'
Starting datafile 6 recovery in thread 1 sequence 86551
Datafile 6: 'E:\ORANT\ORADATA\APR1\INDX01.DBF'
Starting datafile 7 recovery in thread 1 sequence 86551
Datafile 7: 'E:\ORANT\ORADATA\APR1\ODM01.DBF'
Starting datafile 8 recovery in thread 1 sequence 86551
Datafile 8: 'E:\ORANT\ORADATA\APR1\TOOLS01.DBF'
Starting datafile 9 recovery in thread 1 sequence 86551
Datafile 9: 'J:\ORACLE\ORADATA\APR1\USERS01.DBF'
Starting datafile 10 recovery in thread 1 sequence 86551
Datafile 10: 'E:\ORANT\ORADATA\APR1\XDB01.DBF'
Starting datafile 11 recovery in thread 1 sequence 86551
Datafile 11: 'J:\ORACLE\ORADATA\APR1\APR_DATA5_E.DBF'
Starting datafile 12 recovery in thread 1 sequence 86549
Datafile 12: 'J:\ORACLE\ORADATA\APR1\APR_DATA4_C.DBF'
Starting datafile 13 recovery in thread 1 sequence 86550
Datafile 13: 'J:\ORACLE\ORADATA\APR1\APR_DATA2_D.DBF'
Starting datafile 14 recovery in thread 1 sequence 86550
Datafile 14: 'J:\ORACLE\ORADATA\APR1\APR_DATA2_A.DBF'
Starting datafile 15 recovery in thread 1 sequence 86548
Datafile 15: 'J:\ORACLE\ORADATA\APR1\APR_DATA2_B.DBF'
Starting datafile 16 recovery in thread 1 sequence 86550
Datafile 16: 'J:\ORACLE\ORADATA\APR1\APR_DATA1_A.DBF'
Starting datafile 17 recovery in thread 1 sequence 86550
Datafile 17: 'J:\ORACLE\ORADATA\APR1\APR_DATA1_B.DBF'
Starting datafile 18 recovery in thread 1 sequence 86550
Datafile 18: 'J:\ORACLE\ORADATA\APR1\APR_INDX1_A.DBF'
Starting datafile 19 recovery in thread 1 sequence 86549
Datafile 19: 'J:\ORACLE\ORADATA\APR1\APR_INDX1_B.DBF'
Starting datafile 20 recovery in thread 1 sequence 86549
Datafile 20: 'J:\ORACLE\ORADATA\APR1\APR_INDX1_C.DBF'
Starting datafile 25 recovery in thread 1 sequence 86550
Datafile 25: 'J:\ORACLE\ORADATA\APR1\APR_INDX3_A.DBF'
Starting datafile 26 recovery in thread 1 sequence 86550
Datafile 26: 'J:\ORACLE\ORADATA\APR1\APR_INDX3_B.DBF'
Starting datafile 27 recovery in thread 1 sequence 86550
Datafile 27: 'J:\ORACLE\ORADATA\APR1\APR_INDX3_C.DBF'
Starting datafile 28 recovery in thread 1 sequence 86550
Datafile 28: 'J:\ORACLE\ORADATA\APR1\APR_MVIEWS_A.DBF'
Starting datafile 29 recovery in thread 1 sequence 86550
Datafile 29: 'J:\ORACLE\ORADATA\APR1\BLOB_A.DBF'
Starting datafile 30 recovery in thread 1 sequence 86549
Datafile 30: 'J:\ORACLE\ORADATA\APR1\HR_DATA1_A.DBF'
Starting datafile 31 recovery in thread 1 sequence 86548
Datafile 31: 'J:\ORACLE\ORADATA\APR1\HR_DATA2_A.DBF'
Starting datafile 32 recovery in thread 1 sequence 86550
Datafile 32: 'J:\ORACLE\ORADATA\APR1\HR_INDX1_A.DBF'
Starting datafile 33 recovery in thread 1 sequence 86550
Datafile 33: 'J:\ORACLE\ORADATA\APR1\HR_INDX2_A.DBF'
Starting datafile 34 recovery in thread 1 sequence 86548
Datafile 34: 'J:\ORACLE\ORADATA\APR1\INVENTORY_A.DBF'
Starting datafile 35 recovery in thread 1 sequence 86550
Datafile 35: 'J:\ORACLE\ORADATA\APR1\INVENTORY_INDX_A.DBF'
Starting datafile 36 recovery in thread 1 sequence 86550
Datafile 36: 'E:\ORANT\ORADATA\APR1\SAMPLE_DATA1_A.DBF'
Starting datafile 37 recovery in thread 1 sequence 86550
Datafile 37: 'J:\ORACLE\ORADATA\APR1\VMS_DATA1_A.DBF'
Starting datafile 38 recovery in thread 1 sequence 86550
Datafile 38: 'J:\ORACLE\ORADATA\APR1\APR_MMS_A.DBF'
Starting datafile 39 recovery in thread 1 sequence 86550
Datafile 39: 'J:\ORACLE\ORADATA\APR1\AUDIT_DATA_A.DBF'
Starting datafile 40 recovery in thread 1 sequence 86549
Datafile 40: 'J:\ORACLE\ORADATA\APR1\UNDOTBS.DBF'
Starting datafile 41 recovery in thread 1 sequence 86550
Datafile 41: 'J:\ORACLE\ORADATA\APR1\APR_DATA1_C.DBF'
Starting datafile 42 recovery in thread 1 sequence 86549
Datafile 42: 'J:\ORACLE\ORADATA\APR1\APR_INDX3_E.DBF'
Starting datafile 43 recovery in thread 1 sequence 86548
Datafile 43: 'J:\ORACLE\ORADATA\APR1\APR_DATA2_C.DBF'
Starting datafile 44 recovery in thread 1 sequence 86550
Datafile 44: 'J:\ORACLE\ORADATA\APR1\APR_INDX1_E.DBF'
Starting datafile 46 recovery in thread 1 sequence 86550
Datafile 46: 'E:\ORANT\ORADATA\APR1\SYSTEM02.DBF'
Starting datafile 47 recovery in thread 1 sequence 86550
Datafile 47: 'J:\ORACLE\ORADATA\APR1\APR_INDX4_A.DBF'
Starting datafile 48 recovery in thread 1 sequence 86549
Datafile 48: 'J:\ORACLE\ORADATA\APR1\APR_DATA4.DBF'
Starting datafile 49 recovery in thread 1 sequence 86550
Datafile 49: 'J:\ORACLE\ORADATA\APR1\APR_DATA4_A.DBF'
Starting datafile 50 recovery in thread 1 sequence 86548
Datafile 50: 'J:\ORACLE\ORADATA\APR1\APR_DATA4_B.DBF'
Starting datafile 51 recovery in thread 1 sequence 86550
Datafile 51: 'J:\ORACLE\ORADATA\APR1\APR_INDX4_B.DBF'
Starting datafile 52 recovery in thread 1 sequence 86550
Datafile 52: 'J:\ORACLE\ORADATA\APR1\APR_DATA5_A.DBF'
Starting datafile 53 recovery in thread 1 sequence 86550
Datafile 53: 'J:\ORACLE\ORADATA\APR1\APR_DATA5_B.DBF'
Starting datafile 54 recovery in thread 1 sequence 86550
Datafile 54: 'J:\ORACLE\ORADATA\APR1\APR_DATA5_C.DBF'
Starting datafile 55 recovery in thread 1 sequence 86550
Datafile 55: 'J:\ORACLE\ORADATA\APR1\APR_DATA5_D.DBF'
Starting datafile 56 recovery in thread 1 sequence 86549
Datafile 56: 'J:\ORACLE\ORADATA\APR1\APR_INDX4_C.DBF'
Starting datafile 57 recovery in thread 1 sequence 86550
Datafile 57: 'J:\ORACLE\ORADATA\APR1\APR_INDX3_F.DBF'
Starting datafile 58 recovery in thread 1 sequence 86550
Datafile 58: 'J:\ORACLE\ORADATA\APR1\APR_DATA6_A.DBF'
Starting datafile 59 recovery in thread 1 sequence 86548
Datafile 59: 'J:\ORACLE\ORADATA\APR1\APR_DATA6_B.DBF'
Starting datafile 60 recovery in thread 1 sequence 86549
Datafile 60: 'J:\ORACLE\ORADATA\APR1\APR_DATA6_C.DBF'
Starting datafile 61 recovery in thread 1 sequence 86549
Datafile 61: 'J:\ORACLE\ORADATA\APR1\APR_INDX4_D.DBF'
Starting datafile 62 recovery in thread 1 sequence 86550
Datafile 62: 'J:\ORACLE\ORADATA\APR1\APR_INDX5_A.DBF'
Starting datafile 63 recovery in thread 1 sequence 86550
Datafile 63: 'J:\ORACLE\ORADATA\APR1\APR_INDX5_B.DBF'
Starting datafile 64 recovery in thread 1 sequence 86550
Datafile 64: 'E:\ORANT\ORADATA\APR1\USERS01_A.DBF'
Starting datafile 65 recovery in thread 1 sequence 86550
Datafile 65: 'J:\ORACLE\ORADATA\APR1\GMT1_DATA.DBF'
Starting datafile 66 recovery in thread 1 sequence 86548
Datafile 66: 'J:\ORACLE\ORADATA\APR1\GMT1_INDX.DBF'
Starting datafile 67 recovery in thread 1 sequence 86550
Datafile 67: 'J:\ORACLE\ORADATA\APR1\APR_DATA7.DBF'
Starting datafile 68 recovery in thread 1 sequence 86550
Datafile 68: 'J:\ORACLE\ORADATA\APR1\APR_INDX7A.ORA'
Starting datafile 69 recovery in thread 1 sequence 86550
Datafile 69: 'J:\ORACLE\ORADATA\APR1\APR_INDX8_A.DBF'
Starting datafile 70 recovery in thread 1 sequence 86550
Datafile 70: 'J:\ORACLE\ORADATA\APR1\APR_INDX8_B.DBF'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Wed Jul 23 11:26:24 2008
ALTER DATABASE RECOVER CONTINUE DEFAULT
Wed Jul 23 11:26:24 2008
Media Recovery Log J:\ORACLE\ORADATA\APR1\ARCHIVE\APR1T001S86548.ARC
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Wed Jul 23 11:26:25 2008
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log J:\ORACLE\ORADATA\APR1\ARCHIVE\APR1T001S86549.ARC
Wed Jul 23 11:26:53 2008
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Wed Jul 23 11:26:53 2008
ARC0: terminating instance due to error 472
Instance terminated by ARC0, pid = 2100
Tell me the solution.
Thanks in advance

I think your database is not going in begin backup mode...
this is my standby database server Pratap is there any method to check backup mode .
Thanks

Standby Database Creation problem

Hi,
I have setup Standby Database for our Primary DAtabae,
I am facing probel while applying redo logs, if somebody nows the solution, Please help me.
SQL> startup nomount PFILE='E:\oracle\admin\fno\pfile\init.ora';
ORACLE instance started.
Total System Global Area 730931140 bytes
Fixed Size 454596 bytes
Variable Size 285212672 bytes
Database Buffers 444596224 bytes
Redo Buffers 667648 bytes
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Database altered.
SQL> RECOVER STANDBY DATABASE;
ORA-00279: change 7990686470 generated at 04/01/2006 15:53:57 needed
for threa
1
ORA-00289: suggestion : F:\ORACLE\ORADATA\FNO\ARCH\LOG_17032.ARC
ORA-00280: change 7990686470 for thread 1 is in sequence #7032
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [8388681], [1],
[7032],
[137367], [16], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 73)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 2: 'G:\ORACLE\ORADATA\FNO\UNDOTBS01.DBF'
ORA-10560: block type 'KTU SMU HEADER BLOCK'
ORA-01112: media recovery not started
Ramesh
pls mail me : [email protected]
+91 080 9341018616

Hi,
I have setup Standby Database for our Primary DAtabae,
I am facing probel while applying redo logs, if somebody nows the solution, Please help me.
SQL> startup nomount PFILE='E:\oracle\admin\fno\pfile\init.ora';
ORACLE instance started.
Total System Global Area 730931140 bytes
Fixed Size 454596 bytes
Variable Size 285212672 bytes
Database Buffers 444596224 bytes
Redo Buffers 667648 bytes
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Database altered.
SQL> RECOVER STANDBY DATABASE;
ORA-00279: change 7990686470 generated at 04/01/2006 15:53:57 needed
for threa
1
ORA-00289: suggestion : F:\ORACLE\ORADATA\FNO\ARCH\LOG_17032.ARC
ORA-00280: change 7990686470 for thread 1 is in sequence #7032
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [3020], [8388681], [1],
[7032],
[137367], [16], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 73)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 2: 'G:\ORACLE\ORADATA\FNO\UNDOTBS01.DBF'
ORA-10560: block type 'KTU SMU HEADER BLOCK'
ORA-01112: media recovery not started
Ramesh
pls mail me : [email protected]
+91 080 9341018616

Standby do not applied archives

Hi,
Please help me any one,
am facing the below problem,
Errors in file /oracle/admin/marvlstd/bdump/marvlstd_mrp0_28273.trc:
ORA-12801: error signaled in parallel query server P000
ORA-00600: internal error code, arguments: [3020], [90], [573443], [378060803], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 90, block# 573443)
ORA-10564: tablespace USERS
ORA-01110: data file 90: '+DA
when am started MRP above error to be occurred how to solve the issue in statdby
i have restarted asm and DB its fine but archives not applied,
once i put the below command facing the above problem.
alter database recover managed standby database disconnect from session;
Thanks
Gopi G

Hi,
please check following link: ORA-10567: Redo is inconsistent with data block (file# 124, block# 214081) &laquo; Hendry&#039;s &quot;Oracl…
Thank you

Help! standby errors

Hi, we got some weird messages from standby alert log on the apply instance of standby. Could someone help me what we need to do to fix this problem. Thank you so much.
Our system is Oracle RAC (2 nodes, 10g, ASM, Windows Servers 2003). Both primary and standby have the same configuration
Fri Feb 06 02:17:28 2009
Recovery of Online Redo Log: Thread 1 Group 12 Seq 547 Reading mem 0
Mem# 0: +DATA/standby/onlinelog/group_12.287.677414141
Mem# 1: +RECOVERY/standby/onlinelog/group_12.5749.677414141
Fri Feb 06 04:59:38 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_p005_6116.trc:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '+DATA/standby/onlinelog/group_1.306.677414335'
ORA-10567: Redo is inconsistent with data block (file# 8, block# 39122)
ORA-10564: tablespace PAD_INDEX
ORA-01110: data file 8: '+DATA/standby/datafile/pad_index.319.677763323'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 50004
Fri Feb 06 04:59:38 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_p005_6116.trc:
ORA-00339: archived log does not contain any redo
ORA-00334: archived log: '+DATA/standby/onlinelog/group_9.312.677414345'
Fri Feb 06 04:59:38 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_p005_6116.trc:
ORA-00600: internal error code, arguments: [3020], [8], [39122], [33593554], [], [], [], []
Fri Feb 06 04:59:38 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_p005_6116.trc:
ORA-00600: internal error code, arguments: [3020], [8], [39122], [33593554], [], [], [], []
Fri Feb 06 04:59:38 2009
Trace dumping is performing id=[cdmp_20090205045938]
Fri Feb 06 04:59:40 2009
MRP0: Background Media Recovery terminated with error 12801
Fri Feb 06 04:59:40 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_mrp0_1728.trc:
ORA-12801: error signaled in parallel query server P005, instance standbyDB2:standby2 (2)
ORA-00600: internal error code, arguments: [3020], [8], [39122], [33593554], [], [], [], []
Fri Feb 06 04:59:41 2009
Managed Standby Recovery not using Real Time Apply
Fri Feb 06 04:59:44 2009
Recovery interrupted!
Recovered data files to a consistent state at change 6773432869
Fri Feb 06 04:59:46 2009
Errors in file c:\oracle\product\10.2.0\admin\standby\bdump\standby2_mrp0_1728.trc:
ORA-12801: error signaled in parallel query server P005, instance standbyDB2:standby2 (2)
ORA-00600: internal error code, arguments: [3020], [8], [39122], [33593554], [], [], [], []
Fri Feb 06 08:58:42 2009
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[30]: Successfully opened standby log 11: '+DATA/standby/onlinelog/group_11.288.677414139'
Fri Feb 06 16:27:51 2009
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[30]: Successfully opened standby log 12: '+DATA/standby/onlinelog/group_12.287.677414141'

There is a bug published in metalink.
Please read note 30866.1 and 7197445.8

Standby db ORA-10567:

Similar Messages

Maybe you are looking for