客户的有一套数据库系统，单实例，这套系统针对线上业务，主要业务包括APP、微信小程序等。这套数据库每次在发布活动推送的时候，CPU资源都能达到接近100%，后来在中间件层做了一些会话连接限制，CPU资源消耗有所下降，在活动发布期间生成了AWR报告，活动发布时间分别为3月8日10：00和3月8日16:00，分析之后做了总结，但不确定总结得是否正确，希望各位老师和前辈帮助解惑，在此拜谢。
分析总结：客户的数据库主要消耗在CPU上，AWR报告中显示每秒的逻辑读有近200万，每秒执行的SQL语句有近2000条，查看AWR报告中的sql order by gets，虽然SQL语句的单次执行时间都很短，但每次执行都产生近2万的逻辑读，因此判断CPU消耗高的原因基本为SQL语句的逻辑读导致
现在客户想要增设CPU资源，从而可以承载发布活动推送时候的3倍负载压力，我的建议则是增设CPU资源治标不治本，可以从SQL语句的优化入手，降低逻辑读，或者改变数据库架构，因为毕竟单实例数据库的吞吐量和并发量有限，可以采用RAC架构分摊负载
再次感谢各位老师和前辈
评论
有用 0怀晓明老师您好，按照您的指导思路，我从统计信息入手，查看了相关表的统计信息以及表上索引的统计信息，发现这些表上索引的聚簇因子接近于表的行数，因此我判断不好的cluster factor导致SQL执行的时候访问了更多的数据块，从而导致较高的逻辑读，不知这么判断是否合理，我将查询结果添加到附件，希望老师能够协助审核判断，感谢
评论 有用 0 评论 有用 02p9kkyqyfm2ay，OLN_ORDER 上，OO.ORD_STATUS 、OO.REG_DT 、OO.ORDER_NO 考虑建索引，另外考虑用hint改变执行计划
86wdsb538ctdg，meta结果参考aschth4krpugd的，SQL应从left outer join改为join，同时考虑用hint改变执行计划。另考虑SCN_DY字段结合THAT_CD是否能过滤出更少的数据，其他字段如RL_SCN_YN、DEL_YN，从SQL含义本身推测可能不会有很好的过滤效果。
aschth4krpugd类似86wdsb538ctdg，优化思路类似
guq87fwdg9a7g除了你说的，还要改写SQL，主要是“TRUNC(A.REG_DT)=TRUNC(SYSDATE)”这段需要改为去掉字段上的函数。
评论 有用 0已经将优化建议以邮件形式发送给相关业务人员，同时我也会协助进行相关优化并跟进，在昨天的活动推送过程中，由于之前已经做了些许优化工作以及在中间件层做了会话并发限制，CPU资源开销已经明显下降，在此特别感谢怀晓明老师提供后续的优化思路。
评论 有用 0
墨值悬赏