一次dataguard引起的_ORA-00314和ORA-00312错误_解决方案

现象：
做dataguard，数据库Primary在起到 startup后
出现以下保错信息
ORA-00314： log 3 of thread 1 ,expected sequence# doesn't match  0
ORA-00312:online log 3 thread 1 :'/home/oracle/app/oracle/oradata/ora8/redo01.log'

主库和备库是在一台物理机器上

解决：
log_file_name_convert中包含了archive日志的路径转换，但是online redo日志是跟归档日志不是放同一个目录下的，导致redo日志在备机启用恢复之后被覆盖，导致主库宕机。


解决方案来自metalink

 

		ora-314....does not match 0 on primary database with standby using the same storage (文档 ID 376261.1)	转到底部

---

In this Document   Symptoms   Cause   Solution   References APPLIES TO: Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.3 - Release: 10.1 to 10.2 Information in this document applies to any platform. ***Checked for relevance on 23-Nov-2011*** SYMPTOMS ora-314 can occur on primary database with physical standby using the same storage Sat Jul 8 14:35:19 2006 Errors in file /u11/admin/PEASY/bdump/peasy1_lgwr_5869.trc: ORA-00314: log 1 of thread 1, expected sequence# 202 doesn't match 0 ORA-00312: online log 1 thread 1: '/u11/oradata/PEASY/redo01.log' Sat Jul 8 14:35:19 2006 Errors in file /u11/admin/PEASY/bdump/peasy1_lgwr_5869.trc: ORA-00314: log 1 of thread 1, expected sequence# 202 doesn't match 0 ORA-00312: online log 1 thread 1: '/u11/oradata/PEASY/redo01.log' Sat Jul 8 14:35:19 2006 LGWR: terminating instance due to error 314 Examination of the logfile on the primary database shows that the logfile contents have been "cleared" i.e:- 0002000 2201 0000 0002 0000 0000 0000 8000 a203  0002020 0000 0000 0000 0000 0000 0000 0000 0000  *  0003000 2201 0000 0003 0000 0000 0000 8000 a202  0003020 0000 0000 0000 0000 0000 0000 0000 0000  *  0004000 2201 0000 0004 0000 0000 0000 8000 a205  0004020 0000 0000 0000 0000 0000 0000 0000 0000 CAUSE Invalid setting for log_file_name_convert Standby was started with:- log_file_name_convert = /u10/, /u60/    <<< note no conversion for /u11 where cleared logfile resides Then after startup this is altered, but only for spfile, so only active at next startup. ALTER SYSTEM SET log_file_name_convert='/u10/','/u60/','/u11/','/u61/','/u12/','/u62/','/u13/','/u63/','/u14/','/u64/ ','/u15/','/u65/','/u16/','/u66/','/u17/','/u67/','/u18/','/u68/','/u19/','/u69/' SCOPE=SPFILE; Then during managed recovery the logfile clears the log on the primary as files have not been converted to standby location:- Sat Jul 8 14:34:58 2006 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILE Sat Jul 8 14:34:58 2006 Attempt to start background Managed Standby Recovery process (PEASY) MRP0 started with pid=28, OS id=24723 Sat Jul 8 14:34:59 2006 MRP0: Background Managed Standby Recovery process started (PEASY) Managed Standby Recovery starting Real Time Apply parallel recovery started with 7 processes Clearing online redo logfile 1 /u11/oradata/PEASY/redo01.log Clearing online log 1 of thread 1 sequence number 202 The standby DB clears log sequence 202 on the primary....resulting in ora-314 on the primary SOLUTION To implement the solution, please execute the following steps: Set log_file_name_convert correctly so that only the standby logs are cleared and not the logs on the primary, this will only occur if the standby and primary have access to the same storage, if they are located in seperate physical environments using different storage this issue cannot occur. Bug 5354726 was filed for this but closed as not a bug, as it must be ensured that db/log_file_name_convert parameters are set correctly. REFERENCES BUG:5354726 - MISTAKE IN DB_FILE_NAME_CONVERT CAN CORRUPT LOGS ON PRIMARY

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/438414/viewspace-1262926/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/438414/viewspace-1262926/