评论: 也说一下Oracle CPU Time

作者: gengmao

gengmao — Mon, 20 Aug 2007 17:12:37 +0000

CPU Time不是实际的等待，不能算是瓶颈。所以对一个系统做instance level tuning的时候，通常是忽略CPU time的。我猜Oracle顾问经常遇到只允许做instance level tuning的事吧?:) 非常理解Kamus这么说的道理。
不过等待事件通常无法准确告诉你产生等待事件的root cause，也无法说明数据库应用是否足够优化。我们需要DBA作出合理判断，找出根源，在SQL level，application level作出调优。在这两个层次优化带来的效果通常也更好。个人以为这种能力是DBA的基本素质，也是饭碗所在（不用担心Oracle能够自动完成这样的任务:)

作者: piner

piner — Tue, 21 Aug 2007 00:57:28 +0000

所以，调整系统，还一定要从全面把握，从根本把握。
我不喜欢有固定的模式，说什么不重要，不用关心，这样不好。或者是Oracle顾问没有办法关心到这里，那也可能。
调优技术就如太极，无招无式，无形无迹，但是，总是能用最小的代价，取得最好的效果。

作者: big_bear

big_bear — Tue, 21 Aug 2007 01:50:09 +0000

我倒不认为从sql level进行调优最好，可能会最提现dba的价值，不过我认为调优应该首先从业务的角度开始。比如我们前端时间有个程序，2秒钟到一个表中查一次看看是否有新的数据进来需要处理，消耗了大量的资源，后来跟开发交流，开发给的结果是因为PM说这个要尽量的快，越快越好。但终端客户可以接受的时间是10秒，那我只要6－8秒跑一次就可以了，这个sql的压力马上就下来了。而且有的时候，很多sql可能换个写法，本来从A表查的变成从B表查，或许压力就下来了，不过从A换到B要对业务很熟悉的，要明确知道这两个写法返回的结果是相同的。
其次才是sql级别的优化，而sql的优化我倾向于减少读，只要读取少了，至少90％以上的问题就解决了。

作者: piner

piner — Tue, 21 Aug 2007 02:18:02 +0000

SQL Level往往就是与applicatin level在一起的。一般认为是一个层次。
真正的第一层是设计与构架，
然后才是sql与application，
之后才是数据库

作者: mustapha

mustapha — Tue, 21 Aug 2007 09:34:31 +0000

呵呵，一看就是实际经验得出的，不过CPU Time在高性能服务器下影响不是那么严重罢了，如果深入调优还是要全面考虑啊，没有既定的公式来套，搞清楚原理才是根本啊

作者: melity78

melity78 — Sat, 26 Jan 2008 13:24:01 +0000

oracle数据库改进的地步非常大，由于它的基础是以on-disk为基础，并且相应的数据结构和它的多进程协调机制，以及算法完全跟不上现在硬件cpu技术，内存技术，硬件技术稳定性的进步。由于oracle数据库太过庞大，革命性的优化的可能性基本不存在.