查看原文
其他

DBASK问答集萃第二期

数据和云 2019-12-13

以下文章来源于恩墨云服务 ,作者墨天轮

引言



近期我们对DBASK小程序进行了升级,UI交互做了重大优化调整,对注册用户开放知识库全文检索功能,引入数据和云公众号文章,提问时自动关联知识库已知问题,专栏可生成图片分享给好友,欢迎大家通过微信搜索DBASK体验。


问答集萃



接下来,我们分享本期整理出的问题和诊断总结,供大家参考学习,详细的诊断分析过程可以通过标题链接跳转到小程序中查看。

listener不能访问,重启lsrnctl restart 无效,最后操作系统重启后正常,请帮忙分析下原因。

2019.01.30 02:41接到电话,反映不能使用,erp有画面报警;我发现db不能连接,lsnr 不能服务了。

查询日志发现:

  1. Wed Jan 30


  2. 01:02:02 China Standard Time 2019


  3. ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'


  4. waited for 'direct path read', seq_num: 10340


  5. for 'rdbms ipc message' count=1 wait_time=3.009785 sec


DB: direct path read 这个值超时。2019-01-30 00:50:24时,有锁出现 :

  1. sql::DELETE FROM XXX WHERE XXX<=TO_CHAR(SYSDATE-30,'YYYYMMDD')||' 0000000' AND ROWNUM<1001


有大量锁表:XXX,接着有XXXX表,用户FTRPT/sqlplus.exe_程序,XXXXX,XXXXX,一些job等进程锁,越来越多!造成连锁反映!

详细日志如下:

  1. Wed Jan 30 01:02:02 China Standard Time 2019


  2. Errors in file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc:


  3. ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'


  4. Wed Jan 30 01:02:02 China Standard Time 2019


  5. System State dumped to trace file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc


  6. Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000


  7. by killing session 162.1


  8. Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000


  9. by terminating the process


  10. MMON: terminating instance due to error 2103


  11. Wed Jan 30 01:12:05 China Standard Time 2019


  12. USER: terminating instance due to error 1092


  13. Wed Jan 30 01:12:05 China Standard Time 2019

  14. ...省略


诊断结论:表象是控制文件的enq,最终锁定到根源是闪回区清理进程RVWR,清空闪回区问题解决。




今天通过工具查询表的数据突然报错,详细如下:

  1. The statement failed with status 8103:

  2. ORA-08103: object no longer exists for input row 1236.

  3. (CC_OraStatement::rejectRecord, file CC_OraStatement.cpp, line 1,842)


诊断结论:客户环境中表空间为bigfile,设置了maxsize 700G,当前使用率已经99%,在resize为900G后,错误消失,确认为未知BUG引起。




早上7点左右,系统突然出现CPU警报,后连接失败,直接连接操作系统可以登录但操作特别卡顿,后现象消失,后排查,发现告警日志其中有两个可疑告警一个是VKTM另外一个是01555,目前还不清楚具体是什么原因造成?

诊断结论:GC相关的等待严重,首先可以通过参数禁用DRM避免频繁的GC操作。




open数据库报错ORA -0600,详细日志如下:

  1. Fri Feb 15 18:44:11 2019


  2. Restarting dead background process CJQ0


  3. Fri Feb 15 18:44:11 2019


  4. CJQ0 started with pid=33, OS id=3992


  5. Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc (incident=210531):


  6. ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []


  7. Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc (incident=210532):


  8. ORA-00600: internal error code, arguments: [600], [ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []


  9. ], [], [], [], [], [], [], [], [], [], []


诊断结论:索引和表不一致导致,重建该对象所有的索引即可。




问题描述:11202升级12102做SPA性能测试,在12.1的库上执行dbmssqlpa.executeanalysis_task重演SQL时,一直卡在一个SQL上不动,麻烦问下有什么方法能暂时跳过这条SQL继续执行后面的任务吗?

诊断结论:正在执行的没办法干预,可以在开始之前从视图中删除相关SQL,或者设置超时时间。




很多时候发现SQL的PLANHASHVALUE=0,请问是什么意思?


诊断结论:这个是正常现象,主要发生在不带查询的INSERT/DELETE语句、带绑定变量的SQL仅进行了解析而没有实际执行。




如图,为什么在AWR报告中某些 SQL的 执行次数为空?


诊断结论:这个问题是多版本导致的,当 VERSION_COUNT 超过200时,Oracle 放弃一些指标的记录。




在测试挖掘日志时,执行了多次DML操作,但是挖掘后发现只有1条DML语句,请问是什么原因?

诊断结论:如果不加附加日志,有的操作可能挖掘不出来。

出处:恩墨云服务(ID:enmocs)


公司简介 | 恩墨学院 | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城

  

zCloud | SQM | Bethune Pro2 zData一体机 | Mydata一体机 | ZDBM 备份一体机

Oracle技术架构 | 免费课程 数据库排行榜 | DBASK问题集萃 | 技术通讯 

升级迁移 | 性能优化 | 智能整合 安全保障 | 

云和恩墨大讲堂 | 一个分享交流的地方

长按,识别二维码,加入万人交流社群


请备注:云和恩墨大讲堂

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存