Oracle11g Direct NFS 测试
这篇讲的是作者对Oracle 11g Direct NFS功能的一次实测。他发现，传统NFS客户端与服务器之间通常只建立一个TCP连接，所有请求都是串行处理的，必须等前一个完成，后一个才能开始，这使得随机读写IO性能很难提升。 而Oracle Direct NFS的关键优化，就在于它会与NFS服务器建立多个TCP连接。这样，IO请求就可以被分发到这些连接上并发处理，从架构上突破了传统串行模式的瓶颈。作者通过测试确认了这一机制，指出其理论上能够显著提升NFS存储的IO性能。 这个发现对于使用NFS作为数据库存储的环境尤其有价值，它点明了通过改变连接模型来优化性能的一个可行方向。
11G real time query
这篇讲的是如何利用 Oracle 11G 的 Real Time Query 功能，实现备用数据库的实时查询，为读写分离架构提供新思路。 文章从传统 Data Guard 备库查询存在延迟的痛点出发，指出 11G 版本引入的这个特性，允许在备库以实时方式查询主库的数据变更。作者团队并没有停留在理论层面，而是结合 `lgwr+async` 的具体配置，实际搭建并测试了该功能。他们重点验证了从主库事务提交到备库可见这个链路的实时性究竟如何，通过测试数据直观地展示了延迟水平。 对于考虑读写分离但又对数据延迟敏感的系统来说，这个功能提供了一个无需复杂中间件的原生解决方案。文章最终的测试结论，也为评估该方案在具体业务场景中的适用性提供了直接的参考依据。
整型（int）数字溢出在程序和数据库设计中的考虑
这篇讲的是在数据库和程序设计中，一个容易被忽视却可能随业务增长而爆发的隐患——整型（int）数字溢出。 作者从实际的业务场景出发，指出数据库中的某个整型字段，其数据可能随着业务规模扩大而持续增长。如果当初设计时选择的类型范围不足，这个数字终有一天会“撑破”字段定义的容器，导致溢出错误。更麻烦的是，在应用程序代码里，如果涉及到对这个数字的运算或比较，同样可能因为超出该语言数据类型的处理极限而引发异常。这类问题往往在开发或测试阶段难以发现，因为初期数据量很小，直到生产环境数据积累到一定程度才会突然爆发。 文章的核心观点是，这种“温水煮青蛙”式的问题需要开发者具备前瞻性的设计思维。它提醒我们，在项目初期就应当评估数据的未来增长空间，并据此选择足够大的数据类型，或者在关键业务逻辑中设计好边界检查与处理机制，避免某个看似普通的字段成为系统未来的定时炸弹。