環境：
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)
經過對問題的分析以及查閱以下文件：
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 .
Posted by on Jun 15, 2007
This was yesterday on 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
問題解決。。
解決思路：
問題並不重要，重要的是解決問題的思路及問題定位，查詢出主要的問題點進行解決！