通过vmstat ,sar看内存使用都正常.没有page in/out.

Statistics from Oracle :

LIO PIO Transaction/Second CPU usage in oracle
8gb 17,990.70 148.68 56.54 157.9
10gb 17,707.28 95.95 56.54 167.9

可以看到disk read是降低了.但是cpu成本却增加.
首先想到sga的增加，带来sga的管理的开销，有可能加剧了latch 的竞争
毕竟CPU TIME 通常和 logical IO 是有关联的，应该从这里来看 ,LIO 没有什么变化而 CPU TIME 升高，
就只能从 SGA的管理和latch 方向去入手了
LIO 代表着数据库的查询的 逻辑读 的实际需求
也就是说 LIO不增加的情况下，CPU的使用量增家不代表 CPU的利用更充分了

从response time考虑。　
　　　response time = cpu time + wait time
transaction没变，　cpu time上去了,如果wait time减少了，减少的比率大于cpu time上去的比率的话，
这次sga　增大就是有效果的。相反的话，就没有效果。

Response Time = Service Time + Wait Time
Service Time：
Service Time = CPU Parse + CPU Recursive + CPU Other

Service Time 是在CPU消耗的时间
Service Time 由CPU for Parsing,
Recursive CPU usage (for PLSQL and recursive SQL) 和
CPU used for execution of SQL statements (CPU Other)组成

可以在sysstat中查询
'CPU used by this session' + 'parse time cpu' + 'recursive cpu usage'
select name,value
from v$sysstat
where name in ('CPU used by this session' , 'parse time cpu' , 'recursive cpu usage');
---------------------------------------------------------------- --------------
recursive cpu usage 275046
CPU used by this session 1886963
parse time cpu 15135
CPU other = CPU used by this session - parse time cpu - recursive cpu usage

parse time cpu 主要决定了解析统计
CPU other 主要决定buffer get block的统计

Wait Time：主要查看 db file sequential read 和db file scattered read 值
Wait Time 是Wait Events中消耗时间的合计

计算实例：
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read 4,232 10,827 52.01
db file scattered read 6,105 6,264 30.09
direct path write 1,992 3,268 15.70
control file parallel write 893 198 .95
db file parallel write 40 131 .63
-------------------------------------------------------------

Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------
CPU used by this session 358,806 130.5 12,372.6
parse time cpu 38 0.0 1.3
recursive cpu usage 186,636 67.9 6,435.7

From these figures we can obtain:
Wait Time = 10,827 x 100% / 52,01% = 20,817 cs
Service Time = 358,806 cs
Response Time = 358,806 + 20,817 = 379,623 cs
CPU Other = 358,806 - 38 - 186,636 = 172,132 cs

CPU Other = 45.34%
CPU Recursive = 49.16%
direct path read = 2.85%
如果这个CPU过高并不是由于某个进程引起的，而是由于平均的由很多进程引起的，那么你可以查看statspack中的Service Time
然后看CPU Other及SQL ordered by Reads

如果这个CPU过高并是由于某个进程引起的，那么你用10046及tkprof进行分析。
所以我们可以通过CPU Parse + CPU Recursive + CPU Other 这个三个值的百分比及top等待事件，来确认CPU的负载过高主要是哪块造成的
增加SGA大小，终究还是降低了磁盘读取量，降低了磁盘的IO Wait。

您可以按照以下步骤引用本文.本站收到您的引用通知后, 将自动链接您的文章, 以方便别人阅览 .

1. 启动您自己的博客管理页面, 并进入发表新文章的画面, 输入文章的内容. (如果您是ITPUB的博客请点这里.)

2. 复制下面虚线框里的连接字串, 把它们粘贴到您的文章中, 按照您的喜好修改一下表示文字.

3. 确认您选择了"发送引用通知"的选项.

4. 发表您的文章.

好啦, 您的文章就可以被自动链接到本站啦.