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)

Amazing Oracle Backup and Recovery(Internal) Training

我的朋友崔华(dbsnake)将作为恩墨科技备份与恢复高级培训课程的独立讲师在2010年10月21日 ~ 2010年10月24日为大家奉献4天的技术分享

我对于这次培训的评价是,这将是一次挑战听众技术水平和技术热情的讲座。如果你可以在这4天内全程跟住讲师的思路,并且在听完课以后以极大的热情进行更多的研究和实验巩固,那么对于Oracle数据库的备份恢复细节以及相关的所有知识点都将获得一次飞跃性的理解。

ACOUG的多次活动中崔华都做过一些技术分享,而这次是崔华多年来对Oracle数据库潜心研究成果的全面性展示,对于感兴趣的人群(我知道这次培训很高端)这是一场精彩绝伦的盛宴。

想拥有力挽狂澜的技术实力吗?想拥有泰山崩于前而淡定自若的自信心吗?这次培训正是你所需要的。报名信息请猛击这里

11.2.0.2 Patch Set? Really a Patch Set?

Oracle最新为Linux x86和x86-64平台发布了Oracle 11.2.0.2 patch set [Patch set ID: 10098816],这个庞大的patch set拥有5G的超大容量。所以几乎全世界的人都在问,这真的是一个补丁集吗?不仅仅是体积庞大,甚至还一改往日补丁集仅仅是作为Bug修复的角色,在11.2.0.2中还包含了很多New Feature

Oracle专门为此补丁写了一篇文章-Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2 [ID 1189783.1],着重提到了几点。

1. Oracle 11.2.0.2 patch set是一个完整的安装包,以后Oracle也会如此发布后续的补丁包。所以在以后如果要安装新数据软件,不再需要安装一个Base版本然后再打补丁集到最新版本,而是直接使用最新补丁集安装包即可。
2. Oracle建议今后的补丁集安装都安装在一个与当前环境目录不同的全新目录下(Out-of-place upgrade),在安装完成以后再通过此份软件启动数据库实例。实际上以后安装补丁集的过程就等同于从一个版本升级到一个新版本的过程。
3. 为什么做这种改变,是因为Oracle认为Out-of-place upgrade是最佳实践,比较安全。当然这实际上符合Oracle的作风,他认为合理且最好的通常都会武断地改变并且说服客户去接受。
4. Oracle仅仅计划在11.2.0.2中提供一些新功能,今后的补丁集仍然会以修复bug为首要任务。

我个人承认确实Out-of-place upgrade是更加安全的,但是至少这种做法目前存在两点缺陷:
1. 补丁尺寸急剧增加,下载2G的补丁和下载5G的补丁还是有很大区别,但是这不是大问题。当然,由于需要安装在新Oracle Home中,在打补丁时需要额外的硬盘空间,但是不到10G的空间需求也不是大问题。
2. 由于在打完补丁以后,Oracle Home路径实际上发生了变化,那么在脚本中,服务定义中牵涉到的原ORACLE_HOME路径必须都要做相应改动。这是个大问题。不过,可以将老目录rename成一个新名字,再将新目录rename成原目录。

今后的补丁集发布计划可以参看Release Schedule of Current Database Releases [ID 742060.1]