SQL Statistics
AWR包含了一些不合的SQL统计值：
同样的，因为我们并没有看到latch相干的等待，latch在我们这个例子里并没有激发严重的机能问题;那么我们接下来就完全不须要分析latch相干的信息。
诀窍是可以或许评估引起这些等待的语句是否应用了最优的拜访路径。如不雅"db file scattered read"比较高，那么相干的SQL语句可能应用了全表扫描而没有应用索引(也许是没有创建索引，也许是没有合适的索引);响应的，如不雅"db file sequential read"过多，则注解也许是这些SQL语句应用了selectivity不高的索引大年夜而导致拜访了过多不须要的索引块或者应用了缺点的索引。这些等待可 能解释SQL语句的履行筹划不是最优的。
根据Top 5 部分的Top Wait Event不合，我们须要检查不合的SQL statistic。
在我们这个例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU;我们最须要关怀的是SQL ordered by CPU Time, Gets and Reads。
AWR申报中的"Top 5 Timed Events"部分就供给了如许的信息，可以让我们只存眷重要的问题。
我们会大年夜"SQL ordered by gets"入手，因为引起高buffer gets的SQL语句一般是须要调优的对象。
对这些Top SQL,可以手工调优，也可声调用SQL Tuning Advisor。
分析：
- -> Total Buffer Gets: 4,745,943,815
对于数据库整体的机能问题，AWR的申报是一个异常有效的┞凤断对象。
假设这是一个一个小时的AWR申报，4,745,943,815是一个很大年夜的值;所以须要进一步分析这个SQL是否应用了最优的履行筹划
- Individual Buffer Gets
膳绫擎的例子里单个的SQL的buffer get异常多，起码的那个都是8亿5切切。这三个SQL指向了两个不合的引起过多buffers的原因：
留意：对于某些异常劳碌的体系来讲，以上的数字可能都是正常的。这时刻我们须要把这些数字跟正常时段的数字作比较，如不雅没有什么太大年夜差别，那么这些SQL并不是引起问题的元凶(固然经由过程调优这些SQL我们仍然可以受益)
# 单次履行buffer gets过多
SQL_ID为'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL语句总共被履行了168次，然则每次履行引起的buffer gets跨越500万。这两个SQL应当是重要的须要调优的候选者。
# 履行次数过多
SQL_ID 'grr4mg7ms81' 每次履行只是引起16次buffer gets,削减这条SQL每次履行的buffer get可能并不克不及明显削减总共的buffer gets。这条语句的问题是它履行的太频繁了，6500万次。
改变┞封条SQL的履行次数可能会更有意义。这个SQL看起来是在一个轮回琅绫擎被调用，如不雅可以让它一次处理的数据更多也许可以削减它履行的次数。
我们还可以在AWR申报"Tablespace IO Stats"部分获得更具体的信息
【编辑推荐】
- 浅析开源数据库MySQL架构
- 一图秒懂中国数据库的40年江湖
- 十年DBA老兵：重Java轻SQL乃机能大年夜忌
- MySQL组复制技巧实现与数据库机能测试对象
- 关于数据库“状况”字段设计的思虑与实践
推荐阅读
【沙龙】51CTO诚邀您9月23号和多位技巧大年夜咖一路聊智能CDN的优化之路，抓紧时光哦！ 索引设计是数据库设计中比较重要的一个环节，对数据库的机能个中至关重要的感化，然则索引的设计却竽>>>详细阅读
本文标题：如何使用AWR报告来诊断数据库性能问题
地址：http://www.17bianji.com/lsqh/37579.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示