20M1. 头部的DBtime/Elapsed Time 比值大约为230，这个就是平均活动会话，说明CPU负载较高，后面的load profile 里面 CPU每秒时间为49，超过了cores 32也可以说明，另外前面的session数超过1400+，也可以排查一下正不正常。
2. 另外，load profile 中 CPU 时间远远低于DBtime，说明IO或者其它非空闲类等待比较高（一般IO的原因比较多）。
3. Top 10 里面 cursor: pin S wait on X ，latch: shared pool和 library cache: mutex X 这个等待比较高，内存争用较大，一般是SQL过多解析造成，尤其是硬解析，检查一下后面的高版本SQL，前面load profile 里面每秒的SQL解析数量超过了400次（硬解析每秒27次）也可略作说明，再后面Time Model statistics里面也可以看到软解析和硬解析对DB time的占比比较高。
4. log file sync 这个等待比较高，建议优化（我的经验通常就是换快盘或者适当增加redo size等）。
5. latch: row cache objects 这个排在了首位，通过ASH查询一下看看这个事件当时的SQL能否找到，优化一下。
以上这些，在不考虑修改数据库各种眼花缭乱的参数情况下，大多与SQL性能不佳有关，redo这个的话，能上快盘就尽量快盘吧。
6. 内存上，服务器256G，目前PGA+SGA还占不到45%，一般是70%我觉得比较合适，当然只是我的经验哈，建议SGA再调大一点儿，PGA可以增加到16或者32。可以看到cache size 部分，share pool end值比begin大，也说明share pool不够，也需要调大SGA。
7. Share Pool Statistics 中 % SQL with executions>1 较低，说明SQL重用度较低，多和没有采用绑定变量的SQL较多有关，可以用force_matching_signature这个特性去抓一下相似的SQL，看看是否可以绑定变量改造。
以上就是我粗略的一些看法，一般AWR到了我手里，我个人经验比较关注的就是SQL统计部分，哪个SQL最爱冒头就按死哪个，多调优几个SQL后，数据库的整体性能可能就会有很大的改善。我个人不怎么喜欢动不动就去碰数据库的各种参数啥的（SGA/PGA除外，因为这个比较明显而且影响巨大），尤其是隐含参数，调优尽量以优化SQL为主吧。
评论
有用 2我大致看了下几个ASH报告，ASH我一般使用的话，就是根据 Top SQL with Top Events 这一节，抓取相关的SQL语句，然后查看它的执行计划，看看有没有什么可以调优的，实际上ASH报告最大的用处就是这个了。
引起SQL性能的变化原因很多，看看数据库有没有历史的基线做比对，没有的话，你就直接看他们的执行计划是什么情况，然后针对性调优就行，我个人经验的话，觉得实际上没有太大的必要去纠结“以前都正常但是现在就不正常”这类问题，因为很少能真正查出具体的原因的，出了问题你就看执行计划情况，见招拆招就行。
比如这几个ASH里面都提到这个SQL ‘277kx3y6px37s', 这个SQL 单次执行需要92秒，一个小时跑了900多次，应该是多会话去调用它的，看看它的执行计划是什么。
另外AWR报告里面还有个SQL bunvx480ynf57，这个SQL 就是个简但的 select 1 from dual ,不知道是干啥的，但是它一个小时内跑了18W次，这是个很大的解析负担，不必要的话都可以取消掉。
AWR里面，你首先就重点针对那些执行次数非常高，单次执行时间比较长的SQL，只要能把它们打掉，效果就会很明显了。
评论 有用 1