云和恩墨 数据和
为了及时共享行业案例，通知共性问题，达成共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》，通过对过去一段时间的知识回顾，故障归纳，以期提供有价值的信息供大家参考。同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。
墨天轮文档：《云和恩墨技术通讯（8月刊）》：https://www.modb.pro/doc/5227（复制到浏览器中打开或者点击文末左下角“阅读原文”立即下载）
以下截取部分页面：
这里推荐一个频发的案例：不合理业务设计导致CPU飙升。
在DBA日常运维中，在开发人员不是很了解数据库原理的情况下，设计不符合数据库常理的业务逻辑，从而导致数据库性能下降或者主机HANG住的事情时有发生，下面我们通过一则实际案例来说明：
问题描述
一条查询T1表的SQL语句，在行计划没有改变的情况下，逻辑读从之前的5万变成了14.5万，逻辑读使用CPU，从而导致CPU使用率急剧增加。逻辑读增加的原因，是因为在同一时段，开始了一条 DELETE T1 的业务SQL 开始执行， 每次平均删除6-14万不等的记录再提交，但是在未提交前，当查询SQL读取该表数据需要读取未提交前的镜像数据，构建一致读，从而增加了数据库的逻辑读。
问题分析
一、故障现象：
1、数据库AAS从15上升至150以上
2、主机CPU 100%
3、SSH登录不上
4、应用响应慢
5、TOP CPU SQL88gz2bjs25p5a 执行计划未改变，但逻辑读是之前的3倍。
通过带外登录主机，杀掉TOP CPU SQL88gz2bjs25p5a的SESSION后缓解。
分析定位应用从9点开始大量删除A.T1表的记录，导致问题SQL需要读取UNDO块BUILD CR块，最终导致SQL执行计划未变，但逻辑读增长至原来的3倍，导致 CPU使用率增长，进而影响其它应用进程。
二、故障根源
1、CPU 100%导致了性能问题，通过ASH定位到TOP CPU SQL
2、分析SQL88gz2bjs25p5a历史执行情况， SQL的执行计划未改变，但逻辑读是源来的3倍。
3、逻辑读变化可能的原因
a、近期INSERT了大量数据,导致表变大，通过分析表未增长，该项排除。
b、表上有大量变更，未提交的事物，常见批量UPDATE,DELETE。
4、CR Undo Records Applied Per Sec从0.08/s增长到问题时间段400000/s以上，验证的表上有大量变更，未提交的事物的猜测。
5、经分析问题时间点确实有较大的事务。
通过以上信息，进一步定位到从9点开始，有SQL进行了大量删除操作。与故障时间点吻合。
分析该SQL近10天的执行情况，确实有大量删除。
问题解决
1、临时杀掉TOP CPU SQL缓解
2、性能问题解决之后,数据库主机连接数从2000左右增至7800，连接数高，与业务组沟通，进行应用重启处理。
解决方案及总结
热表上的大事务，导致SQL构建CR块逻辑读增长，性能衰减，占用CPU资源导致了故障。
1， 建议业务调整，将delete 设计到的业务业务空闲的时候执行。
2， 建议大事务的delete 业务建议分批次执行，缩短事务长度，及时提交，减少其它会话的CR一致读。
《云和恩墨技术通讯（8月刊）》：https://www.modb.pro/doc/5227（复制到浏览器中打开或者点击文末左下角“阅读原文”立即下载）
