awr报表解读

1.

• Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否
• Logical reads:平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB Block Gets.逻辑读大小可以看出数据库消耗的系统资源，特别是cpu资源的情况，逻辑读越大的系统消耗cpu也越高。
• Block changes:每秒block变化数量，数据库事务带来改变的块数量。
• Physical reads:平均每秒数据库从磁盘读取的block数。物理读的值越高，说明系统对于i/o的负载越大，如果某个系统的物理读突然变高。就要查查是不是某个应用走了全表扫描了。
• Physical writes:平均每秒数据库写磁盘的block数。
• User calls:每秒用户调用次数。
• Parses:每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。在这里，fast parse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse则是指都不命中的情况。硬分析的数量。
• Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。
• Sorts:每秒产生的排序次数。
• Logons:每秒登陆的次数。
• Executes:每秒sql执行次数。
• Transactions:每秒产生的事务数，反映数据库任务繁重与否。
• % Blocks changed per Read：在每一次逻辑读中更改的块的百分比。
• Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
• Recursive Call %:递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。
• Rows per Sort:平均每次排序操作的行数。

2.enq: TX - row lock contention

引用

优化碰到的第一个wait event

enq是一种保护共享资源的锁定机制，一个排队机制，先进先出(FIFO)

发生TX锁的原因一般有几个

1.不同的session更新或删除同一个记录。

2.唯一索引有重复索引

3.位图索引多次更新

4.同时对同一个数据块更新

5.等待索引块分裂

通过数据系统视图检查果然是多个update的sql

select sid,username,event from v$session where stat in('WAITING') and wit_class!='Idle';

sid从上面的sql获得

select sid,sql_text from v$session a,v$sql b where sid in(282,496) and (b.sql_id=a.sql_id or b.sql_id=a.prev_sql_id);