我公司的生产数据库的CPU利用率高居不下，一般us都是85%，sys 12％左右，id几乎都是为0，查看进程情况cpu的running队列一般都是30多个，block队列也达到10多个,该服务器也只是数据库服务器，6个CPU，6G内存，数据库版本为Oracle 8.1.7.3，一般有320个登陆进程，没有任何内存分页情况，利用脚本查看数据库内存指标也不错，只有这几个指标比较差：
library Cache Get Hit Ratio 85.1575%
Chained Fetch Ratio  0.0964
Parse to Execute Ratio 32.841
我怀疑是否SQL的运行性能较差造成数据库CPU利用率较差，再复上report请大家帮我会诊一下.

补充 sar -u
00:00:00    %usr    %sys    %wio   %idle
01:00:05      92       5       3       1
02:00:00      78       4       6      12
03:00:00      69       8       5      18
04:00:00      72       8       6      14
05:00:00      63       5       5      27
06:00:00      70       4       9      17
07:00:00      64       5       7      24
08:00:01      62       5       6      27
09:00:00      85       9       4       2
10:00:26      89       6       4       1
11:00:00      91       5       2       3
12:00:03      70       6       5      18
13:00:02      90       9       1       0
14:00:02      92       7       1       0
15:00:03      91       8       1       0
16:00:01      90       8       1       0
17:00:01      89       9       2       0
18:00:27      90       8       2       0
19:00:01      86      10       4       0

Average       81       7       4       9

sar -r：报告内存利用情况；
00:00:00 freemem freeswap
01:00:05  138087  9530733
02:00:00  160594  9906048
03:00:00  145083 10052579
04:00:00  117993 10015121
05:00:00  169270  9985627
06:00:00  169023  9988594
07:00:00  180378 10181081
08:00:01  175130 10098237
09:00:00  157581  9803347
10:00:26  130324  9362824
11:00:00   73129  8425567
12:00:03   94442  8767481
13:00:02   90160  8692224
14:00:02   94217  8760693
15:00:03   86073  8624000
16:00:01   78016  8482600
17:00:01   77210  8470627
18:00:27   76935  8462195
19:00:01   81856  8551445

Average   120831  9271871

sar -w：报告Solaris内存交换活动；
00:00:00 swpin/s bswin/s swpot/s bswot/s pswch/s
01:00:05    0.00     0.0    0.00     0.0    1825
02:00:00    0.00     0.0    0.00     0.0    2530
03:00:00    0.00     0.0    0.00     0.0    8537
04:00:00    0.00     0.0    0.00     0.0    9386
05:00:00    0.00     0.0    0.00     0.0    2446
06:00:00    0.00     0.0    0.00     0.0    2471
07:00:00    0.00     0.0    0.00     0.0    2902
08:00:01    0.00     0.0    0.00     0.0    3684
09:00:00    0.00     0.0    0.00     0.0    6509
10:00:26    0.00     0.0    0.00     0.0    3980
11:00:00    0.00     0.0    0.00     0.0    3879
12:00:03    0.00     0.0    0.00     0.0    5036
13:00:02    0.00     0.0    0.00     0.0    5852
14:00:02    0.00     0.0    0.00     0.0    4659
15:00:03    0.00     0.0    0.00     0.0    5241
16:00:01    0.00     0.0    0.00     0.0    5528
17:00:01    0.00     0.0    0.00     0.0    5719
18:00:27    0.00     0.0    0.00     0.0    5462
19:00:01    0.00     0.0    0.00     0.0    5480

Average     0.00     0.0    0.00     0.0    4796

检查一下是否缺一个重要的索引.
db buffer hit ratio 是多少?

SGA 的命中率 : 98%
SGA 中字典缓冲区的命中率基本都是99%
SGA 中共享缓存区的命中率:98%
上述指标都应很不错

我估计有几点：
１、虽然你的SGA 的命中率 很高，但library Cache Get Hit Ratio 比较低，可能的原因是你的sql语句没有使用变量绑定，导致每个语句都不一样。

2、虽然你的SGA 的命中率 很高，但文件的ＩＯ量好象仍很大，且每个表空间之间不平衡，
是不你的ＩＯ是瓶劲，或是你的应用设计不合理，或没有建立合适的索引！

希望以上可以帮上你的忙，如有需要，可直接找我！

Your first guess is most likely correct.

If he can't change SQLs, try setting alter system set cursor_sharing=force. If this breaks something else, set it back to exact.

Yong Huang

QUOTE:

---

最初由 lwxian 发布
我估计有几点：
１、虽然你的SGA 的命中率 很高，但library Cache Get Hit Ratio 比较低，可能的原因是你的sql语句没有使用变量绑定，导致每个语句都不一样。

---

还有一个可能，你的表和索引没有经过analyze，导致优化器不能
利用基于代价的优化。

可以对所有用户对象进行analyze一下

Why would that cause excessive CPU usage, which is the problem he has?

Yong Huang

QUOTE:

---

最初由 lwxian 发布
还有一个可能，你的表和索引没有经过analyze，导致优化器不能
利用基于代价的优化。

可以对所有用户对象进行analyze一下

---