ORA-01206: file is not part of this database - wrong database id

环境：

REDHAT5.4 64BIT

ORACLE10.2.0.1 DG

在primary DB RMAN DUPLICATE方式创建好STANDBY DATABASE后，在启用日志应用的时候发现后台报如下错误：

DBW0 started with pid=5, OS id=3142

LGWR started with pid=6, OS id=3144

CKPT started with pid=7, OS id=3146

SMON started with pid=8, OS id=3148

RECO started with pid=9, OS id=3150

CJQ0 started with pid=10, OS id=3152

MMON started with pid=11, OS id=3154

Sat Feb 12 21:26:34 2011

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

MMNL started with pid=12, OS id=3156

Sat Feb 12 21:26:34 2011

starting up 1 shared server(s) ...

Sat Feb 12 21:26:35 2011

ALTER DATABASE MOUNT

Sat Feb 12 21:26:39 2011

Setting recovery target incarnation to 3

ARCH: STARTING ARCH PROCESSES

ARC0 started with pid=16, OS id=3163

Sat Feb 12 21:26:39 2011

ARC0: Archival started

ARC1: Archival started

ARCH: STARTING ARCH PROCESSES COMPLETE

Sat Feb 12 21:26:39 2011

ARC0: Becoming the 'no FAL' ARCH

ARC0: Becoming the 'no SRL' ARCH

ARC0: Thread not mounted

ARC1 started with pid=17, OS id=3165

ARC1: Becoming the heartbeat ARCH

ARC1: Thread not mounted

Sat Feb 12 21:26:39 2011

Successful mount of redo thread 1, with mount id 574531083

Sat Feb 12 21:26:39 2011

Physical Standby Database mounted.

Completed: ALTER DATABASE MOUNT

Sat Feb 12 21:27:24 2011

alter database recover managed standby database disconnect from session

Sat Feb 12 21:27:24 2011

Attempt to start background Managed Standby Recovery process (qqdb)

MRP0 started with pid=18, OS id=3171

Sat Feb 12 21:27:24 2011

MRP0: Background Managed Standby Recovery process started (qqdb)

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1110

Sat Feb 12 21:27:29 2011

Errors in file /u01/admin/qqdb/bdump/qqdb_mrp0_3171.trc:

ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'

ORA-01206: file is not part of this database - wrong database id

Sat Feb 12 21:27:29 2011

Errors in file /u01/admin/qqdb/bdump/qqdb_mrp0_3171.trc:

ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u01/oradata/qqdb/system01.dbf'

ORA-01206: file is not part of this database - wrong database id

Sat Feb 12 21:27:29 2011

MRP0: Background Media Recovery process shutdown (qqdb)

经过对问题的分析以及查阅以下文档：

http://www.pythian.com/news/512/ora-01206-file-is-not-part-of-this-database-wrong-database-id/

Pythian is hiring the best and brightest at all levels across all practices: Oracle DBAs & Apps DBAs, MySQL DBAs, SQL Server DBAs, and Systems Admins. If you want a job experience like this then submit your candidacy here.

ORA-01206: file is not part of this database – wrong database id

Posted byAlex Gorbachevon Jun 15, 2007

This was posted yesterday on Oracle-L by Li Li. I feel I should blog about it to spread the word, especially since not everyone in this world performs test-restores.

Li was executing a test-restore and hit a problem at the end of the point-in-time recovery phase:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

ORA-01122: database file 9 failed verification check

ORA-01110: data file 9: 'H:xxxxxxxxx.dbf'

ORA-01206: file is not part of this database - wrong database id

Datafile 9 was a read-only tablespace, and the source database was actually created with RMAN DUPLICATE. Datafile 9 was read-only during that duplicate operation, and the status hadn’t changed since then. As you can imagine, the read-only datafiles were not changed and their headers still contained the DBID of the database that was the source of the RMAN DUPLICATE. A similar situation could probably happen if tablespaces were imported using transportable tablespaces feature, and left read only.

The fix in this case is to make tablespaces read-write for a moment, and then change back to read-only. The read-write operation will write new datafile headers and, consequently, put there the “right” DBID. IMPORTANT — this has to be done before backup and not after a disaster strikes. This case just emphasizes again the most important rule of any backup/recovery strategy is to do regular test-restores.

