Oracle AWR文件导出、分析，查看Alert文件
一.AWR的概念
Oracle数据库是一个使用量很多的数据库，关于Oracle数据库的性能。Oracle10g以后，Oracle提供了一个性能检测的工具：AWR（Automatic Workload Repository 自动工作负载库）这个工具可以自动采集Oracle运行中的负载信息，并生成与性能相关的统计数据。我们可以根据这些统计数据来分析一些潜在的问题。
二.AWR的原理
Oracle启动后，后台会有个进程去每小时采集一次系统的快照信息，信息采集来源为： V$active_Session_History视图。该视图可以展示最近活动会话的历史记录。并将采集到的信息保存8天。（查询SQL：select * from dba_hist_wr_control;）采样频率和保存时间可配置。
快照由MMON和MMNL的进程自动地每隔固定时间采集一次。MMON进程负责执行多种和管理相关的后台任务，MMNL负责执行轻量级切高频率的管理相关的后台任务。
三.导出awr报告
oracle 可以将8天的awr快照数据进行储存，我们可以将oracle中的任何两个时间点（输入日期后，会返回相应的时段内，快照对应的时间）生成该段时间内的awr报告。具体生成方式有多种，一般需要sys权限，如果读者有更好的方法，欢迎讨论。
1.首先登陆sys用户下 sqlplus as sysdba;
然后，再新弹出的窗口中输入@?/rdbms/admin/awrrpt.sql
按照提示，输入导出脚本的类型（HTML还是text），输入HTML
这里输入的是返回几天的快照，这里输入1天，表示返回一天的记录
这里返回的是范围内的所有快照的信息。通过输入两个快照id生成两个快照点之间的报告信息。这里可以根据需要进行选择，比如说，四点的时候，系统出现了明显的卡顿，想要分析这个卡顿出现的原因，那么最好取三点到五点之间的日志，也就是对应的26和28 两个snapId的值。
从上图可以看出，id为21和22之间服务器进行了重启，不能选择这样的快照区间，不然会抛出异常。
这里，我们选择12点到18点之间的日志。
然后，输入返回awr对象的名称，建议写一些有代表意义的名称，便于以后查看。
然后就是一通滚屏，最后可以看到输出成功的提示：
导出的awr报告：
四.分析查看AWK报告
查看数据库运行的总体情况：
从图中可以看出：
- 这是一个双节点的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操作时引起。
五.查询数据库的alert
select * from v$diag_info;
VALUE
--------------------------------------------------------------------------------
1 Diag Trace
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
1 Diag Alert #数据库文件目录
/u01/app/oracle/diag/rdbms/orcl/orcl/alert
进入数据库alert 及trace目录，备份及清理
cd 进去
alert 下是log.xml 文件
注：转载自：https://www.cnblogs.com/liyasong
