寻找隐秘的变量

白鳝的洞穴 2025-04-29

最近遇到一个很有趣的案例，用户告诉我一套并发交易量特别高的交易系统搬迁了存储后，突然经常出现卡顿了。按照用户的原话是一切都没变，业务没变，应用没变，交易量也没变，只是换了一个存储，然后就开始出各种各样的卡顿了。

通过AWR报告分析一下，确实按照一小时统计，平均每秒事务数略有增长，不到1%，不过row cache lock的争用要比以前严重得多，时不时就出现业务突然卡住了一样，过一阵子又缓解了。

按照用户的描述，其他都没变，只有存储变了，那么就去看存储吧。刚开始的时候，确实在存储侧发现了一些问题，经过调整后，存储的IO延时也正常了，不过卡顿问题并未解决。

于是继续分析系统的问题，很快发现系统中存在不少对于高并发交易十分致命的问题，比如几张争用十分严重的记录交易明细和审计日志信息的表没有做成HASH 分区表，表上的INITRANS、PCTFREE等参数也是用的默认值，SESSION_CACHED_CURSORS设置也是默认的，导致系统中每秒10000次左右的执行，7000+是需要做软解析的。应用写得还算规范，每秒的硬解析大概在40次左右，虽然这个值对于普通系统来说已经算是不小了，不过对于目前这个系统，也只能暂时先不管这个问题了。

给用户的建议是首先表和索引分区的工作一定要做，因为业务高峰期一小时平均的叶节点分裂数量已经高达400+，枝节点分裂都2+了。一旦出现枝节点分裂，那么很可能一个简单的INSERT语句会持续数秒钟甚至数十秒，这时候系统就会因为行锁冲突而产生严重的卡顿了。在应用开发商完成表分区设计的验证之前，我先建议他们加大几个关键索引上的ITL数量和PCTFREE参数，并且每天在晚上非业务高峰期做索引REBUILD。这个措施起到了一定的作用，卡顿有所好转，但是还是偶发。

虽然近期的一些优化措施用户已经接受，并且交给研发部门加快实施了，不过他们一直想不通，为什么这个系统什么都没变，搬迁一下，以前很稳定的系统就故障频繁了。大家讨论了一下午也没抓到要点。有个哥们偶然说这回搬迁把应用服务器换了台新的，只有这两台数据库服务器还是老设备了，是不是把这两台服务器换新的能改善一下性能。

我突然灵光一现，换数据库服务器能否解决这个问题，十个更复杂的问题，很难一下子评估出结果。不过更换了应用服务器这一点变数，以前是没有想到的。于是用户再次取分析业务高峰期的每秒交易数量，通过监控系统发现虽然总量上的变化不大，但是交易的分布情况发生了较大的变化，在某些高峰时点的交易总量明显有较大的变化，远远比一小时平均值的增长要大得多。

我们在AWR报告中看到的往往是经过平均后的比较粗粒度的宏观数据，如果在宏观上变化不是很大，但是在微观的分布上发生了较大变化的业务负载，是很难从AWR数据中看到的。而这种变化是能够解释row cache lock争用变得更加严重的问题的。这种变化可能会引发质变，导致卡顿变得比以前更严重。可能以前的卡顿对于业务来说还能够接受，而变化之后，就变得不能接受了。

其实如果这个用户已经建立了全面的数字化运维体系，这个问题不需要经过几天的多次讨论，最终才被发现的。如果应用服务器的QPS被很好地监控了，那么应用服务器是否做了升级这件事根本就无需了解，只需要通过监控数据就可以自动发现问题了。用户其实也建立了数据库的监控系统，也采集了每秒事务数这样的指标。只不过他们采集了数据之后还需人去分析，当他们没想到这个变数的时候，是不会去分析每秒事务数的分布情况的变化的。如果他们不仅仅采集了这些指标，还对指标进行了自动化的分析，并建立了相关风险预警的模型，那么这些问题一旦出现，就会被发现了。这就是数字化运维体系建设对于企业数据库运维的十分重要的支撑能力的最好体现。

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

寻找隐秘的变量

评论