AWR是专门用来生成性能报告的，可以把他看做是oracle 9i 的statspack的一个升级版！
数据库的性能分析，大致上可以分为两个方面，会话级和系统级！
1.会话级
如果可以确定某个会话存在的性能问题 （也可能是某个用户提出的一个操作缓慢的申告），那么我们就可以针对这个去定的会话进行分析。最常见的分析方法是对这个会话做一个SQL_TRACE或者10046事件，通过分析trace文件来确定问题的所在。
2.实例级
当我们无法确定那个会话性能有问题（或者说每个会话性能力更都有问题）的时候，就需要从实例级别来分析问题的所在，这很有可能是实例整体性能下降导致的。为了获得一个实例的整体性能数据，可以查询一些动态性能视图，比如：v$sysstat,v$system_event；为了查询实例里的整体性能情况，可能要查询 很多方面的信息，比如SQL，比如I/O，比如等待，需要查询非常多的试图。针对这种情况，在Oracle 10g之前，statspack工具包是实例级性能分析的首选工具，它能够定期收集数据库的性能信息，然后生成报告：在10g里，Oracle提供了一个新的性能采集和分析工具的AWR（automatic workload repository）。
AWR的性能数据是oracle自动采集和保存的，采集周期是1小时，不需要人为干预。
===================================实验：==========================================
如何去生成：AWR的性能报告！
$ORACLE_HOME/rdbms/admin/awrrpt.sql
以sysdba的身份运行这个脚本！
sqlplus / as sysdba @awrrpt.sql
==================================AWR性能报告分析==================================
读AWR报告绝非是从头读到尾的，而是用户根据自己的实际情况来从报告中获取自己需要的信息！
比如OLTP：
1.library hit
2.buffer hit
这两项就应该非常关注，因为OLTP系统是一个SQL执行非常密集的系统，共享池命中率低说明有很多SQL不能被重用，需要重新解析，这会大大降低系统的性能和SQL的执行效率！
Buffer hit 在OLTP系统中也非常重要。OLTP系统要求SQL执行的效率非常高，当SQL需要的数据块都能够保留在内存中，那么SQL执行效率自然要比从磁盘读取数据块要高很多，当这个值越接近100时，说明内存中的SQL访问的数据块越多，也就是从磁盘上读取的数据块越少。
反之，如果是OLAP或者是数据仓库，那么完全可以忽略这两个性能指标，即使是他们非常低，因为OLAP系统数据库中通常是运行一些报表分析的SQL，这些SQL都是一些聚类查询的SQL，这些SQL执行时间都非常长，而且每个SQL查询的数据块都可能不相同，所以数据块很难长时间的缓存在内存分钟；另外OLAP系统本身执行的SQL重复率就不高，不需要要求这些SQL重用，甚至在OLAP系统分钟，绑定变量会导致负面的作用。
================================要注意的几个参数=====================================
第一部分：
sessions：
表示采集是实例连接的会话数，这个数字可以让我们连接数据库的并发用户大概的情况，这个数值对于判断出数据库的类型有帮助。
cursors/session:
每个会话数平均打开的游标数
DB Time
这个数值比较重要，他表示用户操作花费的时间，包括CPU的时间和等待事件。要注意它指的是用户操作的时间，而不是包含数据库后台进程花费的时间。举例：如果在60分钟的周期中，DB Time的值高于400那么说明数据库已经相当忙碌了！如果出现了这样的情况，那么就应该去TOP5的等待事件中去查看究竟是什么时间占用了系统如此多的时间！
☆☆☆☆☆☆
AWR中所有的时间都是累计时间！！！
==================================report summary====================================s
1.cache sizes
列出了AWR在性能采样开始和结束的时候，数据缓冲区（buffer cache）和共享池（shared pool size）的大小。通过比较前后的大小，可以了解系统内存消耗的变化。
2.load profile
这两个部分是数据库资源负载的一个明细列表，分割成每秒钟的资源和每个事务的资源负载情况，性能指标的含义如下：
redo size： 每秒（每个事务）产生的redo量。
Logical reads：每秒（每个事务）产生的逻辑读（对应于物理读）
Block changes：每秒（每个事务）改变的数据块数
Physical reads：每秒（每个事务）产生的物理读
Physical writes：每秒（每个事务）产生的物理写
User calls：每秒（每个事务）用户的调用次数
Parses：每秒（每个事务）分析次数
Hard parses：每秒（每个事务）硬分析次数
Sorts：每秒（每个事务）排序次数
Logons：每秒（每个事务）登陆数据库次数
Executes：每秒（每个事务）SQL执行次数
Transactions：每秒的事务数
☆☆☆☆☆☆
通过上面的一些参数，可以对数据库的运行情况有一个大概的了解。
====================Instance Efficiency Percentages（Target 100%）=========================
这一部分是内存效率的统计信息，个人觉得对于OLTP系统来说，它的意义比较重大，这些值都应该尽可能地接近100%；对于OLAP系统来说，他的值高低似乎对系统的影响不大，因为在OLAP中，大查询的数据（也就是他的执行计划是否最优），才是对性能影响最大的因素。
其中各个参数的含义如下：
buffer nowait%：非等待方式获取数据块的百分比
redo nowait%：非等待方式获取redo数据百分比
in-memory sort%：数据块在内存中排序的百分比
library Hit%：共享池中SQL解析的命中率
soft parse：软解析在总解析数的百分比
Execute to Parse%：执行次数对分析数的百分比
Latch Hit%：latch命中率百分比
Parse CPU to Parse Elapssd%：解析总时间中消耗CPU的时间百分比
%Non-parse CPU：CPU非分析时间在整个CPU时间的百分比
对于OLTP系统，数据库内存效率的高低对性能影响非常大，这一部分正是oracle内存效率的统计信息，如果这部分那个数据偏低，那就要做相关的分析研究了，比如soft parse%值偏低，说明系统中有些SQL没有被重用，最优可能的原因就是没有绑定变量；在比如buffer hit%太低，说明很多数据块没有被缓存在内存中，可能的原因是内存（SGA）太小，导致一些数据被刷到磁盘中，这时候就要考虑加大SGA的尺寸；再比如说buffer Nowait%的值太小，说明发生SQL访问数据块的时候数据库正在被别的会话读入到内存中，需要等待这个操作完成，发生这样的情况通常是某个数据块变成了热块（hot block）
===============================Top 5 timed Events=====================================
这一部分我认为是AWR的最重要的一部分，我每次看AWR的时候，最先看的就是这里！
这一部是AWR报告中最重要的一部分，如果要寻找系统的性能问题，这一部分向我们提供了第一手的资料，通过这些信息，就能够知道等待事件比较长的事件，根据这些事件，去其他的部分具体化问题的原因，这样就能找到一种如何快速阅读AWR报告的方法！
==============================time model statistics=====================================
这一部分信息列出了各种操作中庸的数据库时间比例，这也是很有用的一部分！
比如其中的两个参数：
parse time elapsed 和 hard parse elapsed time，如果这两个参数的值都特别高的话，说明这个数据库里面几乎所有的SQL都是硬解析。其实在上面的一个参数%non-parse CPU就可以看到。
================================wait class===========================================
这一部分是等待的类型，这一部分信息又从另外一个角度帮助我们分析和确定等待的事件！
在一个AWR的报告中，其实性能问题可能只是一个原因所引起的。比如说是磁盘I/O能力不够，在AWR报告的各个部分都会呈现出由这个性能问题所引起的属于他们覆盖范畴的问题，即一个原因引起很多的表象，但我们从这个部分确定不了问题的时候，可能要从另外一部分的性能数据中就找到原因了。这也说明AWR报告完全不需要顺序的从头读到尾。
===================================wait event========================================
这一部分是整个实例等待事件的明细，他包含了TOP5等待事件的信息，这一部分只有在需要的时候才拿来使用，比如TOP5提供的等待信息依然不足以说明问题的所在，安么就需要这一部分进一步寻找一些等待时间来判断。
===============================backgroud wait events==================================
这个实例的后台进程的等待事件，这一部分也只有在需要的时候才会用到。比如如果我们怀疑用户的操作可能是由于后台的某个进程无法及时响应导致的，那么需要到这里来确定一下是否有后台进程等待时间太长的事件存在。
=============================SQL ordered by Elapsed time===============================
这一部分是按照SQL的执行时间从长到短的排序，SQL只是显一小部分，每条SQL语句都有一个SQL_ID，如果生成的AWR是HTML类型的，那么通过SQL_ID上的超级链接，可以在报告中直接定位到完整的SQL。
=============================SQL ordered by CPU time==================================
这一部分是SQL消耗的CPU时间从高到底的排序。
指标的含义如下：
CPU Time(s)：SQL消耗的CPU时间
Elapsed Time(s)：SQL执行的时间
Executions：SQL执行的次数
CPU per Exec(S)：每次执行消耗的CPU时间
％Total DB Time：SQL执行时间占总共DB time的百分比。
==================================SQL ordered by gets=================================
这部分列出的SQL获取的内存数据块的数量，按照由大到小的顺序排序。
实际上，我们孤立地去看这些指标的大小是没有实际意义的，他们是一些相对的数字。比如，我们没有前面的信息作为参考，只有这一部分排在第一位的SQL，认为他获取的内存块太多，会有性能问题，这是没有根据的。只有SQL没有长时间的等待，就不能说它有性能问题。我们必须首先确定存在性能问题的SQL，这些数值会给我们一些补充信息。
这部分的指标含义如下：
buffer gets：SQL执行获取的内存数据块数
executions：SQL执行的次数
gets per exec：每次执行获得的内存数据块数量
%Total：占总数的百分比
CPU Time(s)：消耗的CPU时间
Elapsed Time(s)：SQL执行的时间。
flashback table_name to before drop rename to table_name;
日志挖掘的小工具！！！
logminer
开启归档模式
startup mount;
alter database archivelog;
alter database open;
关闭归档模式
startup mount;
alter database noarchivelog;
alter database open;
切换日志组，归档日志！
alter system switch logfile;
将数据库启动到闪回的状态！
shutdown immediate
startup mount
alter database flashback on;
alter database open;
select flashback_on from v$database;
文章评论