某客户数据库警告日志报大量的ORA-00600: internal error code, arguments: [15753]错误,日志内容如下:
Tue May 26 22:10:00 2015
opiodr aborting process unknown ospid (18088452) as a result of ORA-28
Tue May 26 22:10:02 2015
opiodr aborting process unknown ospid (10485766) as a result of ORA-28
Tue May 26 22:10:03 2015
opiodr aborting process unknown ospid (26804280) as a result of ORA-28
Tue May 26 22:10:03 2015
Dumping diagnostic data in directory=[cdmp_20150526221003], requested by (instance=2, osid=7799620 (P001)), summary=[incident=721
038].
Tue May 26 22:10:04 2015
opiodr aborting process unknown ospid (23855276) as a result of ORA-28
Tue May 26 22:18:40 2015
Dumping diagnostic data in directory=[cdmp_20150526221840], requested by (instance=2, osid=15795022 (M000)), summary=[incident=72
0434].
Tue May 26 22:22:20 2015
Errors in file /u01/oracle/diag/rdbms/jzh/jzh1/trace/jzh1_ora_1638890.trc (incident=733420):
ORA-00600: internal error code, arguments: [15753], [2], [1263753296], [0x7000019FFEDFFE8], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/jzh/jzh1/incident/incdir_733420/jzh1_ora_1638890_i733420.trc
Tue May 26 22:22:35 2015
Dumping diagnostic data in directory=[cdmp_20150526222235], requested by (instance=1, osid=1638890), summary=[incident=733420].
Tue May 26 22:22:35 2015
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Tue May 26 22:22:36 2015
Sweep [inc][733420]: completed
Sweep [inc2][733420]: completed
查询MOS文档:ORA-600[15753](文档ID138463.1),该错误是Oracle Bug: 13911083
Cause
This ORA-600 error code is due to Oracle Bug: 13911083.
Bug No : 13911083
Versions confirmed as being affected : 11.2.0.3
Fixed: 12.1.0.0
Patch available : on Linux/HP
Descriptions: ORA-600 [15753] [2] can occur in a parallel query slave if user sessions are killed or terminate abnormally.
Oracle is working on patch for AIX platform.
-----由于并行session被kill掉,或者意外中断就会触发该Bug。
Capture needs to query gv$instance to know whether any nodes are down or not.
Due to this Oracle Bug, when Capture tries to query GV$INSTANCE dictionary view, it gets ORA-600 error as a result Capture couldn't start.
Furthermore, whenever running below query in Instance#1 or #2 by SQL*Plus, the results were ORA-12805 error(parallel query server died unexpectedly).
select count(*) from gv$instance where status = 'OPEN' and thread# = 1;
select count(*) from gv$instance where status = 'OPEN' and thread# = 2;
-----当在查询gv$instance或者gv$session时,应用程序就会报 ORA-12805 parallel query server died unexpectedly 错误。
Resolution
Workaround:
1. Apply patch 13911083.
Check the Oracle patch in Metalink, at this time(Feb 2013) there are patches on Linux/HP platform, but regarding AIX platform there are no patches.
OR
2. Flush SHARED_POOL
For clearing up the dirty cursors related to GV$INSTANCE query, issue below command in the problematic instance(s).
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
If you may startup database instance, it's a better approach.
OR
3. Purge the individual cursor in shared_pool.
解决方法:
1、打13911083补丁
2、flush shared_pool
3、清理共享池中individual cursor。
Tue May 26 22:10:00 2015
opiodr aborting process unknown ospid (18088452) as a result of ORA-28
Tue May 26 22:10:02 2015
opiodr aborting process unknown ospid (10485766) as a result of ORA-28
Tue May 26 22:10:03 2015
opiodr aborting process unknown ospid (26804280) as a result of ORA-28
Tue May 26 22:10:03 2015
Dumping diagnostic data in directory=[cdmp_20150526221003], requested by (instance=2, osid=7799620 (P001)), summary=[incident=721
038].
Tue May 26 22:10:04 2015
opiodr aborting process unknown ospid (23855276) as a result of ORA-28
Tue May 26 22:18:40 2015
Dumping diagnostic data in directory=[cdmp_20150526221840], requested by (instance=2, osid=15795022 (M000)), summary=[incident=72
0434].
Tue May 26 22:22:20 2015
Errors in file /u01/oracle/diag/rdbms/jzh/jzh1/trace/jzh1_ora_1638890.trc (incident=733420):
ORA-00600: internal error code, arguments: [15753], [2], [1263753296], [0x7000019FFEDFFE8], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/jzh/jzh1/incident/incdir_733420/jzh1_ora_1638890_i733420.trc
Tue May 26 22:22:35 2015
Dumping diagnostic data in directory=[cdmp_20150526222235], requested by (instance=1, osid=1638890), summary=[incident=733420].
Tue May 26 22:22:35 2015
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Tue May 26 22:22:36 2015
Sweep [inc][733420]: completed
Sweep [inc2][733420]: completed
查询MOS文档:ORA-600[15753](文档ID138463.1),该错误是Oracle Bug: 13911083
Cause
This ORA-600 error code is due to Oracle Bug: 13911083.
Bug No : 13911083
Versions confirmed as being affected : 11.2.0.3
Fixed: 12.1.0.0
Patch available : on Linux/HP
Descriptions: ORA-600 [15753] [2] can occur in a parallel query slave if user sessions are killed or terminate abnormally.
Oracle is working on patch for AIX platform.
-----由于并行session被kill掉,或者意外中断就会触发该Bug。
Capture needs to query gv$instance to know whether any nodes are down or not.
Due to this Oracle Bug, when Capture tries to query GV$INSTANCE dictionary view, it gets ORA-600 error as a result Capture couldn't start.
Furthermore, whenever running below query in Instance#1 or #2 by SQL*Plus, the results were ORA-12805 error(parallel query server died unexpectedly).
select count(*) from gv$instance where status = 'OPEN' and thread# = 1;
select count(*) from gv$instance where status = 'OPEN' and thread# = 2;
-----当在查询gv$instance或者gv$session时,应用程序就会报 ORA-12805 parallel query server died unexpectedly 错误。
Resolution
Workaround:
1. Apply patch 13911083.
Check the Oracle patch in Metalink, at this time(Feb 2013) there are patches on Linux/HP platform, but regarding AIX platform there are no patches.
OR
2. Flush SHARED_POOL
For clearing up the dirty cursors related to GV$INSTANCE query, issue below command in the problematic instance(s).
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
If you may startup database instance, it's a better approach.
OR
3. Purge the individual cursor in shared_pool.
解决方法:
1、打13911083补丁
2、flush shared_pool
3、清理共享池中individual cursor。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10271187/viewspace-1679886/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10271187/viewspace-1679886/