awr报告小结

一、awr报告--靠前的重要

1、Lord Profile看负载

物理读

逻辑读

会话数

sql数

事务数

2、 TOP事件=Top 5 Time Events

3、top5 top10的SQL

执行时间长的（SQL ordered by Elapsed Time）

执行次数多的

没绑定变量的

4、top5 top10的SQL

执行时间长的

执行次数多的

没绑定变量的

5、同一时间段多对比几天的，看有没有波动

(1)Lord Profile

(2)Instance Efficiency Percentages (Target 100%) 

(3)top10--Background Wait Events

(4)Top 5 Time Events

(5)Shared Pool Statistics

(5)SQL ordered by Elapsed Time

(5)SQL ordered by Gets 

二、Hard Parse+Soft Parse+Soft Soft Parse

1、Hard Parse：第一次执行

语法分析

权限与对象检查

在共享池中检查是否有完全相同的之前完全解析好的. 如果存在，直接跳过4和5，运行Sql, 此时算soft parse.

选择执行计划

产生执行计划

2、Soft Parse(绑定变量): 在共享池中找到了执行计划

3、Soft Soft Parse：游标cache到pga中，对中间件的长连接有帮助

三、OLTP 系统(OLAP 系统重点优化 SELECT 语句)

1.等待事件enq: TX - row lock contention，direct path read 平均等时间查过3MS

2.Soft Parse %: 74.26 小于80%

3.SQL 优化 SQL ordered by Elapsed Time，SQL ordered by Gets 排在前面的查看SQL 执行计划

4.File IO Stats Av Rd(ms) 20MS 以下 IO比较良好

四、内存管理--等待事件

1、buffer busy wait

有很多会话修改相同的块容易出现这种问题

rac显示为gc buffer busy wait

2、row cache lock

是在修改行高速缓冲区（dictionary cache）时产生，

其中最典型的代表是设置Sequence的cache设得比较低的时间容易出现?

3、在10G、11G后，大部分lib cache lock/pin被Mutex代替

（1）内存不足、硬解析比较高（lib里放的sql语句）、并发比较高的时候容易出现

（2）模拟和表相关的lib cache pin，比如说表上带有DML 触发器，DML触发了触发器，另外的进程修改此触发器。

（3）模拟lib cache lock，

举个和表T相关的例子，

硬解析时会持有表T的lib cache lock，

进程A不使用绑定变量频繁执行和表T相关的硬解析，

进程B为修改表T的元数据，比如加个列。进程A写到lib cache中的SQL文本会失效了。

就会遇到lib cache Lock。

当然还会有其他的等待，比如Shared pool latch。

五、硬解析与游标共享

1、绑定变量

（1）需要修改代码

（2）列数据有倾斜，可能使用错误的执行计划。

2、传统的游标共享--cursor_sharing

(1)EXACT：默认SQL语句完全相同时才会重用。

(2)SIMILAR：尽量重用第一条SQL语句；但谓词条件可能会影响到执行计划时，重新分析。

(3)FORCE：不管谓词的值如何，一律重用第一条SQL语句

3、绑定变量窥探+ACS自适应游标共享

(1)BIND PEEKING在SQL第一次硬解析的时候查看一下谓词的值，以后所有执行只能走第一次硬解析时的执行计划。

(2)自适应游标共享是指依据绑定变量的具体值，从多个执行计划中选择适合该值的执行计划。

动力小刚于2019年5月  个人邮箱：zcs0237#163.com