共 3 篇相关文章
这篇讲的是Oracle数据库补丁体系中那些容易混淆的概念。文章清晰地梳理了从标准版本Release，到累积型的Patch Set (PSR)、季度发布的Patch Set Update (PSU) 和 Critical Patch Update (CPU) 等各类补丁的定义与区别。 特别实用的部分在于，它点明了不同补丁的发布逻辑和应用场景：例如，PSU和PSR虽是累积型，但PSU不改变主版本号；在Windows平台上则使用Bundle Patch (BP) 作为替代。文章还澄清了小补丁 (One-Off Patch)、合并补丁 (Merged Patch) 以及诊断补丁 (Diagnostic Patch) 的具体用途和注意事项。 对于希望理解补丁策略的DBA来说，文中的安装建议很有价值，比如推荐安装最新的PSR，以及在应用小补丁前务必进行测试。文章最后引入了Composite Patch的概念，解释了这种新格式如何通过增量安装减少时间开销，并与之前的PSU版本构成了清晰的包含关系，为管理补丁提供了新的视角。
这篇文章从一个常见的使用痛点出发：TokyoTyrant虽然高性能，但原生不支持列出所有Key，这在数据排查和迁移时很不方便。作者通过一个简洁的源码patch，为TokyoTyrant添加了这一功能。 核心的实现思路非常巧妙。作者并非去修改TokyoTyrant复杂的内部存储逻辑，而是选择扩展其命令行接口（ttserver），通过一个额外的命令来遍历数据库。他利用了TokyoTyrant已有的迭代器接口，编写了一个专门的函数来遍历并打印所有键名。这个方案避免了侵入数据库核心，实现起来干净利落。 这篇分享的价值在于它展示了如何用最小的改动解决一个具体问题。对于正在使用TokyoTyrant并受此困扰的开发者，这个patch提供了一个直接可用的思路；即使对于其他数据库使用者，这种“扩展而非侵入”的修改策略也值得借鉴。
这篇文章讲的是，作者发现TokyoTyrant（一个基于Tokyo Cabinet的K-V数据库）默认不支持像Redis那样列出所有的Key，这在某些运维或调试场景下不太方便。于是，作者直接从源码入手，动手写了一个简单的补丁来解决这个问题。 核心思路是利用TokyoCabinet已有的遍历游标功能。作者在TokyoTyrant的服务端，新增了一个特定的命令来触发这个操作：当收到该命令时，服务端会创建一个数据库游标，从头到尾遍历所有记录，并将遍历到的Key逐一返回给客户端。实现上虽然直接，但作者也指出了关键点：对于数据量巨大的数据库，这种全量遍历会带来显著的性能开销，因此更适合作为管理工具在非高峰时段使用。 这个案例很实际，它展示了如何通过对开源工具的轻量级定制来弥补功能短板，满足特定需求。虽然补丁简单，但思路清晰，对于想自己动手修改数据库源码的开发者来说，是个不错的入门参考。
