数据库运维中，防患于未然为什么叫好不叫座

白鳝的洞穴 2025-05-14

759

很多用户都希望自己的数据库运维能够防患于未然，不过在具体实践中却不太愿意在这方面多花钱。以前我去给用户做数据库巡检的时候，发现了他们的很多隐患，在给领导汇报的时候，他很高兴，说一定认真去分析分析，加以改进。不过几个月后再次巡检的时候，发现他们根本没有对我上回发现的问题进行整改。在谈起这个问题的时候，那位领导问我：“如果我按照你的方案整改了，是不是以后就不会出问题了？”，我说这个不敢保证。于是领导说，既然如此，那么花精力去做这些整个意义就不大了。

上面的领导的观点代表了某些用户的想法，防患于未然是有成本的，而且花了成本不等于高枕无忧，于是就不太愿意在这方面花钱了。

另外一个案例，有一次一个用户给我发来一个AWR报告，说他们的系统昨天出了大问题，业务熔断了半小时，算是一个重大事故，随后几天也是卡顿不断。于是他们想让我帮忙分析一下。我看了一下，大量的 us方面的等待，在UNDO数据的小节看到得了的us、es，很明显是UNDO表空间不足了。于是让他们把UNDO表空间从500G扩到了2TB，扩完表空间后，系统就稳定了。事后他翻出我半年前的一个巡检报告，上面白纸黑字写了我建议他们的UNDO扩大到500G。于是就说，为什么我给他们建议的大小不够用了。不知道他们是想让我背一下锅还是真的不懂随着业务的变化，很多最佳配置都是在变化的。这个案例也说明了一个问题，防患于未然不是一年一两次巡检就能真正做到的。

数据库是一个动态的系统，周边的应用、负载、网络、安全、存储等都是在动态变化的，因此风险并不是固定的，而是在随时动态变化的，因此防患于未然的工作需求也是动态变化的。需要动态处置的事情，成本就是相对较高的，如果没有很好的自动化手段，那是很难落地的。这是很多用户都在口头上追求防患于未然，但是实际上很少投资在这方面的主要原因之一。

要做到防患于未然，其基本原理就是防微杜渐，在问题不严重的时候，或者某些条件没有达到的时候，风险是不会变成故障的。当前不会引发故障的风险有没有必要花成本去优化，这一点实际上并不是简单的运维能力问题，而是一个企业管理的问题。当技术手段还不够完备的情况下，发现故障，分析问题，故障修复如果无法形成一个自动化的闭环，那么隐患排除必然是存在一定成本的。Oracle的自治数据库就是想从根本上解决这个问题，让风险发现预警与修复形成一个闭环，从而大大降低企业运维数据库的成本。

其实企业中已经建立了不少风险修复机制，比如空间容量扩容，数据归档等。只不过数据库运维风险不止于此，对于一些发生概率更小，修复成本更大的风险就没有建立类似的机制了。一个企业不可能雇佣专家天天帮着分享风险，处置高风险隐患，因此防患于未然也只能口头上说说了。凭着自己的日常运维人员，很多风险连发现都做不到，谈什么防患呢？

实际上技术手段的不足限制了风险防范的真正落地，而AI技术的发展可能会让风险防范形成真正的闭环，我想在未来数年间，这方面的技术落地将会变得越来越普及，成本也会越来越低。

数据库大数据表空间

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

数据库运维中，防患于未然为什么叫好不叫座

评论