查看数据库运行的总体情况:
从图中可以看出:
- 这是一个双节点的rac中的一个节点的AWR报告。
- 数据库版本为:11.1.0.7.0
- 平台为Windows X86 64
- 有8颗CPU共16个核心数
- 一小时内产生了两份快照
- 一小时内DB Time为174
- 所以,可以计算出这个快照周期内数据库负载为:174/(60*16)=18%。说明此时间段内数据库的负载是很低的。但是要注意一点,由于AWR报告展示的一段时间内的统计数据,如果快照跨度包括了大量的空闲时间,那么计算出来的CPU平均利用率也会偏低。
- 图中10点产生快照时候,数据库中有166个session;等到11点时数据库中有181个session
查看负载分析表:
建议重点关注以下数据项:
Redo size: Redo size 单位 bytes,redo size可以用来估量update/insert/delete的频率,大的redo size往往对lgwr写日志,和arch归档造成I/O压力。
如何解决每秒钟产生大量redo?
- 增加redo log的size
- 增加redo log组
- 增加redo buffer
Logical reads、Block changes、Physical reads、Physical writes:,评估数据库的读/写繁忙程度,判断数据库的活动性质和规模。
逻辑读的单位是块,表中每秒读了50290.4块,那么大小就是50290.4*8K=393M;逻辑读影响全表扫描。
Parses、Hard parses:SQL软解析以及硬解析的次数,评估SQL是否需要优化。
Executes、Transactions:每秒/每事务SQL执行次数、每秒事务数.每秒产生的事务数,反映数据库任务繁重与否。
Recursive Call:递归调用占所有操作的比率.递归调用的百分比,如果有很多PL/SQL,那么这个值就会比较高。
Rollback:每秒回滚率及每事物回滚率,因为回滚很耗资源,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争。
查看实例效率分析报表:
Instance Efficiency Percentages报表显示了Oracle关键指标的内存命中率及其它数据库实例操作的效率:
Buffer Nowait %:在内存获得数据的未等待比例。这个值一般需要大于99%,否则可能存在争用。
Buffer Hit %:数据块在数据缓冲区中的命中率,通常应在95%以上。否则需要调整重要的参数,或者要加大db_cache_size。
Library Hit %:SQL在共享区的命中率,通常应该在95%以上。
Soft Parse %:软解析的百分比,通常应该在95%以上。,
Execute to Parse %:语句执行与分析的比例,反映SQL的重用率。
查看共享池统计报表:
Shared Pool Statistics
Memory Usage %:共享池内存使用率,正常应在75%~90%之间,过低说明有浪费,过高则说明有争用。
% SQL with executions>1:执行次数大于1的SQL的比例。
% Memory for SQL w/exec>1:执行次数大于1的SQL消耗内存的占比。
查看系统Top10等待
一个性能良好的系统,DB CPU项应该排在前5之内
查看SQL统计信息:
建议重点关注以下:
SQL ordered by Elapsed Time:记录了执行总时间最长的Top SQL,其中Elapsed Time = CPU Time + Wait Time
SQL ordered by CPU Time:记录了占CPU时间最长的Top SQL
SQL ordered by User I/O Wait Time:记录了执行过程中等待IO时间最长的Top SQL
SQL ordered by Gets:记录了执行最多逻辑读(逻辑IO)的Top SQL
SQL ordered by Reads:记录了执行最多物理读(物理IO)的Top SQL
SQL ordered by Executions:记录了执行次数最多的Top SQL,即使单条SQL运行速度飞快,任何被执行几百万次的操作都将耗用大量的时间。
SQL ordered by Parse Calls:记录了软解析次数最多的Top SQL
查看Undo资源信息:
Undo Statistics部分记录了回滚相关的信息:
查看行锁等待信息:
Segments by Row Lock Waits表展示了行锁等待信息:
当一个进程在正被其它进程锁住的数据行上获得排它锁时会发生等待,这种等待经常是由在一个有主键索引的表上做大量INSERT操作时引起。