If it’s too late and something hit the fan — well, you probably have a chance to offline drop those tablespaces and, hopefully, be able to import them back, if those are transportable tablespaces, and the metadata dump file is still available.

Another idea would be to offline datafiles and then online them after OPEN RESETLOGS. Should someone try that — let us know if it works

最终解决方式：对standby database做一次完整恢复：

RMAN> restore database;

Starting restore at 12-FEB-11

Starting implicit crosscheck backup at 12-FEB-11

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=153 devtype=DISK

Crosschecked 3 objects

Finished implicit crosscheck backup at 12-FEB-11

Starting implicit crosscheck copy at 12-FEB-11

using channel ORA_DISK_1

Finished implicit crosscheck copy at 12-FEB-11

searching for all files in the recovery area

cataloging files...

no files cataloged

using channel ORA_DISK_1

datafile 5 not processed because file is read-only

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /u01/oradata/qqdb/system01.dbf

restoring datafile 00002 to /u01/oradata/qqdb/undotbs01.dbf

restoring datafile 00003 to /u01/oradata/qqdb/sysaux01.dbf

restoring datafile 00004 to /u01/oradata/qqdb/users01.dbf

restoring datafile 00006 to /u01/oradata/qqdb/test_tran01.dbf

channel ORA_DISK_1: reading from backup piece /u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_nnndf_TAG20110212T201720_6odylk88_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_nnndf_TAG20110212T201720_6odylk88_.bkp tag=TAG20110212T201720

channel ORA_DISK_1: restore complete, elapsed time: 00:01:06

Finished restore at 12-FEB-11

RMAN> recover database;

Starting recover at 12-FEB-11

using channel ORA_DISK_1

datafile 5 not processed because file is read-only

starting media recovery

channel ORA_DISK_1: starting archive log restore to default destination

channel ORA_DISK_1: restoring archive log

archive log thread=1 sequence=26

channel ORA_DISK_1: reading from backup piece /u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_annnn_TAG20110212T201839_6odyo0wf_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/u01/flash_recovery_area/QQDB/backupset/2011_02_12/o1_mf_annnn_TAG20110212T201839_6odyo0wf_.bkp tag=TAG20110212T201839

channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

archive log filename=/u01/flash_recovery_area/QQDB/1_26_736032558.dbf thread=1 sequence=26

unable to find archive log

archive log thread=1 sequence=27

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 02/12/2011 21:34:34

RMAN-06054: media recovery requesting unknown log: thread 1 seq 27 lowscn 11338164342448

将sequence为27的日志拷贝过来继续恢复：

RMAN> recover database;

Starting recover at 12-FEB-11

using channel ORA_DISK_1

datafile 5 not processed because file is read-only

starting media recovery

archive log filename=/u01/flash_recovery_area/QQDB/1_27_736032558.dbf thread=1 sequence=27

archive log filename=/u01/flash_recovery_area/QQDB/1_27_736032558.dbf thread=1 sequence=28

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 02/12/2011 21:35:38

RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/flash_recovery_area/QQDB/1_27_736032558.dbf'

ORA-00310: archived log contains sequence 27; sequence 28 required

ORA-00334: archived log: '/u01/flash_recovery_area/QQDB/1_27_736032558.dbf'

RMAN> recover database until sequence 28;

Starting recover at 12-FEB-11

using channel ORA_DISK_1

datafile 5 not processed because file is read-only

starting media recovery

media recovery complete, elapsed time: 00:00:03

Finished recover at 12-FEB-11

RMAN> exit

[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Sat Feb 12 21:37:05 2011

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

SQL> select status from v$instance;

STATUS

------------

MOUNTED

SQL> alter database open;

Database altered.

SQL> startup mount;

ORA-01081: cannot start already-running ORACLE - shut it down first

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 243269632 bytes

Fixed Size 2019864 bytes

Variable Size 83889640 bytes

Database Buffers 150994944 bytes

Redo Buffers 6365184 bytes

Database mounted.

SQL> alter database recover managed standby database disconnect from session;

Database altered.

SQL> select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

--------------

27

问题解决。。

解决思路：

问题并不重要，重要的是解决问题的思路及问题定位，查找出主要的问题点进行解决！