数据库国产化替代在顺利推进中，一个又一个客户把自己的系统从Oracle迁移到国产数据库，并开始进入稳定运行期。这是一个十分好的开端，不过这个好的开端的背后并不说明国产数据库已经能够完全替代Oracle，而只能说是很多行业的核心业务系统成功地完成了数据库国产化替代。

　　核心业务系统成功地完成了国产数据库替代和国产数据库成功地替代了Oracle是两句话看似相似，实际上是有着完全不同的内涵的。核心业务系统经过应用改造或者系统升级，将数据库替换为国产数据库，是几乎所有核心系统替代的唯一方案。很多新系统上线之后甚至性能远超老系统，这些都是事实，不过其背后的逻辑还是“应用系统升级改造”，数据库国产化替代，倒逼了关键行业的应用系统升级改造，这笔账算下来也不见得很亏，因为升级改造是早晚要做的事情，只不过可能提前了几年。

　　也是依靠应用改造的力度很大，系统上线之后大多数还算平稳，不过保障系统稳定运行的逻辑发生了变化。前几天和一个运维某核心系统的DBA聊天，他说目前他们在运维的时候主要是关注数据库的日志中是否有严重报错，因为数据库的指标反映不出太多的系统问题，日志监控是重中之重。另外一个需要关注的是服务器的CPU，如果服务器CPU的load超过核数2倍，并持续1分钟以上，那么就是一个重大的安全事件，必须分析清楚是什么原因，否则可能系统会有高风险。

　　load超过CPU核数的两倍确实是一种CPU负载过高的现象，以前我们监控Oracle数据库服务器的时候，也会使用这种规则。只不过，当Oracle数据库服务的Load持续十分钟甚至一两个小时处于这种状态的时候，才是需要去关注的。很多Oracle数据库系统只要一到上班高峰就处于这样的高负载下，跑上一天，也不见得会出问题。

　　而国产数据库相对还比较脆弱，因此必须把监控粒度缩小到1分钟范围，才能更有效地发现问题，规避风险，甚至有些国产数据库系统除了提出了超高的硬件配置之外，还对CPU负载监控提出的建议是使用率不超过30%。这也说明目前的国产数据库虽然已经成功完成了不少核心系统的替代，但是在保障长期稳定运行上，还存在很多不足，还需要不断在这些关键业务系统中磨练成长。只有当承载关键业务系统的国产数据库能够在高负载下长时间持续稳定运行，才能说明国产数据库真的成功了。