暂无图片
分享
又要值班啊
2019-09-03
数据库出现ora-00600错误

问题:告警日志中出现大量ora-00600错误,附件为trace文件。麻烦盖总看下大概是什么原因造成的,感谢!

Mon Sep 02 21:22:21 2019

Errors in file /u01/oracle/diag/rdbms/yxjc/YXJC1/trace/YXJC1_ora_9044270.trc  (incident=528946):

ORA-00600: internal error code, arguments: [15711], [4], [0x700000C38298638], [0x700000B9F93DBD0], [], [], [], [], [], [], [], []

Incident details in: /u01/oracle/diag/rdbms/yxjc/YXJC1/incident/incdir_528946/YXJC1_ora_9044270_i528946.trc

Mon Sep 02 21:22:24 2019

Dumping diagnostic data in directory=[cdmp_20190902212224], requested by (instance=1, osid=9044270), summary=[incident=528946].

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Mon Sep 02 21:22:24 2019

Sweep [inc][528946]: completed

Sweep [inc2][528946]: completed


收藏
分享
10条回答
默认
最新
盖国强

那就是这个问题了:

3、查看了dba_hist_sess_history视图,问题时刻对方节点(节点2)中,有大量“cursor: pin S wait on X”等待事件,对应的语句是收集统计信息的insert append parallel语句。


这个实例请求不到并行进程了。


我昨天将分析结果写了一篇文章,你可以参考一下:

https://www.modb.pro/db/6321

暂无图片 评论
暂无图片 有用 0
暂无图片
又要值班啊
上传附件:ora-00600.rar
暂无图片 评论
暂无图片 有用 0
Moone

从trace文件的SQL看,比较可能的是Bug 3212516  Select from GV$ views can fail with OERI[15711],但是这个BUG的版本是10.1.0.2的版本。

场景如下:

Parallel operations across nodes on GV$ views can fail with
ORA-600 [15711] particularly if the other node/s are changing
state (up/down/up)


检查下是不是当时2#实例有状态变化

暂无图片 评论
暂无图片 有用 0
又要值班啊

感谢大佬指导!实例2在实例1出现600错误时是正常状态。实例1出现该问题时会产生多个几十G的文件从而撑爆磁盘空间,有没有什么好办法可以避免

暂无图片 评论
暂无图片 有用 0
盖国强

你这个问题是 OGG 引发的,跟踪文件有明确的提示:

*** MODULE NAME:(OGG-EXTJC1-OCI_META_THREAD) 2019-09-02 21:22:21.965

暂无图片 评论
暂无图片 有用 0
盖国强

触发的原因和 Bug 3212516  Select from GV$ views can fail with OERI[15711] 类似。

转储文件中,出现了查询 gv$instance 的语句。


----- Current SQL Statement for this session (sql_id=48k7nky3dkt0d) -----

SELECT TO_CHAR(startup_time, 'YYYY-MM-DD HH24:MI:SS') FROM gv$instance WHERE inst_id = 2


你可以手工测试一下,执行这个语句是否有问题。

暂无图片 评论
暂无图片 有用 0
盖国强

把对方节点问题时刻的 ash 报告发上来再看看。

暂无图片 评论
暂无图片 有用 0
又要值班啊

盖总,

1、ash和awr当时没有及时生成,已经被刷了取不到了。

2、手工执行查询 gv$instance 的语句没有报错。

3、查看了dba_hist_sess_history视图,问题时刻对方节点(节点2)中,有大量“cursor: pin S wait on X”等待事件,对应的语句是收集统计信息的insert append parallel语句。


盖总让查看节点2问题时刻的ash报告,是否是想看节点2当时是不是hang住了?


暂无图片 评论
暂无图片 有用 0
又要值班啊

感谢盖总和上面回复的朋友,无以为报,只有买本书支持下,哈哈!

暂无图片 评论
暂无图片 有用 0
又要值班啊
问题已关闭: 问题已经得到解决
暂无图片 评论
暂无图片 有用 0
回答交流
提交
问题信息
请登录之后查看
附件列表
请登录之后查看
邀请回答
暂无人订阅该标签,敬请期待~~
暂无图片墨值悬赏