在ORACLE 12C RAC中使用in memory特性请注意parallel_degree_policy和parallel_force_local参数
这是一篇典型的故障排查文章。作者在对Oracle 12C RAC的In-Memory特性进行测试时，遇到了一个棘手的问题：在清空缓冲区缓存后，测试总是意外触发大量并行操作，导致结果不准确。 经过与Oracle官方协作排查，最终定位到问题的根源在于两个关键参数的默认设置不匹配In-Memory的最佳实践。具体来说，参数`parallel_degree_policy`被设为了`AUTO`，而`parallel_force_local`则是默认的`false`。在RAC环境下，这种组合会导致并行执行计划不符合预期。 文章通过具体的SQL操作和执行计划对比，清晰地展示了问题表现：从执行计划中可以看到“automatic DOP: Computed Degree of Parallelism is 2”的提示，并且明确标注了“parallel scans affinitized for inmemory”，这证实了In-Memory特性已被触发。解决方法就是根据RAC环境的需要，正确调整这两个参数的值。 对于计划在RAC集群中使用In-Memory功能的DBA来说，这篇文章提供了一个非常实用的避坑指南。它提醒我们，在启用强大的新特性时，往往需要仔细检查并调整相关的并行处理参数，才能确保其发挥出应有的性能优势。
持续可用与CAP理论 – 一个系统开发者的观点
这篇从金融数据库的视角出发，探讨了如何在实际工程中打破CAP理论的悲观论断，实现“持续可用”。作者首先明确了金融级数据库的两大支柱：强一致性（保证ACID）和高可用性（秒级故障恢复）。针对CAP理论中一致性与可用性的矛盾，文章指出CAP中的A（任何节点都须响应）与工程实践中的高可用（HA）存在差异——通过快速剔除故障节点、依赖多数派存活继续服务，系统仍能满足业务需求。 文章对比了两种实现路径：传统的共享存储方案虽成熟但成本高且无法跨机房；而基于Paxos的分布式方案则通过强同步与多数派选举，能在容忍单IDC故障的同时保持强一致与高性能。作者结合实践经验指出，若架构设计得当（如OceanBase的实现），强同步带来的额外延时可控制在同城0.5ms左右，吞吐量影响低于10%。 文章最终结论是：在同城环境下，采用Paxos协议的系统能够做到持续可用；而在异地场景，由于网络延迟，仍需根据业务需求在一致性与可用性之间做出权衡。
Hermes：来自腾讯的实时检索分析平台
这篇讲的是腾讯数据平台部推出的实时检索分析平台Hermes。它瞄准的是一个非常具体的痛点：当数据量达到千亿级别、维度上万时，如何还能做到秒级响应的多维交互式分析。 Hermes为营销分析、系统运维监控、长期趋势分析以及探索性分析等场景提供了一套完整方案。它的核心思路在于，针对海量数据重新设计了存储和计算引擎。例如，通过嵌套列存储、位图计算、前缀压缩等技术，有效规避了传统数据库和早期搜索引擎在超大规模索引下内存消耗大、扩容困难、恢复慢的问题。文章特别将Hermes与Solr、ElasticSearch做了定位对比：后者更擅长小规模数据的全文检索，而Hermes则为亿级到万亿级的数据仓库提供索引支持与即席分析能力，旨在成为数据仓库的高效分析层。 本质上，Hermes是在大数据领域，为“即查即所见”的敏捷分析体验提供的一个经过生产验证的基础设施选型参考。
如何统计Redis中各种数据的大小
这篇讲的是 Redis 内存占用分析的一个轻量级自定义方案。作者从一个常见的痛点出发：Redis 内存变大后，不像 MySQL 能轻易定位到具体是哪些“大表”，很难快速找出到底是哪些键占用了主要空间。 现有的分析工具如 redis-rdb-tools 可能无法满足所有定制化需求。为此，作者展示了如何仅用 SCAN 和 DEBUG 这类 Redis 原生命令，编写一个简短的脚本，就能实现按自定义模式统计键大小的功能。其核心思路是通过 SCAN 遍历所有键，利用 DEBUG OBJECT 获取每个键的序列化长度，再按照预定义的正则表达式模式进行分类和累加。这种方法非常灵活，你可以轻松定义比如“用户Session”、“缓存数据”等业务维度来查看各类数据的内存占比。 文章也补充了两个实用要点：一是可以通过 MONITOR 命令配合分析，来初步总结出可能的键命名模式；二是需要明白 DEBUG 返回的序列化长度（serializedlength）会比实际内存占用小，但作为相对大小的参考指标依然有效。
kvproxy配置文件之集群设置
这篇讲的是kvproxy配置文件中集群设置的具体方法和注意事项。作者开篇就点明了kvproxy集群分为三种：默认集群、读集群和备份集群，后两者都是可选的，各自承担读写分离与数据同步的职责。 文章重点解析了几个核心配置要点：集群名可自定义，但同一集群内的数字id必须唯一，它作为实例标识在更换节点时能确保数据路由的一致性；权重数值并非百分比，而是代表实例在一致性哈希环中的虚拟节点数，数值越大承载的数据通常越多。 为了让概念更具体，作者提供了一个memcached集群配置实例。其中清晰展示了如何通过设置`hosts`、`hosts_backup`和`hosts_read`来分别指定默认、备份和读集群，并详细列出了每个集群成员的IP、端口、ID和权重。通过这个配置，读请求会由`read`集群处理，所有写操作则会同步到`slave`备份集群，从而实现了基本的读写分离和数据备份。整个讲解从概念到实践，条理清晰。
kvproxy的数据主从复制简介
这篇讲的是如何为Memcached缺少的数据主从同步能力打上补丁。 作者从Memcached用户在多集群部署时面临的数据一致性痛点出发，介绍了kvproxy提供的一个核心功能：通过主从复制实现集群间的数据同步。文章没有停留在概念层面，而是直接拆解了典型场景，比如应对单点故障做热备份，以及跨机房部署时减少网络延迟。 核心方案是让kvproxy代理层支持同步与异步两种复制策略。同步复制保证强一致但增加延迟，异步复制响应快但数据有滞后。文章很细致地指出了如何通过配置文件设置主从集群、指定复制策略前缀，比如让以“+”开头的Key强制走同步通道。 这相当于在缓存层引入了一个可控的数据同步管道，对于既想用Memcached高性能、又需要一定可靠性的团队，提供了一个具体的参考实现路径。
理想数据库客户端的准则
这篇讲的是，一位开发者从实际项目（Gittask）中遇到的数据库客户端“抽象漏洞”出发，思考了理想的数据库客户端应具备哪些特质。 作者认为，当前客户端普遍存在不足，理想的客户端应遵循三大准则：首先是“无损序列化与反序列化”，客户端应负责保持数据结构的完整性，确保存取的类型完全一致，避免开发者陷入繁琐的类型转换。其次是支持“混合持久化”，客户端应能统一接入不同后端数据库，让开发者可以为不同任务选择最合适的数据库。最后是实现“跨数据库的原子事务”，当操作涉及多个数据库时，客户端应保证操作的原子性，任何环节失败都能整体回滚，避免数据处于不一致状态。 文章还进一步探讨了，这种客户端应将复杂数据库操作抽象为 get、put、del 等基础操作，同时允许扩展调用特定数据库的独特功能。作者借此批判了ORM是抽象漏洞的观点，并提倡用独立的数据校验库配合此类客户端来构建模型。 这套准则指向一个更强大、更通用的数据库交互层，旨在减轻开发者心智负担，让多数据库架构的开发与维护变得更可靠、更简洁。
给你的rman备份集加上密码锁
备份是数据保护的最后一道防线，但如果备份集本身没有防护，泄露的风险同样存在。这篇文章从这个角度出发，讲解了如何为Oracle RMAN备份集加上密码锁，实现加密存储。 作者从数据安全的现实威胁切入，指出RMAN备份集若被窃取，其数据风险等同于生产库被入侵。解决方案是利用RMAN在10.2及以上企业版中提供的`set encryption`命令，在备份过程中直接设置加密密码。文章详细演示了从配置加密算法（支持AES128/AES256等）到执行加密备份的完整步骤，并特别提醒：加密仅对`backupset`有效，`copy`方式不支持；若需备份到带库，则必须使用Oracle Secure Backup。 最具说服力的部分是实操验证。作者创建了测试表空间和数据，进行了加密备份，随后模拟数据文件丢失并尝试恢复。结果显示，在不知道密码的情况下恢复会报错；即使设置错误密码也无法成功。只有使用正确的密码才能顺利完成恢复，这直观地证明了加密机制的有效性。 整篇文章实操性强，不仅提供了命令行的具体操作，更通过正反验证让读者清晰看到加密带来的保护效果，对于关注数据库备份安全性的DBA来说，是一个直接可落地的加固方案。
Redis编程小技巧拾遗
这篇讲的是作者在阅读Redis源码时，特意“拾遗”的几个精妙的C语言编程技巧。作者从Redis简洁的1.0版本入手，并未重复大众熟知的源码剖析，而是聚焦于那些能让代码更健壮、更高效的小细节。 最典型的是“空数组”技巧：在`sdshdr`和`zskiplistNode`结构体的末尾定义一个空数组成员（如`char buf[]`和`level[]`）。这允许在动态内存分配时，根据实际需要的数据长度（如字符串长度、跳表层数）一次性申请合适大小的内存，实现了结构体内可变长数据的紧凑存储。 另一个常见但重要的技巧是使用 `do { } while(0)` 来包裹宏定义中的多条语句。这不仅能确保宏在if等控制流中像单条语句一样安全执行，文章还展示了将其用于简化流程控制的用法，使代码逻辑更清晰。 此外，文章还介绍了Redis中定制化的断言宏`redisAssert`和分级日志系统`redisLog`，前者在条件失败时能输出详尽的上下文信息，后者则允许根据日志级别进行过滤。这些实现虽小，却体现了生产级项目对可调试性和可观测性的重视。 这些从顶级项目中提炼出的技巧，对任何C/C++开发者都有直接的借鉴意义。
关于oracle ebs系统apps的一些故事
这篇讲的是Oracle E-Business Suite（通常叫Oracle ERP）为何被业内亲切地称为“Apps”的技术源流。作者从这个有趣的命名问题出发，回顾了APPS schema的进化史，解答了一个许多开发者都好奇的细节。 文章指出，在早期版本（如EBS 10.6）中，系统每个功能模块（采购PO、应收AR等）都有独立的数据库schema。这导致了一个历史遗留的“小麻烦”：跨模块访问数据时，SQL语句里总得带上冗长的Schema前缀，比如`po.po_headers_all`，写起来颇为繁琐。 为了解决这个问题，Oracle引入了统一的APPS schema。它的设计非常巧妙：APPS schema本身不直接存储表，而是通过为其他所有模块的表创建“同义词”，从而让开发者只需连接到APPS，就能像访问本地表一样，简洁地查询全系统所有模块的数据，无需再写任何前缀。 文章最后总结了几条关键的开发实践原则，比如PL/SQL包和视图都应在APPS下创建，而客户化表则建议放在独立的schema中。这个故事不仅解释了一个称呼的由来，更清晰地展示了Oracle EBS在架构上为简化开发所做的一次重要演进。
怎么查看oracle ebs的系统版本号以及各模块的版本号
这篇讲的是如何快速定位Oracle EBS的版本信息，这是系统管理和升级时的一个基础但关键的步骤。作者没有绕弯子，直接切入核心需求：如何查看系统整体版本号，以及如何深入查看每个应用模块的具体版本、安装状态和补丁级别。 文章提供了两个现成的SQL查询，分别用于获取系统级版本（从`fnd_product_groups`表）和模块级详情（关联`fnd_product_installations`与`fnd_application`表）。作者特意点明，这类信息查询的关键线索通常在于以`fnd_`为前缀的系统表。对于需要进行版本核对、补丁安装前检查或环境排查的EBS顾问与DBA来说，这几行查询能直接给出准确答案，避免了在界面上层层点击的繁琐。
SSDB 源码分析 – 网络框架概述
这篇从SSDB重构后的模块化代码出发，聚焦其高度可复用的网络框架。作者首先指出SSDB网络协议虽简单且业务无关，能广泛应用于各类应用，但许多实现代码在解析报文时不够严谨，常误用`fgets()`等行级IO函数。随后，文章剖析了其多线程服务器框架的核心：通过`serve()`函数作为IO主线程管理连接与IO操作，并用`proc()`函数根据命令属性分发任务——或在主线程处理，或投入线程池。框架的巧妙之处在于，利用IO多路复用作为主循环，并通过名为`SelectableQueue`的结构，将线程间通信抽象为类似网络IO的逻辑，从而清晰高效地处理了主线程与工作者线程间的请求与响应传递。整个框架封装完善，几行代码即可构建并运行一个服务器。
复杂关联SQL的优化
这篇讲的是如何将一个耗时 750ms 的复杂关联 SQL 优化到毫秒级的过程。作者从一个真实案例出发，通过分析执行计划，精准定位了性能瓶颈：一条只返回一行数据的查询，却因为驱动表选择不当和索引缺失，导致在两张表上发生了全表扫描。 优化过程分为两步走。首先，针对 `left join` 的 d 表添加了缺失的 `yh_id` 索引，使其扫描行数从 5 万多行骤降至 272 行。但整体耗时并未改善，因为优化器仍坚持选择 a 表作为驱动表。作者进一步深入分析，发现根本原因在于关联字段 `yh_id` 在 b 表上没有索引，导致优化器认为以 a 表驱动的代价更低。于是，第二步是为 b 表和过滤性极强的 c 表分别添加了 `yh_id` 和 `yh_dm` 索引。 索引齐全后，优化器终于“回心转意”，转而选择数据量更小、过滤条件更强的 c 表作为驱动表，执行计划彻底改变，查询时间从 0.75 秒直接降为 0.00 秒。这个案例清晰地展示了，优化复杂 SQL 不能只看单表索引，更要理清表间关联逻辑与数据分布，通过分析执行计划来引导优化器做出正确选择。
NUMERIC和DECIMAL的区别是什么？
这篇讲的是SQL Server中两个容易混淆的精确数值类型：NUMERIC和DECIMAL。文章开篇就点明，在功能上它们是完全同义的，都用于精确存储数值，最大精度都是38位，主要区别体现在类型定义的细微处。 核心差异在于精度（p）和小数位数（s）的约束关系：对于decimal(5,2)这样的定义，p=5代表总位数（小数点左右数字之和），s=2指定小数位数。文章特别强调，p和s必须满足 0 ≤ s ≤ p ≤ 38。另一个关键点是，在Transact-SQL看来，decimal(5,5)和decimal(5,0)会被视为不同的数据类型，这种对精度组合的严格区分影响着存储和计算。 在数据转换方面，文章给出了明确的警示：从decimal/numeric转换到float/real会导致精度损失，而从整数或货币类型转换过来则可能引发溢出。这些细节对于设计需要严格数值一致性的金融或科学计算系统尤为重要。 总的来说，这篇文章厘清了这两个类型的表面相似与本质联系，适合所有需要处理精确数值的数据库开发者，帮助他们在定义表结构时做出更清晰、无歧义的选择。
修改oracle当前会话的语言环境，解决oracle显示中文乱码的问题
这篇讲的是如何快速解决Oracle数据库在操作时出现中文提示显示为一串问号的常见问题。 作者从实际操作中的困扰出发，明确指出这种乱码的根源在于当前会话的语言环境设置不匹配。文章提供了具体、可操作的解决方案：首先通过 `SELECT userenv('language') FROM dual;` 命令来查看当前的语言环境配置，确认问题。接着，给出了两种修改方法：一是通过 `ALTER SESSION SET NLS_LANGUAGE='SIMPLIFIED CHINESE';` 命令临时修改当前会话，使其立即生效；二是通过修改环境变量等方式进行永久性设置，从根源上避免问题再次出现。 整个排查思路清晰，步骤直接，对于遇到类似字符集显示问题的数据库管理员或开发人员来说，是一份实用且能快速解决问题的参考。简单几条命令就能让提示信息恢复可读性，提升了工作效率。
oracle跟踪事件（dump）总结
这篇讲的是Oracle数据库中用于故障诊断的跟踪事件（dump）机制。文章系统梳理了跟踪文件的三种类型——后台报警日志、后台进程跟踪文件和用户跟踪文件，并详细说明了如何通过初始化参数或会话命令来触发dump操作。 核心内容聚焦于各种跟踪事件的具体用法。例如，通过`buffers`事件可导出SGA缓冲区信息，`blockdump`事件能定位特定数据块，`errorstack`事件则用于捕获难以获取的错误栈。文章还列举了诸如`10046`（SQL语句跟踪）、`10231`（全表扫描时跳过损坏块）等实用的内部事件号，并解释了其参数级别含义。 最后，文章提供了查看当前跟踪文件的简单示例。整体上，它像一份面向DBA和开发者的速查手册，将分散的Oracle诊断工具整理成可操作的条目，便于在性能调优或故障排查时快速定位并转储关键内存结构或日志信息。
如何查找消耗资源较大的SQL
这篇讲的是数据库性能优化中一个非常基础但关键的问题：如何找出那些最“吃”资源的SQL语句。作者没有从理论入手，而是直接从Oracle的V$SQLAREA视图出发，给出了一个可直接使用的查询语句。 这条SQL的设计很务实，它不仅找出了总磁盘读取（disk_reads）最多的查询，还计算了每次执行的平均磁盘读取次数（rds_exec_ratio）。通过这个比率，你能快速识别出是那些执行频繁但效率低的语句，还是那些单次执行就消耗巨大的语句。同时，语句关联了执行用户（username）和具体的SQL文本（Statement），让定位和后续优化有了明确目标。 对于需要快速诊断数据库性能问题的DBA或开发人员来说，掌握这几个从V$SQLAREA中提取关键信息的查询，就相当于有了一个高效的“探照灯”，能立刻照出系统中最耗资源的瓶颈所在，让优化工作不再是大海捞针。
SSDB源码分析 – 主从和多主同步原理解析
作者深入SSDB的内核，解析其主从与多主同步的设计哲学。核心思路是将主节点的所有写操作（Binlogs）在从节点重放，这与MySQL类似，但SSDB通过自动化解决了基础数据拷贝的痛点。 整个同步流程分为两个核心阶段：首先是**COPY状态**，此时从节点会像遍历链表一样自动复制主节点的全量数据。在此期间产生的新写入，会根据其在数据链表中的位置决定是立即同步还是留待后续处理。当游标移动到末尾，流程无缝进入**SYNC状态**，实现毫秒级的实时增量同步。 文章巧妙之处在于对细节的剖析：例如，通过为Binlog编号实现断点续传，并解释了`slaveof.type`配置为`mirror`是防止多主死循环的关键。它还澄清了一个常见误解——`slaveof.id`标识的是目标数据库而非物理机器，这使得数据迁移后同步关系能自动保持。 对于理解分布式存储的同步机制，或是面临具体配置问题的开发者来说，这篇从实现细节出发的分析提供了清晰的路线图。
B-树
这篇讲的是经典数据结构B-树的核心设计与操作逻辑。文章开篇就点明了B-树与平衡二叉树的关键差异：通过允许节点容纳更多元素（几十到几百个）来大幅降低树的高度，从而在数据无法全部载入内存时，显著减少访问磁盘的次数，提升效率。 作者详细拆解了B-树的严格定义，特别是倾向于使用奇数阶（如2n+1）的统一性，以避免处理偶数阶时可能出现的不平衡情况。随后，文章通过具体的查找和插入示例，生动展示了B-树的工作原理。查找过程强调了其多路搜索的特性，而插入部分的剖析尤为细致，清晰地说明了节点未满、分裂以及元素移动（如将中间元素上提至父节点）等不同情况下的处理逻辑，解释了如何通过分裂和平衡操作来维持所有叶子节点处于同一层的核心性质。 整个讲解围绕着B-树如何保持平衡与高效展开，为其在数据库索引和文件系统等场景中作为底层核心数据结构的重要性，提供了坚实的技术基础。
为什么长尾数据的翻页技术实现复杂
这篇讲的是长尾数据翻页的技术复杂性。作者从Key-list类型数据（如好友列表、评论ID列表）的翻页需求出发，指出大部分数据长度较短时，简单的LIMIT offset方案尚可应对，但当数据量达到百万级且访问深页码时，该方案性能会急剧下降。 文章核心对比了两种翻页实现：“扶梯方式”（只提供上一页/下一页）与“电梯方式”（支持精确跳转至任意页）。作者解释，扶梯方式通过记录最后一条ID实现O(log n)复杂度的高效查询；而电梯方式因依赖LIMIT offset，在MySQL中需扫描前所有行导致O(n)的复杂度，且难以缓存。 面对更大数据规模，文章进一步讨论了分布式数据分片策略。按用户uid分片可高效读取，但数据冷热不均导致存储成本高昂；引入时间维度分片虽缓解存储压力，却带来了数据滚动自动化难、需额外二级索引等新问题。作者最后指出，现有方案均非理想，为后续探讨更优的长尾翻页设计埋下了伏笔。
