数据库管理-第三十二期 数据库管理是一个持续的过程（20220825）

第三十二期 数据库管理是一个持续的过程

新的一期，半技术半扯淡，主要还是最近工作中遇到和处理的一些问题，又一次有感而发。

1 MAX_IOPS、MAX_MBPS和Resource Manager

首先这几个东西在我刚开始写这一系列文章的前几篇的时候就已经讲过，那会儿只讲了一些概念，有兴趣的可以回溯翻一下。那时候我说12.2上MAX_IOPS和MAX_MBPS是并没有起到很好效果的，但是我最近发现，在后续12.2的PSU中，这俩参数还是起到了一些效果，这次的优化就是基于这俩参数。
首先说下历史，因为IO限制这俩参数以前没起啥用，所以在某个PDB上就设置了1000的IOPS和50的MBPS，这个PDB也是前几期“壮汉挤门”的主人公，说白了就是人造热点。以前因为各种争用等待，SQL执行速率一直提不起来，其中主要是两个，一个就是疯狂update一行来维护全局唯一ID，另一个就是疯狂插入一个表记录日志。由于最近四川干旱，高温限电，很多地方的移动基站、网络设备也是受到了很大影响的，因此上周无论是告警工单还是派发工单量都是激增，之前小打小闹的“壮汉挤门”的优化在那时候看起来就捉襟见肘，没办法和甲方一道逼着业务方快速整改，把全局ID改为数据库sequence实现同时减少日志记录并拆分日志表部分日志异步入库。从这时起，一系列问题就出现了：首先，使用数据库sequence后全局ID获取不在受行锁、集群等待等影响，速度非常快，这就引起了另一个等待事件“resmgr: I/O rate limit”，到这时我才发现MAX_IOPS和MAX_MBPS是有效果的，而且最终是通过Resource Manager实现的，随即把IOPS调整到50000，MBPS调整到400。然而又大量出现另一个等待事件“resmgr:cpu quantum”，承载这个PDB的节点CPU都跑到90%以上，因为业务压力仍然非常大这里分析和尝试处理花了一些时间。最终判断是因为IOPS设置的过高，超过了集群承载能力，反过来触发了Resource Manager通过CPU限制来控制IO，而Resource Manager本身耗费了大量CPU资源。因此将该PDB的IOPS重新设置为25000，CPU随即下降，resmgr相关等待事件也随之下降，业务响应起飞。最终处理结果也验证了我的判断。后面又经过了一周的洗礼，这个业务PDB没有再出现问题，前台响应起飞。

2 DBRM和MMAN

这个是本周一遇到的一个BUG，大半夜（算是周二吧）起夜的时候收到短信告警，节点2出现ORA-445，这个报错一般和数据库进程异常有关，随即登陆到节点2检查，发现sqlplus登陆到数据库非常慢，查询系统性能视图也会卡顿一会儿才出结果。随即检查告警日志发现下面一些内容：

DBRM (ospid: 29533) waits for event 'latch: shared pool' for 3 secs.
DBRM (ospid: 29533) waits for latch 'shared pool' for 3 secs.

通过EMCC检查该节点阻塞会话，发现大量活动会话卡在MMAN进程的latch: shared pool等待事件上，这是这套数据库运行4年多第一次出现这个问题，从长期和数据库的斗智斗勇判断，应该是触发了某个BUG，因此在切走某些重要（其实是没人管）的PDB对应service后，关闭实例并重启，然而遇到另一个问题，数据库响应更慢了，top和free -m一看，好家伙用到swap去了，看起来刚才的MMAN异常并没有正常释放内存，只能手动重启主机，然后节点恢复正常。
既然我的基本判断是个BUG，那么老办法，MOS上提交了一个一级SR，最终对各项告警日志，追踪日志检查确认为一非常难触发的BUG：Bug 28625580 - DBRM waiting too long to get shared pool latch in memory RM code ( Doc ID 28625580.8 )。各位有兴趣可以自己去看看。

3 为什么数据库管理是一个持续的过程

第一节的内容，作为多个厂商共用的DBA，其实我并没有介入各个业务的研发过程，但是我仍然能够通过在数据库运维过程中的点点滴滴，比如SQL、等待、沟通等等知晓业务在数据库使用过程中的各项问题并给出优化反馈意见，虽然算是事后诸葛亮，但是也发挥了巨大作用，至少在本次事件中，提供了正确有效的优化建议，避免了这个业务系统的崩盘。而获取并分析相关信息本身就是一个长时间不断积累的过程。
第二节的内容，其实这不是我第一次大半夜起来处理问题了，常理来说，睡着了是听不到短信告警的，但是几乎每一次半夜出现异常我都能恰巧看到并及时处理，我相信这也是长期管理数据库过程中与数据库之间的某种所谓的“默契”吧。相信也有不少人跟我有相同的经历。
本期内容的具体问题处理，包括其中的临场原因分析和处置，其实也是长期持续数据库管理过程中积累下来的经验也好、技能也罢，是一个量变到质变的过程。所以我一直觉得，一个好的DBA不是一蹴而就的，除了要有扎实的理论知识，也需要丰富的实战经验，二者有机结合才能变得强大。另外，针对第二节的内容，我还是觉得，一个DBA还是得了解操作系统。

4 总结

本期内容涉及全是来自于对工作的感悟，还是有点乱糟糟的，继续：不知道写了些啥。
下期回归到之前AFD+multipath+udev那个坑爹事情，今晚再次割接处理，有了结果一起写。