查看原文
其他

是的 公有云上的数据库也需要DBA

数据库恢复老司机 Roger的数据库专栏 2024-03-03

   前不久怼了一下马工 “你怎么还在招聘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我快看吐了。

   

继续滑动看下一个

是的 公有云上的数据库也需要DBA

数据库恢复老司机 Roger的数据库专栏
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存