‘壹’ oracle awr报告怎么分析一个sql的性能好坏
awr里面只能初步判断，判断标准包括，执行次数，执行时间等。还要根据报告的等待事件等来确定是否要对sql进行调整。再往下就要自己对sql进行执行计划分析，10046,10053事件的追踪了。
‘贰’ pl/sql 中 怎么生成awr报告
AWR报告的原理是基于Oracle数据库的定时镜像功能。默认情况下，Oracle数据库后台进程会以一定间隔（一小时）收集系统当前状态镜像，并且保存在数据库中。
生成AWR报告时，只需要指定进行分析的时间段（开始镜像编号和结束镜像编号），就可以生成该时间段的性能分析情况。AWR镜像保存在数据库中的时间为一个月左右。
‘叁’ oracle的awr报告分析parse cpu to parse elapsd 低怎么优化
cpu较高，一般是SQL执行频率太快导致，看看“SQL ordered by CPU Time”中有没有异常的SQL
‘肆’ 如何使用AWR报告来诊断数据库性能问题
Interpretation
在处理性能问题时，我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。
AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。
•
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体call time的百分比来进行排序的。
根 据Top 5
Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据
库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比
10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
• 事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。
• 事件"db file sequential read"一般是由不能做多块读的操作引起的单块读（如读索引）
其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的操作）；对于这样的SQL，过多的IO操作也是一个症状。关于CPU使用方面，我们会在之后讨论。
在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。
过多的IO相关的等待一般会有两个主要的原因：
• 数据库做了太多的读操作
• 每次的IO读操作都很慢
Top 5 Events部分的显示的信息会帮助我们检查：
• 是否数据库做了大量的读操作：
上面的图显示了在这段时间里两类读操作都分别大于1000万，这些操作是否过多取决于报告的时间是1小
时或1分钟。我们可以检查AWR报告的elapsed time如果这些读操作确实是太多了，接下来我们需要检查AWR报告中 SQL
Statistics 部分的信息，因为读操作都是由SQL语句发起的。
• 是否是每次的IO读操作都很慢：
上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的
至于8ms是快还是慢取决于底层的硬件设备；一般来讲小于20ms的都可以认为是可以接受的。
我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。
‘伍’ 除了做AWR，运行什么语句找到数据库最慢的SQL语句
1，两个快照之间。
2，Executions 执行次数
Rows per Exec 每次执行处理的行数
Rows Processed 总处理行数
CPU per Exec是单个SQL的CPU耗时
Elap per Exec是执行一次SQL的平均时间
‘陆’ 系统的一个异常SQL的处理
下面是在awr报告里面看到的有问题的sql，是9个变量的，在应用前台属于关联查询，在sqlplus里面手工执行检查实际执行情况如下：
下面是查询到的绑定变量值，可以通过查看v$sql_bind_capture视图来查看变量的实际值，如果时间比较久，可以使用如下的语句查看历史的绑定变量信息
以下是开启了autotrace 选项跟踪的手工执行情况，从执行效率上看是没有问题的。
从执行计划和表的数据量等方面判断如果sql的开销有问题，应该出现在表SAMS_CHECKINOUT上面，下面检查该表上面索引的创建语句看是否有问题
下面是在awr报告里面看到的有问题的sql，是9个变量的，在应用前台属于关联查询，在sqlplus里面手工执行检查实际执行情况如下：
下面是查询到的绑定变量值，可以通过查看v$sql_bind_capture视图来查看变量的实际值，如果时间比较久，可以使用如下的语句查看历史的绑定变量信息
以下是开启了autotrace 选项跟踪的手工执行情况，从执行效率上看是没有问题的。
从执行计划和表的数据量等方面判断如果sql的开销有问题，应该出现在表SAMS_CHECKINOUT上面，下面检查该表上面索引的创建语句看是否有问题
从上图可以看到，实际测试出来的执行计划跟awr报告上不同。
现在要对sql做测试
我们通过/*+ gather_plan_statistics */ 收集的相关执行计划及其统计信息与该SQL的AWR报告中的执行计划不同，且逻辑读的数量与AWR报告中的数值也相差巨大。因此，为了更准确的判断问题，按以下方法测试。
1、SQL在生产库（SAMS库的实例 1上，实例名为sams1 ）上，在SQLPLUS中执行。
2、执行后，在同一SQLPLUS窗口中，立即执行以下命令：
结果如下：
1、在目录下创建一个脚本文件，用来获取更加相信的信息。
2、在SQLPLUS中，执行以下命令：@sql_rpt 3271368959 1 24114 24115 99vaabs5ptktb
4、执行完成后，在该目录下生成一个HTML文档，拿到更加详细的sql统计信息附带表的数据信息
初步分析如下：
1、该SQL执行一次的逻辑读为11130块次，其中第37步的逻辑读为6127块次，占了一半还多。而该步的操作是根据前面的获取到的ROWID，回表SAMS_CHECKINOUT获取"SC".“CHECKTIME"[TIMESTAMP,11], "SC"."VERIFYCODE"[CHARACTER,4], "SC"."SN"[NVARCHAR2,40], "SC"."INSYSTIME"[TIMESTAMP,11]四列的内容。
2、第38步对SAMS_ICLOCK表的全表扫描，对整个SQL的逻辑读也有较大贡献。但这个不是问题的关键
另外索引上有两个想法：
1、新建组合索引或改造已有索引，按如下顺序构建组合索引：
（BADGENUMBER, CHECKTIME, SN, VERIFYCODE, INSYSTIME）
2、在表SAMS_ICLOCK上创建组合索引，列名及顺序如下：
（SN, ALIAS）
这两个索引先暂时不创建，先从其他方面入手
由于在测试过程中，其生成的执行计划从未与AWR中显示的执行计划一致过。所以，这也许是造成不能模拟出2亿个块次逻辑读的一个原因。因此，把有问题的SQL的执行计划绑定到的测试SQL上。然后执行该测试SQL，并观察和分析测试SQL的执行过程和结果来做出进一步的处理。
为完成上述想法，需要用到ORACLE的SQL PROFILE在不改变SQL文本的前提下，改变其执行计划。操作方法如下：
1、在SQLPLUS中，生成问题SQL的创建SQL PROFILE的脚本。该脚本执行后，会要求分别输入SQL_ID和PLAN_HASH_VALUE的值。而我们问题SQL的SQL_ID是99vaabs5ptktb，PLAN_HASH_VALUE的值是4243346097。脚本执行完成后，会在运行SQLPLUS的当前目录中生成一个脚本文件。其名称在执行脚本过程中的结尾有显示。为描述方便，简称该生成的S脚本文件为“问题SQL脚本”。
2、再次执行该脚本，只不过这次输入测试SQL的SQL_ID和PLAN_HASH_VALUE。其SQL_ID为3kys9xsdjrm3b，PLAN_HASH_VALUE的值为561269195。为描述方便，简称该生成的脚本文件为“测试SQL脚本”
3、在文本编辑工具中分别打开上述两个脚本，将问题SQL脚本中出现在以下特征文字之间的文字（不包含特征文字 ）复制并覆盖掉测试SQL脚本中同样位置的原文字：
h := SYS.SQLPROF_ATTR(
………
……….
……….
:signature := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt);
4、将测试SQL脚本另存为一个文件（后缀名为.sql）
5、在SQLPLUS中执行第4步另存后的脚本。
6、在SQLPLUS中原封不动的执行原测试SQL。(注：执行前设置SQLPLUS格式,以避免格式混乱。比如 set lines 200 set pagesize 100 )
7、执行 select * from table(dbms_xplan.display_cursor('','','allstats projection last'));
如果正常生成脚本，没有报错信息出现在屏幕上，就是生成脚本成功。比如出现下面的提示就是正常的：
‘柒’ 如何利用pt-query-digest分析慢查询日志top SQL
Oracle数据库可利用awr报告来查找top sql，其实MySQL中，我们可以利用pt-query-digest工具来查找时间最长的TOP SQL。
pt-query-digest可以从普通MySQL日志，慢查询日志以及二进制日志中分析查询，甚至可以从SHOW PROCESSLIST和MySQL协议的tcpmp中进行分析，如果没有指定文件，它从标准输入流（STDIN）中读取数据。
[apps@mvxl0782 bin]$ pwd
/apps/tool/percona-toolkit-2.2.10/bin
[apps@mvxl0782 bin]$ ./pt-query-digest /apps/logs/mysql/slow3306.log
整个输出分为三大部分：
1、整体概要（Overall）
# 8.9s user time, 50ms system time, 25.92M rss, 200.46M vsz
‘捌’ 如何通过awr，ash，addm报告查看oracle的异常sql语句
AWR（ Automatic Workload Repository ）报告是对oracle的性能评定以及发现问题SQL语句的重要手段。 AWR报告的原理是基于oracle数据库的定时镜像功能。默认情况下，Oracle数据库后台进程会以一定间隔（一小时）收集系统当前状态镜像
‘玖’ 如何每天从awr抓取top sql
AWR的数据主要有两部分组成：1）保存在内存中的系统负载和性能统计数据，主要通过v$视图查询 ；2）mmon进程定期以快照(snapshot)的方式将内存中的AWR数据保存到SYSAUX表空间中，主要通过dbA_*视图访问。1. AWR快照的生成默认情况下，每隔一小时自动产生一个快照，保存最近7天的信息，可以通过以下语句查询：sql>select SNAP_INTERVAL,RETENTION from dba_hist_wr_control;SNAP_INTERVAL RETENTION----------------------------------------------------------+00000 01:00:00.0 +00007 00:00:00.0可以通过以下语句修改时间间隔和保存时间(以分钟为单位)：exec dbms_workload_repository.modify_snapshot_settings(interval => 30, retention = > 10*24*60);也可以根据需要随时手动生成快照：exec dbms_workload_repository.create_snapshot;2. AWR报告的生成以sysdba运行如下命令：@?/rdbms/admin/awrrpt.sql3. AWR报告的分析策略因为AWR报告非常长，不可能从头到尾一字不漏的去看，要有选择的去看重点部分。最好能对照的来读，即和系统正常情况下的AWR报告对比，找差异。AWR报告采用总分的形式，前面是系统的整体情况，后面是各个部分细节，一开始不要陷入细节，先分析系统的整体状况，对于后面的专题分析，要根据关注点的不同，采取跳跃式分析。还要根据具体业务的不同，决定某种现象是否正常。系统整体状况方面1）Load Profile：分析系了解系统整体负载状况，如每秒中的事务数/语句数，每秒/每事务物理读写次数(Physical Reads/Writes), 逻辑读写次数(Logical Reads/Writes)，sql语句的解析(Parse)，特别是硬解析次数等。2）Instance Efficiency Percentages：各指标都应接近100%，除了：execute to parse (70%以上)和parse cpu to parse elapsed。如果不符合，基本可以确定系统存在性能问题；但是如果反过来，即都符合，也不能说明系统完全正常，还要看实际情况。具体状况方面1）Top 5 Timed Events：这里列出消耗时间最多的5个等待事件，每种等待说明，都表示一种原因，如：db file sequential read表示按索引访问出现等待，db file scattered reade表示全表扫描访问出现等待事件。2）Top N sql：根据时间消耗，内存消耗，物理I/O等排序，对相关sql分析执行计划3）如果是rac环境，需要特别关注rac Statistic中的相关指标4）sga pga分析5）分析表空间、数据文件I/O
‘拾’ 除了做AWR，运行什么语句找到数据库最慢的SQL语句
一般没有上awr，ash时，简单下我就直接用v$sql查看下top disk reads，一般相对来说单次buffer gets大，disk reads也会是top的，当然IO只是一部分，例如cpu的消耗等，sql执行过程中产生的latch竞争 热点快等，更多是由于并发竞争，单独看sql逻辑读是重点，而物理读top是比较容易体现此sql的IO消耗的，物理读大的sql往往逻辑读也是top的！