What’s the bug status code meaning in MOS

MOS中查看Bug database,会看到每个bug都有自己的status,那么这其中常见的status有哪些,又都分别是什么含义呢?

我们可以通过MOS中的Advanced Search功能查找特定状态的Bug,比如有哪些是已经确认为Bug移交到研发部门但是还没有补丁写出来的?

比较常见的status有以下这些。而这些状态也基本上表明了一个bug从接收到解决的流程。

10 – Description Phase
Development is requesting more information. 研发部门需要更多信息。

16 – Support bug screening
Bug is being reviewed by our Bug Diagnostics group. Bug诊断小组正在评估。

11 – Code Bug (Response/Resolution)
Bug is being worked by Development. 已经确认为Bug,研发部门正在尝试修正。

30 – Additional Information Requested
Bug is being worked by Support and/or more information was requested by Development. 技术支持已经参与工作,不过研发部门正在要求更多信息。这意味着补丁已经写完,正在让技术测试去测试是否有效。研发部门从现有的bug描述和上传的log截图等信息中还无法确定问题,要求bug的提交者提供其他更加详细的信息。

37 – To Filer for Review/Merge Required
Bug has been fixed but the patch will be merged into the next patchset. Bug已经修正但是补丁在下一个补丁集中一起发布。

80 – Development to Q/A
Bug is being regression tested for future release. Bug被移交到质量控制部门做回归测试。

81 – Q/A to Dev/Patch or Workaround Avble
Patch released via Metalink. 补丁发布到Metalink上。

90 – Closed, Verified by Filer
Bug has been fixed and is closed. Bug已经修正并且关闭。

91 – Closed, Could Not Reproduce
Bug is closed as not reproducible. Bug被关闭因为无法重现。

92 – Closed, Not a Bug
Bug is closed as not a bug (not reproducible or setup issue). Bug被关闭因为这不是个bug,可能是因为无法重现也可能仅仅是因为客户的安装问题。

93 – Closed, Not Verified by Filer
Bug has been fixed and is closed. Bug已经修正并且关闭。

95 – Closed, Vendor OS Problem
Bug is closed as an OS problem. Bug被关闭因为这是操作系统问题。

96 – Closed, Duplicate Bug
Bug is closed as a duplicate bug. Bug被关闭因为已经有重复的bug已经被报告了。

其中10, 16表示技术支持部门(也就是Oracle的OSS)提交了一个bug,但是研发部门还没有确认和接受它是一个真正的bug。
11表示bug已经移交到研发部门,研发人员正在尝试修正,还在工作过程中,目前为止还未修正。
80, 81, 90 , 93表示bug已被修正,补丁可以下载或者请求下载了。

DB time VS. DB CPU

如何行之有效地展示系统负载在做系统调优的时候是必不可少的技巧。通常我们会使用Oracle提供的Time Model,比如我们需要作出类似于下面这样的趋势图来展示系统负载的高低。

这样的趋势图可以直接使用Oracle10g以后的OEM得到,也可以将SQL结果传入Excel中作出趋势图,这里并不是想说如何作出这样的图来,而是想说在我们选取的性能指标中,DB time是什么意思?DB CPU是什么意思?

实际上,官方文档已经给出了解释(我很希望我早就注意到):V$SESS_TIME_MODEL

其中的事件模型树状图很值得参考。

总的来说(如果有任何错误,欢迎指正):
1. 数据库消耗的总时间包括background elapsed time + DB time,基本上在一个正常的系统中DB time要远远大于background elapsed time(指数据库后台进程消耗的时间,比如PMON进程本身)。
2. DB time包含DB CPU + sql execute elapsed time + parse time elapsed + 其它的那些elapsed time,基本上一个正常的系统中,前三项占据了99%以上的DB time,而其中sql execute elapsed time又应该会在95%以上,但是值得注意的是DB CPU和sql execute elapsed time是有交集的,因此你会看到在一份AWR报告中有出现DB CPU + sql execute elapsed time超过100% DB time的情况。
3. DB time是流逝的时间量(elapsed time),以微妙(microseconds)为单位,也就是百万分之一秒。在vsys_time_model中的STAT_NAME是”DB time”。
4. DB CPU是CPU运转的时间,不包含数据库进程在等待CPU的时间,同样以微秒(microseconds)为单位。在v
sys_time_model中的STAT_NAME是”DB CPU”。
5. 我们在ASH报告中经常看到的’CPU + Wait for CPU’指的是DB time,而CPU就是DB CPU。

另外,下面的这三篇文章也同样值得阅读:
Average active sessions: the magic metric? (PDF by John Beresniewicz)
Time Matters – DB Time (from Doug’s Oracle Blog)
Time Matters – DB CPU (from Doug’s Oracle Blog)