查看数据库运行的总体情况：

DB Time不包括Oracle后台进程消耗的时间。如果DB

Time远远小于Elapsed时间，说明数据库比较空闲

db time= cpu time + wait time(不包含空闲等待\非后台进程)=cpu time + all of

nonidle wait event time

数据库负载为：DB

TIME/(Elapsed*CPUS)*100%。AWR报告展示的一段时间内的统计数据，如果快照跨度包括了大量的空闲时间，那么计算出来的CPU平均利用率也会偏低。

BEGIN SNAP数据库中有166个session；等到11点时数据库中有181个session

查看负载分析表：

Load Profile

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；逻辑读影响全表扫描。

Logons大于每秒1~2个、Hard

parses大于每秒100、全部parses超过每秒300表明可能有争用问题。

Parses、Hard parses：SQL软解析以及硬解析的次数，评估SQL是否需要优化。

Executes、Transactions：每秒/每事务SQL执行次数、每秒事务数.每秒产生的事务数，反映数据库任务繁重与否。其中硬解析的次数，硬解析太多，说明SQL重用率不高。每秒产生的硬解析次数,

每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。

Recursive

Call：递归调用占所有操作的比率.递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。

Rollback：每秒回滚率及每事物回滚率，因为回滚很耗资源，如果回滚率过高，可能说明你的数据库经历了太多的无效操作

,过多的回滚可能还会带来Undo Block的竞争。

查看实例效率分析报表：

Instance Efficiency

Percentages报表显示了Oracle关键指标的内存命中率及其它数据库实例操作的效率:

Buffer Nowait %：在内存获得数据的未等待比例。这个值一般需要大于99%，否则可能存在争用。

Buffer Hit

%：数据块在数据缓冲区中的命中率，通常应在95%以上。否则需要调整重要的参数，小于90%可能是要加db_cache_size。对于一般的OLTP系统，如果此值低于80%，应该给数据库分配更多的内存

Library Hit %：SQL在共享区的命中率，通常应该在95%以上,如果library hit

ratio低于90%，可能需要调大shared pool区

Soft Parse %：软解析的百分比，通常应该在95%以上。

Execute to Parse %：语句执行与分析的比例，反映SQL的重用率。

Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低(可参考90%阀值)，考虑增加LOG

BUFFER。

In-memory

Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调PGA(10g)。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，

注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。

Soft

Parse：软解析的百分比(softs/softs+hards)，近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。

查看共享池统计报表：

Shared Pool Statistics

Memory Usage

%：共享池内存使用率，正常应在75%~90%之间，过低说明有浪费，过高则说明有争用。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。

如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。

% SQL with

executions>1：执行次数大于1的SQL的比例,如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。。

% Memory for SQL

w/exec>1：执行次数大于1的SQL消耗内存的占比,在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。

当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。

查看系统Top10等待 Total Call Time

如果‘buffer busy wait’是较严重的等待事件，我们应当继续研究报告中Buffer

Wait和File/Tablespace

IO区的内容，识别哪些文件导致了问题。如果最严重的等待事件是I/O事件，我们应当研究按物理读排序的SQL语句区以识别哪些语句在执行大量I/O，并研究Tablespace和I/O区观察较慢响应时间的文件。如果有较高的LATCH等待，就需要察看详细的LATCH统计识别哪些LATCH产生的问题。

一个性能良好的系统，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操作时引起。

等待事件:

log file parallel write：从log buffer 写redo 记录到redo log

文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，当flush log

buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O

操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file

member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file

的写入成本。通常称为同步成本率。改善这个等待的方法是将redo

logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo

log和data的数据文件位于不同的磁盘中。

log file

sync：当一个用户提交或回滚数据时，LGWR将会话的redo记录从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率,

为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上，提高I/O的性能。

需要注意在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中就应该注意，对于这样的查询应该进行避免使用索引扫描。

Direct Path Read：一般直接路径读取是指将数据块直接读入PGA中。一般用于排序、并行查询和read

ahead操作。这个等待可能是由于I/O造成的。使用异步I/O模式或者限制排序在磁盘上，可能会降低这里的等待时间。

direct path write：直接路径写该等待发生在，系统等待确认所有未完成的异步I/O

都已写入磁盘。对于这一写入等待，我们应该找到I/O

操作最为频繁的数据文件(如果有过多的排序操作，很有可能就是临时文件)，分散负载，加快其写入操作。如果系统存在过多的磁盘排序，会导致临时表空间操作频繁，对于这种情况，可以考虑使用Local管理表空间，分成多个小文件，写入不同磁盘或者裸设备。

查询所有等待事件及其属性：

select event#, name, parameter1, parameter2, parameter3 from

v$event_name order by name;

参考

https://blog.csdn.net/daf380/article/details/86598468

https://blog.csdn.net/demonson/article/details/79474133

--单实例下生成AWR报告

SQL> @?/rdbms/admin/awrrpt.sql

--RAC环境下生成AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrgrpt.sql

--指定数据库实例生成AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrrpti.sql

--生成SQL语句AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

--指定实例生成SQL语句AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpi.sql

--生成比较的AWR报告

SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

--RAC环境下生成比较的AWR报告

@$ORACLE_HOME/rdbms/admin/awrgdrpt.sql