数据库老是cpu90多，请老大们看看statspace分析报告，多谢了！

显示全部楼层 · 2012-7-12 18:47:29

sun v8804G内存，2个750cput3阵列
solaris 8 ，oracle 8.16下
数据库老是cpu90多，请老大们看看statspace分析报告，多谢了！
我是每一小时一次snap，有两个报告，一份是10天的，一份是3个小时内的，
Event
Waits TimeoutsTime (cs) (ms) /txn
latch free
84,533 45,86137,712 40.0
SQL*Net message from client43,644,168
0 ########### 142 18.7
virtual circuit status
13,495 13,49541,363,885 #####0.0
SQL*Net message to client43,644,174
0 7,636 0 18.7
这几项有点高，具体的请看我的报告，多谢了！

千问 · 2012-7-12 18:47:29

1、共享池太大！
2、这些语句执行时，读取数据缓冲池的数据多，执行的次数少。
可能没用上索引，执行了全表扫描，或者需要优化表的读取顺序！

千问 · 2012-7-12 18:47:29

建议你在cpu负载高的时候通过top查看是什么进程占用的，如果是oracle进程，根据进程号查出相应的sql语句，然后分析，这样比较直接一点。

千问 · 2012-7-12 18:47:29

还使用了mts？并发用户多少？建议屏蔽使用独立服务器模式

千问 · 2012-7-12 18:47:29

统计期间timed_statitics参数怎么改变了？
Rollback 占所有事务的比重怎么这么大？是应用的需要么？
log_buffer 163840这样的数据库这个参数应该大一些吧。
rbs也值得优化一下。
个人认为RollBack的问题最大。

千问 · 2012-7-12 18:47:29

我的系统业务繁忙的时候也是90%以上的，通过top查询最占cpu的进程，都是Oracle的session，再查，的确有长sql在运行，每个查询占一个cpu (6个cpu，一个长sql占16.6%)。优化过后有所改观，不过忙的时候也会有占90% CPU的情况。

千问 · 2012-7-12 18:47:29

建议调整db_buffer_lru_latches的值
大表扫描的情况比较多
SQL的重用不够好

千问 · 2012-7-12 18:47:29

建议参考 eygle 写的 >
很多设置都不合理...
系统总内存多大?为什么共享池和java池要分配这么大?
Large_pool_size也比较大
java_pool_size
209715200

large_pool_size
52428800
shared_pool_size:
629145600 (把这个值改为100-200MB
之间再检测一下)
同意上面有位朋友的说法，共享池设置太大,系统可能要
花很多时间来进行swap.

Top 5 Wait Events

~~~~~~~~~~~~~~~~~
Wait
% Total
Event
WaitsTime (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
db file scattered read
1,209,611246,545 35.50
log file sync
1,074,068 92,596 13.33
db file sequential read
431,197 87,419 12.59
log file parallel write
1,406,173 81,321 11.71
log file sequential read
280,269 51,1687.37

1. db文件分散读: 建议调整和优化索引的使用
2. 日志文件同步:建议一次性提交更多的记录,将重做日志
放在比较快的磁盘上,或者交替使用不同物理磁盘上的
重做日志
3. db文件顺序读:需要结合报告中列出的效率比较低的SQL:
进行综合分析(检查索引，多表连接的顺序等等), 另外
可尝试加大 db_block_buffers(如果当前设置已经很大，就
减小它的值)
4,5日志文件的问题:增大重做日志文件的大小
其他:
sort_area_retained_size 655360

sort_area_size
655360

如果有大数据的排序，这两个值要设置大一些.
并发最大会话数?如果不是太大，去掉mts.

最初由 jianxialong 发布
[B]sun v8804G内存，2个750cput3阵列
solaris 8 ，oracle 8.16下
数据库老是cpu90多，请老大们看看statspace分析报告，多谢了！
我是每一小时一次snap，有两个报告，一份是10天的，一份是3个小时内的，
Event
Waits TimeoutsTime (cs) (ms) /txn
latch free
84,533 45,86137,712 40.0
SQL*Net message from client43,644,168
0 ########### 142 18.7
virtual circuit status
13,495 13,49541,363,885 #####0.0
SQL*Net message to client43,644,174
0 7,636 0 18.7
这几项有点高，具体的请看我的报告，多谢了！ [/B]

千问 · 2012-7-12 18:47:29

零售系统？ OLTP 还是OLAP？
如果不是数据仓库的话，那么BUFFER GETS太惊人了：
拿其中两个SQL为例，一个平均不到2分钟执行一次，每次产生42万个BUFFER GETS,却只返回三百多条记录。另一个，7分钟执行一次，130多万个BUFFER GETs,也只返回不超过几百行。
LIOs太过分了，重写那几条SQL吧, 一定有大量的Nested Loops.

千问 · 2012-7-12 18:47:29

1,758,144,5214,149423,751.4357.6 1645439970

SELECT * FROM (SELECT a.*,rownum rnum FROM(SELECT b.SKU_id,prod_name,prod_st

1,318,015,773
9781,347,664.4268.1 1934054679

select * from (select a.*,rownum rnum from (select tbl_collect_detail.*,tbl_co

很明显，这两个语句都是分页程序，建议你把这两个sql 贴全，然后说出自己的需求，让大家出出主意；
您也可以搜索本论坛，参考别人的分页程序是如何写的；
分页程序一般都是按照时间排序的，您可以根据经验，子查询的条件里头，可以加上一定的时间限制，比如最近1天、1周、2周、1个月，而不要把所有的结果都query出来再排序，因为后面的数据，对一般分页程序来说，没有用，根本不需要