前不久怼了一下马工 “你怎么还在招聘DBA?”    此文完全是瞎扯,后面没过几天，他约我来个辩论直播，好吧！满足他！不服就干，生死看淡！这里预告一下下周的直播，欢迎DBA们关注并出谋划策。

    好了，广告打完了，下面我们进入此文的正题，毕竟我们是一个数据库爱好者，技术为本。刚好今天有网友找到我，说我们阿里云上的数据库有性能问题，能否给点建议。这不刚好就是反击马工的有力证据吗？ 

    我看了一下阿里云的RDS 没有针对for Oracle的，可能是license问题。

    比较好奇的是居然有RDS for SQL Sever版本，难道是微软授权了。。不多说，我们言归正传。据网友反馈，这是一套运行在阿里云上的Oracle单实例，既然是性能问题，就要先看看故障期时间段的AWR报告吧，没想到故障期间实例基本夯死了，所以AWR快照根本就没有产生，只有ASH和故障前一天的AWR。我觉得也可以差不多将就分析了。

    我们可以看到这是一套Oracle 19c的单实例，也是目前比较主流的版本了，看云资源是16c/64G，其中给Oracle SGA分配了40g，这也算合理。对比前一天的AWR的AAS来看，故障时间段的ash AAS高出了一倍还多。接下来我们直接看看ASH top event：

    oh my God! 这么多的Latch，全是Concurrency，说明并发相比平时较高，其中最引人瞩目的是:latch shared pool，占比非常高，这通常是SQL硬解析时，需要分配share pool内存时申请latch所致，另外library cache:bucket mutex X是Oracle 12c后分化之后的event，跟之前版本中的library cache:mutex X是一回事，包括最后的cursor:pin S wait on X也是跟SQL解析有关，不用我多说，大家肯定都知道，网上文章多如牛毛，这里不再展开了。 另外一个latch:cache buffers chains通常是sql性能问题导致，比如全扫。

    对于event，我们通常会去关注event的P1,P2,P3是什么，ash也有类似的内容：

   毫无疑问，这里最严重的就是share pool的争用，其P2表示的是latch number，也就是说619 是19c版本中latch:shared pool的latch# 编号. 如果此时要进一步去定位具体是哪些硬解析导致的TOP SQL也可以的，直接看这里就行。

    对于force_matching_signature这个值，直接查询v$sql即可。到这里基本上分析完了。刚刚提到网友还有故障之前上午的awr报告，据反馈上午的业务比下午要少一半以上，业务性质类似，那么其AWR应该也是有一些参考价值的。继续来看这份看似正常的AWR吧。

    我们可以清楚地看到，实际上正常时间段压力还是有一些的，其中每秒钟的Hard parses还是略高(41.2/526.8≈8%），如果业务压力再大1~2倍的话呢，那么硬解析可能就15%了，大概率会出问题。此时可以通过Time model 模型进一步确认:

    这个数据非常的清晰直观，正常的情况下，硬解析占比time model指标都比较高了，一个相对好的系统来讲，应该低于3%才对。所以，我们可以想象，如果如网友所讲的那样，业务大2倍的情况下，那么硬解析这里大概率是20%+去了，甚至更高。因为数据库中，出故障的情况下，并非是线性关系，到达一下灵界点之后，性能会极速下降；尤其是这种解析问题，会影响整个数据库系统全局。

    期间网友反馈，之前就做过open_cursor参数的调整，从默认值300调整到了1000。如果我们要判断open_cursor参数是否合理，怎么办呢？实际上强大的AWR可以告诉我们：

    从这里的Instance Active statistics关键数据，我们可以得到很多有价值的信息。其中opened cursors cumulative，表示已经打开的游标数(累积值),由于这里这个awr报告的AAS是3.6,那么1088/3.6;平均每个session 每秒累积打开300多个cursor。所以open_cursor设置为1000肯定是足够的，这个参数是指的单个Session而非全部session。

     其次每秒累计打开1088个cursor，而session cursor cache hins是419.31，说明cursor的命中率只有40%左右，还是比较低的，也侧面反映出session_cached_cursors 参数设置偏小，检查发现确实是默认值。该参数一般可以设置为opened cursors cumulative/aas 大小相近的值即可，当然这是个人经验不是公式。另外这个命中率，也不代表一定参数问题，还有一种可能就是没有命中的都是硬解析呀，因为硬解析过高也会出现这种情况。如果要确认是不是硬件影响，结合execute count，以及load profile中每秒硬解析的次数大致就可以判断。 

    当然，从这个case来看，session_cached_cursors是偏小的。

    最后看这个库也仍然会发现不少低效SQL，平均单次执行超过几分钟的也还是有，这些低效SQL也需要DBA去进行优化整改的；当然，这个库也还有很多参数都没有调整，大都是默认配置。

简单地记录一下，阿里云上的Oracle也需要DBA！

最后：请大家来一些其他case分析，这几天awr我快看吐了。