ORA-00313问题,日志不能应用

zxjlqh

环境  11.2.0.3 双节点rac,   单点dg

dg 是最大可用模式

把REDO大小从150M调到500M后,归档能顺利传到备机上.但是用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION应用日志,就会报以下错误:



RFS[4]: Selected log 14 for thread 2 sequence 1424 dbid -264157542 branch 807640249
Archived Log entry 2662 added for thread 2 sequence 1423 ID 0xf0fb1dbe dest 1:
Thu Aug 29 10:44:42 2013
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (thirdb)
Thu Aug 29 10:44:42 2013
MRP0 started with pid=33, OS id=26826
MRP0: Background Managed Standby Recovery process started (thirdb)
started logmerger process
Thu Aug 29 10:44:47 2013
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 3 (用于线程 2) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 5 (用于线程 1) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 7 (用于线程 2) 的成员
Errors in file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc:
ORA-00313: 无法打开日志组 8 (用于线程 2) 的成员
Media Recovery Log /backup/thirdb/2_1176_807640249.dbf
Media Recovery Log /backup/thirdb/1_1289_807640249.dbf
Completed:  alter database recover managed standby database disconnect from session
Thu Aug 29 10:45:28 2013
Media Recovery Log /backup/thirdb/1_1290_807640249.dbf
Thu Aug 29 10:45:55 2013
ORA-01555 caused by SQL statement below (SQL ID: 3nkd3g3ju5ph1, Query Duration=3 sec, SCN: 0x0000.06c11c7a):
select obj#,type#,ctime,mtime,stime, status, dataobj#, flags, oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
Thu Aug 29 10:47:26 2013
Media Recovery Log /backup/thirdb/2_1177_807640249.dbf
Thu Aug 29 10:47:46 2013
Media Recovery Log /backup/thirdb/1_1291_807640249.dbf



备库也能打开,就是应用不了日志,主库切换日志,备库也会跟着切换的.
请大神帮忙,搞1整天了,没弄好...谢谢!

Maclean Liu(刘相兵

上传  /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_26826.trc

zxjlqh

1. Trace file /u01/app/oracle/diag/rdbms/thdg/thirdb/trace/thirdb_mrp0_3604.trc
   
2. Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
   
3. With the Partitioning, OLAP, Data Mining and Real Application Testing options
   
4. ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
   
5. System name:    Linux
   
6. Node name:      bf.hshy.com
   
7. Release:        2.6.18-308.el5
   
8. Version:        #1 SMP Fri Jan 27 17:17:51 EST 2012
   
9. Machine:        x86_64
   
10. Instance name: thirdb
    
11. Redo thread mounted by this instance: 1
    
12. Oracle process number: 31
    
13. Unix process pid: 3604, image: oracle@bf.hshy.com (MRP0)
    
14. 
    
15. 
    
16. *** 2013-09-24 17:29:37.071
    
17. *** SESSION ID:(1155.1) 2013-09-24 17:29:37.071
    
18. *** CLIENT ID:() 2013-09-24 17:29:37.071
    
19. *** SERVICE NAME:(SYS$BACKGROUND) 2013-09-24 17:29:37.071
    
20. *** MODULE NAME:() 2013-09-24 17:29:37.071
    
21. *** ACTION NAME:() 2013-09-24 17:29:37.071
    
22. 
    
23. *** 2013-09-24 17:29:37.071 4320 krsh.c
    
24. MRP0: Background Managed Standby Recovery process started
    
25. 
    
26. *** 2013-09-24 17:29:42.072
    
27. Managed Recovery: Initialization posted.
    
28. Successfully allocated 4 recovery slaves
    
29. Parallel Media Recovery started with 4 slaves
    
30. Managed Recovery: Active posted.
    
31. *** 2013-09-24 17:29:42.440 2972 krsq.c
    
32. Checking candidate ORLs to be archived
    
33. *** 2013-09-24 17:29:42.440 3083 krsq.c
    
34. Waiting for all non-current ORLs to be archived...
    
35. *** 2013-09-24 17:29:42.440 3302 krsq.c
    
36. All non-current ORLs have been archived.
    
37. All non-current ORLs have been archived successfully. Proceed to clear ORLs
    
38. DDE rules only execution for: ORA 313
    
39. ----- START Event Driven Actions Dump ----
    
40. ---- END Event Driven Actions Dump ----
    
41. ----- START DDE Actions Dump -----
    
42. Executing SYNC actions
    
43. ----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
    
44. Successfully dispatched
    
45. ----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
    
46. Executing ASYNC actions
    
47. ----- END DDE Actions Dump (total 0 csec) -----
    
48. ORA-00313: 无法打开日志组 1 (用于线程 1) 的成员
    
49. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
50. ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
    
51. ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
    
52. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
53. ORA-00313: 无法打开日志组 3 (用于线程 2) 的成员
    
54. ORA-00313: 无法打开日志组 3 (用于线程 2) 的成员
    
55. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
56. ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
    
57. ORA-00313: 无法打开日志组 4 (用于线程 2) 的成员
    
58. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
59. ORA-00313: 无法打开日志组 5 (用于线程 1) 的成员
    
60. ORA-00313: 无法打开日志组 5 (用于线程 1) 的成员
    
61. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
62. ORA-00313: 无法打开日志组 7 (用于线程 2) 的成员
    
63. ORA-00313: 无法打开日志组 7 (用于线程 2) 的成员
    
64. DDE: Problem Key 'ORA 313' was flood controlled (0x1) (no incident)
    
65. ORA-00313: 无法打开日志组 8 (用于线程 2) 的成员
    
66. ORA-00313: 无法打开日志组 8 (用于线程 2) 的成员
    

复制代码

zxjlqh

已解决，原来是两组MEMBER，其中一组的MEMBER都失效了