曾经有个晚上，生产库的alert日志刷了整整一页ORA-01555，我整个后背都在冒冷汗。那是一个跑了五年的Oracle 11g，归档模式，undo表空间设得刚好够用。出问题的是一条夜维SQL，跑了四十分钟，undo_retention设的是900秒，结果这条SQL的查询一致性读需要更老的前镜像——报错的时候，数据块版本已经被后来的事务覆盖了。那晚我们加了40G的undo，但问题根本不是空间不足，而是设计上对长查询的预估不足。
说实话，Oracle这套东西，你越用越觉得它“反人性”。它有很多规则，很多参数，很多隐藏的坑。比如行级锁，它真的实现了低开销的锁行，靠的是数据块头的ITL（Interested Transaction List）来记录事务信息，再配合回滚段去构建一致性读。这种设计很优雅，但如果你不懂它，出了问题你连方向都找不到。反观MySQL，它的MVCC机制更直观，但它的间隙锁（gap lock）会带来更多奇怪的死锁场景。你问我会选哪个？如果系统是银行的核心账务，我还是会选Oracle，因为它的锁等待队列更可控，而且你可以在RAC上做更多隔离。
很多人说ASM过时了，应该用云上的存储。我倒是觉得ASM是Oracle的一大智慧。它把裸设备、文件系统、卷管理全包了，还提供了条带化和镜像能力。你用云盘，确实简单，但你想过没有，云盘的底层是分布式存储，网络延迟和带宽波动是你控制不了的。ASM直接和数据库的连接池通信，在OLTP场景下，它的IO路径更短。当然，ASM的维护难度也不低，特别是遇到磁盘组平衡（rebalance）的时候，整个集群的IO都可能被拖垮。我记得有一次加了块新盘，自动rebalance了整整一个下午，业务方的电话都快打爆了。
但不得不承认，Oracle最大的护城河不是技术，而是许可证和商业流程。金融监管要求审计日志保留，Oracle的Audit Vault和Database Vault提供了成熟的安全模型，开源数据库要自己拼。还有备份恢复，RMAN的恢复机制，到现在都没有开源产品能完全对标。你说这些不值钱吗？在金融行业，稳定和合规比性能更重要。Oracle一个核心系统可以几年不重启，但换了PostgreSQL你可能要操心VACUUM的问题。所以说，选Oracle不是因为它多先进，而是因为它让你半夜不用接电话。
