设为首页 收藏本站
查看: 905|回复: 0

[经验分享] 10g中占用CPU很高异常oracle进程分析

[复制链接]

尚未签到

发表于 2016-8-7 06:23:30 | 显示全部楼层 |阅读模式
上一篇 / 下一篇  2009-07-20 16:15:19 / 个人分类:Oracle研究

查看( 107 ) / 评论( 0 ) / 评分( 0 / 0 )
        在AIX 5.3平台下oracle 10.2.0.3测试环境中,经常发现某些oracle进程占用很大的CPU资源,但这些进程并不存在v$session中,具体发现脚本如下:

      SQL>select spid, pid, program from v$process
                 where addr not in (select paddr from v$session)

                SPID         PID   PROGRAM
               ------------ ------------------------------------------------
               1962208    18   xxxxx@xxxx (TNS V1-V3)
               2039826     49  xxxxx@xxxx (TNS V1-V3)

       查看系统中发现该进程占用CPU比例很高,每个进程消耗CPU大约20%资源。

       以下是该问题的具体分析:

      SQL> alter session set events ' immediate trace name systemstate level 266'
  或者
      SQL>oradebug setospid 1962208
      SQL>oradebug short_stack     
     
   查找对应的 PROCESS 18,具体信息如下:
Short stack dump: ksdxfstk+002c<-ksdxcb+04e4<-sspuser+0074<-000044BC<-ktsmg_register_tac+0074                <-kscnfy+01f4<-ksucrp+0574<-opiino+03d4<-opiodr+0adc<-opidrv+0474<-sou2o+0090
<-opimai_real+01ec<-main+0098<-__start+0098

Dump of memory from 0x070000009E5EF668 to 0x070000009E5EF870
   ................................
  Repeat 29 times
    ----------------------------------------
    SO: 70000009ea7aef8, type: 3, owner: 70000009e6322a0, flag: INIT/-/-/0x00
    (call) sess: cur 0, rec 0, usr 0; depth: 0
    ----------------------------------------
    SO: 7000000941eced0, type: 16, owner: 70000009e6322a0, flag: INIT/-/-/0x00
    (osp req holder)

  short stack分析:
          start ->main->opimai_real->sou2o->opidrv->ipiodrv->opiino->ksucrp
          ->kscnfy->ktsmg_register_tac+0074->sspuser ..........
  
sspuser()功能是给oradebug 请求的代码路径,所以我们关注ktsmg_register_tac,通过metalink查询,发现BUG:6084108与我们所发现的问题非常相似,在10.2.0.4解决该bug。

附录:
其BUG:6084108具体问题描述:

PROBLEM:--------Intermittently, oracle process abnormally terminates due to ora-3115, thenconsumed one cpu 100%.  There was no v$session info so could not get sessioninformation to track down the root cause.STACK TRACE:------------ktsmg_register_tac 0074 kscnfy ksucrp opiino opiodr opidrv sou2o opimai_realmain暂时解决办法,用操作系统命令kill -9 删除以上进程。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-253964-1-1.html 上篇帖子: oracle连接配置故障的错误及解决方法. 下篇帖子: oracle drop table 之前的if exists判断
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表