Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

2135

积分

502

好友

184

主题
1#
发表于 2013-5-24 11:33:38 | 查看: 5684| 回复: 4
【基于ORACLE TRACE的问题诊断】通过600 trace大家能发现什么?

如下面的附件, 基于这个trace的内容 结合METALINK 大家都得出些什么结论? 畅所欲言, 只谈谈自己的看法,没有所谓错对。 ORA-600 KGHALP1.zip (959.55 KB, 下载次数: 2575)
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/zh-hans/emergency-services

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569   
2#
发表于 2013-5-24 13:47:55
本帖最后由 lunar 于 2013-5-24 13:55 编辑

看了下,这是一个跑在AIX 7.1(28 core) 的11.2.0.3.0 - 64bit RAC ,实例名称 orcl1 ,看的出来,已经经过了一些初步的优化,比如,数据库使用了30G内存,pga 8G,使用ASMM,已经disable了DRM

数据库使用时报错,目前看数据库使用的非缺省参数和缺省参数中,以下值得注意:
db_block_checksum=FULL ---影响性能

这个节点配置了standby数据库(DG)

结论,可能是 bug造成的share pool的bug

回复 只看该作者 道具 举报

3#
发表于 2013-5-24 16:25:02
从metalink的官方说法,Bug 10378052 - ORA-600[KGHALP1] during insert of XMLType [ID 10378052.8] ,应该是触发了这个bug,SQL语句:INSERT INTO DAT_XBRL_INFO_TMP (XBRL_ID, TEXT, XBRL) VALUES (:B3 , :B2 , XMLTYPE(:B1 ))
oracle 官方的建议是:
escription

    ORA-600[KGHALP1] can occur when inserting an XMLType
     
    Rediscovery Notes:
      ORA-600[KGHALP1] with xmltype
      The trace is likely to show the error is on heap name="qmxlu subheap"
     
    Workaround
     The ORA-600 occurs as the memory size request is too large.
     This fix changes the internal error to a graceful user error .
     Hence a workaround is to address the reason for needing a very large
      memory allocation if the cause can be identified.
--------------------------------------------------------------------
[0004]: resource_limit=TRUE

应该是请求的内存过大,但由于有资源限制,导致用户请求更多资源失败,触发的bug
已有 1 人评分威望 理由
Maclean Liu(刘相兵 + 5 很给力!

总评分: 威望 + 5   查看全部评分

点评 回复 只看该作者 道具 举报

Maclean Liu(刘相兵 发表于 2013-5-24 16:40
good reply !
4#
发表于 2013-5-24 16:34:19
本帖最后由 clevernby 于 2013-5-24 16:43 编辑

ORA-600往往意味着corruption,第一个参数KGHALP可以看出corruption位于kernel generic shared heap manager - allocate permanent memory。
进程随后自动做了heap dump(shared pool),内存是qmxlu subheap,qmx意味着内存和XML功能有关。
接着trace中列出了当前执行的SQL:INSERT INTO DAT_XBRL_INFO_TMP (XBRL_ID, TEXT, XBRL) VALUES (:B3 , :B2 , XMLTYPE(:B1 )),果然有涉及XML。
我觉得有价值的call stack为: qmxEvAllocMem->qmemNextBuf->kghalp

processstate中
SO: 0x7000007847800a0
session状态为BSY,最后一次等待发生在2秒前,为direct path write,但与ORA-600的关系尚不能确定,无关的可能性高

processstate中没有发现有价值的内容

查询metalink,发现和Bug 10378052 : ORA-600[KGHAPL1] DURING INSERT OF XMLTYPE接近
已有 1 人评分威望 理由
Maclean Liu(刘相兵 + 5

总评分: 威望 + 5   查看全部评分

点评 回复 只看该作者 道具 举报

Maclean Liu(刘相兵 发表于 2013-5-24 16:41
不错, 但我觉得 还不至于 corruption
5#
发表于 2013-5-24 16:46:24
clevernby 发表于 2013-5-24 16:34
ORA-600往往意味着corruption,第一个参数KGHALP可以看出corruption位于kernel generic shared heap manage ...

这样的活动可以多搞搞,非常喜欢,对我们这种环境不多的甲方DBA本本族很有帮助

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-16 15:42 , Processed in 0.119915 second(s), 29 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569