共计 2959 个字符，预计需要花费 8 分钟才能阅读完成。
引言
近期我们对 DBASK 小程序进行了升级，UI 交互做了重大优化调整，对注册用户开放知识库全文检索功能，引入数据和云公众号文章，提问时自动关联知识库已知问题，专栏可生成图片分享给好友，欢迎大家通过微信搜索 DBASK 体验。
问答集萃
接下来，我们分享本期整理出的问题和诊断总结，供大家参考学习，详细的诊断分析过程可以通过标题链接跳转到小程序中查看。
问题一、数据库夯 ORA-00494: enqueue [CF] held for too long
listener 不能访问，重启 lsrnctl restart 无效，最后操作系统重启后正常，请帮忙分析下原因。
2019.01.30 02:41 接到电话，反映不能使用，erp 有画面报警；我发现 db 不能连接，lsnr 不能服务了。
查询日志发现：
Wed Jan 30
01:02:02 China Standard Time 2019
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'
waited for 'direct path read', seq_num: 10340
for 'rdbms ipc message' count=1 wait_time=3.009785 sec
DB: direct path read 这个值超时。2019-01-30 00:50:24 时，有锁出现：sql::DELETE FROM XXX WHERE XXX<=TO_CHAR(SYSDATE-30,'YYYYMMDD')||'0000000' AND ROWNUM<1001有大量锁表：XXX，接着有 XXXX 表，用户 FTRPT/sqlplus.exe_程序，XXXXX，XXXXX, 一些 job 等进程锁，越来越多！造成连锁反映！
详细日志如下：
Wed Jan 30 01:02:02 China Standard Time 2019
Errors in file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc:
ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 4688'
Wed Jan 30 01:02:02 China Standard Time 2019
System State dumped to trace file d:\oracle\product\10.2.0\admin\\bdump\_mmon_4704.trc
Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000
by killing session 162.1
Killing enqueue blocker (pid=4688) on resource CF-00000000-00000000
by terminating the process
MMON: terminating instance due to error 2103
Wed Jan 30 01:12:05 China Standard Time 2019
USER: terminating instance due to error 1092
Wed Jan 30 01:12:05 China Standard Time 2019
... 省略诊断结论：表象是控制文件的 enq，最终锁定到根源是闪回区清理进程 RVWR，清空闪回区问题解决。
问题二、oracle rac ORA-600 : [qerltcUserIterGet_1] ORA-08103
今天通过工具查询表的数据突然报错，详细如下：
The statement failed with status 8103:
ORA-08103: object no longer exists for input row 1236.
(CC_OraStatement::rejectRecord, file CC_OraStatement.cpp, line 1,842）诊断结论：客户环境中表空间为 bigfile，设置了 maxsize 700G，当前使用率已经 99%，在 resize 为 900G 后，错误消失，确认为未知 BUG 引起。
问题三、数据库性能问题 GC 等待严重
早上 7 点左右，系统突然出现 CPU 警报，后连接失败，直接连接操作系统可以登录但操作特别卡顿，后现象消失，后排查，发现告警日志其中有两个可疑告警一个是 VKTM 另外一个是 01555，目前还不清楚具体是什么原因造成？
诊断结论：GC 相关的等待严重，首先可以通过参数禁用 DRM 避免频繁的 GC 操作。
问题四、ORA-0600:[kdsgrp1]
open 数据库报错 ORA -0600，详细日志如下：
Fri Feb 15 18:44:11 2019
Restarting dead background process CJQ0
Fri Feb 15 18:44:11 2019
CJQ0 started with pid=33, OS id=3992
Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc (incident=210531):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file f:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3992.trc (incident=210532):
ORA-00600: internal error code, arguments: [600], [ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []], [], [], [], [], [], [], [], [], [], []诊断结论：索引和表不一致导致，重建该对象所有的索引即可。
问题五、如何在做 SPA 的时候跳过某条 SQL？
问题描述：11202 升级 12102 做 SPA 性能测试，在 12.1 的库上执行 dbmssqlpa.executeanalysis_task 重演 SQL 时，一直卡在一个 SQL 上不动，麻烦问下有什么方法能暂时跳过这条 SQL 继续执行后面的任务吗？
诊断结论：正在执行的没办法干预，可以在开始之前从视图中删除相关 SQL，或者设置超时时间。
问题六、SQL 的 PLAN_HASH_VALUE=0
很多时候发现 SQL 的 PLANHASHVALUE=0，请问是什么意思？
诊断结论：这个是正常现象，主要发生在不带查询的 INSERT/DELETE 语句、带绑定变量的 SQL 仅进行了解析而没有实际执行。
问题七、awr report SQL 执行次数为空
如图，为什么在 AWR 报告中某些 SQL 的 执行次数为空？
诊断结论：这个问题是多版本导致的，当 VERSION_COUNT 超过 200 时，Oracle 放弃一些指标的记录。
问题八、logmnr 未显示全部 dml 操作
在测试挖掘日志时，执行了多次 DML 操作，但是挖掘后发现只有 1 条 DML 语句，请问是什么原因？
诊断结论：如果不加附加日志，有的操作可能挖掘不出来。
