oGRAC 整体代码架构梳理 1. 先建立一张心智地图 oGRAC 是一个采用共享存储架构的多主关系型数据库。每个计算节点都运行完整的数据库实例，节点之间通过全局缓存、分布式锁、分布式事务可见性和集群重构机制，共同访问同一份持久化数据。从代码角度看，最重要的判断是： 1.ograc 不是只包含一个“server 模块”，而是把 Server Runtime、SQL 引擎、Kernel、DTC、MES、RC、CMS 客户端等核心组件链接进同一个数据库进程。 2.独立的 cms 进程负责成员、资源、投票、故障检测和 I/O fencing；它不参与每次 SQL 的页面访问热路径。 3.DSS、DBStor 和普通文件系统位于统一设备抽象 cm_device 之下。共享存储解决“共同访问持久数据”，缓存一致性仍由 DRC/DCS/DLS 等数据库内组件保证。 4.这是一个“概念上分层、实现上强耦合”的大型 C 数据库内核。阅读代码时，按启动链和请求链查看，比按目录从头到尾阅读更有效。一句话概括运行主链：客户端 → 协议与连接 → Server 的 session / reactor / agent → SQL 解析、校验、改写、优化、执行 → Kernel cursor 与表/索引访问器 → Buffer / Undo / Redo / Transaction → 集群模式下 DRC / DCS / DLS → cm_device → FILE / DSS / DBStor 2. 总体组件关系可以把系统分成三条相互交叉的主线：主线核心组件解决的问题 SQL 请求数据面 Protocol → Server → SQL → Kernel 一条 SQL 怎样进入、编译、执行并访问数据 RAC 协同数据面 DTC → DRC/DCS/DLS → MES 多个计算节点怎样协调页面、锁、事务和 SCN 集群控制面 CMS → RC/Reform → DTC Recovery 节点加入、退出、故障时怎样恢复并形成新稳定视图 3. 仓库顶层结构路径主要职责 CMakeLists.txt 全局构建选项、平台判断、依赖路径、输出目录；当前最权威的构建描述 build/ 第三方依赖准备、CMake/Make 编译、增量编译、打包、RPM、符号分离 CI/ 被外部 CI/Jenkins 类流水线调用的 Shell 脚本；仓库内没有独立 Jenkinsfile pkg/ 数据库源码、配置、安装、部署、管理脚本和测试 pkg/src/ C/C++ 核心源码 pkg/admin/ 建库和系统对象 SQL；含不同兼容模式脚本 pkg/cfg/ ogracd.ini、cms.ini、cluster.ini、HBA、MES 节点配置等模板 pkg/deploy/ 新部署框架，主要是 Shell 薄入口加 Python 组件编排 pkg/install/ 较旧的独立安装、启停和建库流程 pkg/test/ SQL 回归、GoogleTest 单元测试、OM 测试 og_om/ 运维管理：ogcli、ogmgr、exporter、巡检和日志采集 docker/ 开发和 CI 容器构建、启动脚本 DSS/ 当前 checkout 中是空 gitlink，不能据此分析 DSS 服务端实现 open_source/ 当前 checkout 中是空 gitlink，用于外部开源依赖 library/ 构建期第三方头文件/库位置；当前内容不完整 common/ 仓库级辅助脚本，与 pkg/src/common 不是同一层概念 3.1 pkg/src 核心模块模块 CMake 目标或产物职责 common ogcommon 基础类型、内存、容器、日志、加密、线程、网络辅助、设备抽象、DBStor 适配等 driver/ogconn ogclient 原生 C 客户端驱动 driver/ogodbc ogodbc ODBC 驱动 protocol ogprotocol packet、pipe、TCP、SSL、UDS、listener、协议读写 server ogserver、ogracd、libograc.so 数据库进程、实例、参数、listener、session、reactor、agent、SGA、审计、资源管理 ogsql ogracsql SQL/PL 编译执行体系 kernel ogkernel 数据字典、表、索引、事务、buffer、redo、恢复、备份、复制等 cluster ogcluster DTC、DRC、DCS、DLS、DMon、集群恢复和 reform 执行动作 mec ogmes 节点间消息通信、通道、队列、工作线程和 waiting room；目录叫 MEC，接口和目标大量使用 MES 命名 rc ogrc 从 CMS 成员视图触发并编排一轮 reform cms cms、ogcms、libdsslock.so 独立集群管理服务及数据库侧 CMS 客户端接口 tms ogtms 线程监测 fdsa ogfdsa 长耗时 I/O 检测、自愈相关适配，可动态配合 libfdsa.so rbp rbps 独立页缓存/读写/检查点网络服务及其管理脚本 utils/ogsql ogsql SQL 命令行客户端 utils/ogbackup ogbackup 备份、prepare、归档和清理工具 utils/gspe ogencrypt 密码、密钥、证书相关工具 dbstool dbstor DBStor 管理工具 ogbox ogbox cminer、crepair、cfunc 等工具集合 ogrst ogrst 紧急修复工具 upgrade_check 链入相关工具/服务升级检查 version 版本对象统一版本源文件的一部分从代码规模看，主要复杂度集中在：1. pkg/src/ogsql 2. pkg/src/kernel 3. pkg/src/common 4. pkg/src/server 5. pkg/src/cluster 6. pkg/src/cms 因此，server + ogsql + kernel + cluster 是理解数据库运行机制的四个主战场。 4. 构建目标和真实依赖关系 4.1 核心目标关键证据： ●pkg/src/server/CMakeLists.txt 构建 ogserver、ogracd 和输出名为 ograc 的共享库。 ●ogracd 最终链接：ogserver ogracsql ogkernel ogmes ogprotocol ogcommon ogclient ogcluster ogcms ogrc m rt pthread dl z zstd lz4 ●链接时使用 --start-group/--end-group，说明核心静态库之间存在环状符号依赖，不能把 CMake 链接边机械理解为严格的单向架构边界。 ●ogracsql -> ogkernel ●ogkernel -> ogfdsa ●ogcluster -> ogrc + ogtms + ogfdsa ●ogmes -> ogrc + ogtms ●ogrc -> ogcms 正常构建中 ogserver 显式链接 ogcluster + ogcms；Fuzz 构建还额外显式链接 ogracsql + ogmes。无论如何，最终 ogracd 会把完整核心闭包一起链接。 4.2 主要交付产物产物用途 ogracd 数据库实例主进程 cms Cluster Manager Service rbps 独立页缓存服务 ogsql SQL 命令行客户端 ogbackup 备份工具 ogencrypt 加解密工具 dbstor DBStor 管理工具 ogbox 数据修复/分析工具集合，OSS 构建不生成 ogrst 紧急数据库修复工具 libograc.so 核心数据库服务共享库 libogclient.so 原生客户端库 libogodbc.so ODBC 驱动 libogprotocol.so 协议库 libogcommon.so 通用基础库 libdsslock.so CMS/DSS 锁适配库当前仓库中能确认的数据库驱动是 ogclient 和 ogodbc。构建脚本中的 JDBC、Go 相关变量不等于本 checkout 内存在相应驱动源码。 5. ogracd 进程内的核心运行对象 5.1 instance_t：进程级总上下文 pkg/src/server/srvinstance.h 中的 instancet 是 Server 层的总对象，全局入口是：instance_t *g_instance; 它直接持有：knl_instance_t kernel sql_instance_t sql sga_t sga session_pool_t session_pool reactor_pool_t reactor_pool 并行/应急 session pool SQL cursor pool 参数 config 资源管理器、作业管理器、审计/SSL/关闭状态等这意味着 Server、SQL、Kernel 并不是三个独立进程，也不是通过 RPC 连接的三个服务，而是同一进程内共享内存和对象的三个逻辑层。 5.2 session_t：贯穿 Server、SQL、Kernel 的请求上下文 pkg/src/server/srv_session.h：typedef struct st_session { knl_session_t knl_session; // need to be first! ... } session_t; knlsessiont 必须位于首字段，使同一块会话对象可以在 Server/SQL 和 Kernel 接口间转换与传递。它是理解跨层调用的关键：网络连接状态 + SQL statement/context + Kernel transaction/resource manager + wait/event/statistics + 当前兼容模式 5.3 knlcursort：SQL 与存储引擎的主要边界对象 SQL executor 调用 knlopencursor、knlfetch、knlinsert、knlupdate、knldelete 时，核心载体都是 knlcursort，定义在：pkg/src/kernel/include/dml_defs.h cursor 中保存扫描方式、索引范围、row buffer、update/insert 信息、分区位置、访问器函数等。SQL 层负责“要怎样执行”，Kernel cursor 负责“怎样访问表和索引”。 5.4 关键全局上下文全局对象位置/含义 g_instance Server、SQL、Kernel 总实例 g_dtc DTC集群实例上下文 grcctx RC/Reform上下文 g_mes 或 MES 全局上下文节点间消息系统 gknlcallback Kernel 回调 Server/SQL 的函数表 Kernel 并非完全独立于上层。srvsetkernelcallback() 会为 gknl_callback 注册大量回调，例如： ●分配/释放 kernel session ●解析和执行默认值、check 条件、函数索引 ●执行内部 SQL ●加载系统脚本 ●使 SQL cursor 失效 ●PL 对象处理和逻辑日志回放 ●获取 SQL 文本 ●kill session ●事务前置处理和资源统计所以真实依赖关系既有 SQL → Kernel 的直接调用，也有 Kernel → callback → SQL/Server 的反向调用。 6. 内存和线程模型 6.1 SGA ●pkg/src/server/srvsga.h 中的 sgat 主要包括： ●data buffer ●CR buffer ●log buffer ●temp buffer ●shared area ●DBWR/LGWR 相关 buffer ●transaction/index 相关内存 ●large pool ●PMA/VMA ●buddy pool SQL context、执行器、Kernel buffer、redo、临时对象和集群能力都依赖这套进程内共享内存。 6.2 前台请求线程模型listener accept 线程 → 创建/复用 session → session 注册到 reactor 的 epoll → reactor 发现 socket 可读 → 从 agent pool 绑定工作 agent → agent 处理一个或多个 session 的命令 → 满足可分离条件时，session 重新交给 reactor，agent 回池因此它不是简单的“一连接一永久线程”模型： ●session 表示逻辑连接和数据库上下文。 ●reactor 负责大量连接的 I/O 事件。 ●agent 是真正执行命令的工作线程，可被复用。 ●事务中、持有特定锁、私有保留连接或需要 dedicated agent 的场景，不会无条件在每条命令后分离；同一 session可能继续由当前 agent 处理。核心文件：pkg/src/server/srv_lsnr.c pkg/src/server/srv_session.c pkg/src/server/srv_reactor.c pkg/src/server/srv_agent.c pkg/src/protocol/cs_listener.c 6.3 后台线程 ●Kernel 启动后会创建或初始化多类后台任务，例如： ●log writer ●DB writer ●checkpoint ●SMON ●rollback/RMON ●statistics ●index recycle ●archive/recovery/replication 相关线程 ●MES 工作线程 ●DMon ●RC trigger/reform 执行线程 ●TMS 监测集群部署中还有独立 cms 进程自己的心跳、资源检测、投票、GCC、UDS、MES 等线程。 7. ogracd 启动链 7.1 进程入口入口文件：pkg/src/server/srv_main.c 主链：main → oGRACd_lib_main → srv_startup → srv_instance_startup → srv_instance_loop 关键位置：函数文件位置 main pkg/src/server/srv_main.c:318 oGRACdlibmain pkg/src/server/srv_main.c:255 srv_startup pkg/src/server/srv_main.c:212 srvinstancestartup pkg/src/server/srv_instance.c:1863 srvinstanceloop pkg/src/server/srv_instance.c:1432 启动参数支持 nomount、mount、open 和 -D 数据目录。 7.2 srvinstancestartup 的顺序1. timer、g_instance、locale、JSON、IP/密码安全上下文 2. 获取 HOME，加载 ogracd 参数、CPU/License 信息 3. 锁定数据库目录，防止同一实例重复启动 4. 加载自定义函数、HBA/PBL 5. 注册信号、Kernel callback、OS 信息、动态视图 6. 创建 SGA 7. sql_instance_startup，加载类型映射 8. 初始化 session pool 9. srv_kernel_startup → knl_init_attr → knl_startup 10. 初始化并行 session 和应急 session 11. 初始化 LOB locator 12. 创建 reactor pool 13. 启动 TCP/UDS listener 14. 初始化 SYSDBA privilege 和 SSL 15. 若启动模式是 MOUNT/OPEN，执行 srv_kernel_open 16. 初始化 signal/job manager 17. 进入 srv_instance_loop 一个容易忽略的顺序是：普通 listener 在 srvkernelopen() 之前启动。对应代码位置约为：srv_start_lsnr srv_instance.c:2027 srv_kernel_open srv_instance.c:2049 7.3 Kernel 启动srv_kernel_startup → knl_init_attr → knl_startup → db_load_lib → db_init → DBStor/集群设备初始化 → 数据库状态进入 NOMOUNT 7.4 MOUNT 和 OPEN MOUNT 主链：srv_kernel_open → knl_alter_database → db_mount → db_register_iof → db_mount_ctrl → 集群模式下 dtc_startup → partial-write 处理 → archive / logfile / DC preload → recovery context 初始化 dtc_startup() 的确定顺序：drc_init → dtc_register_proc → dtc_init_proc_sessions → dtc_set_mes_profile → tms_monitor_init → mes_startup → dmon_startup → record_io_stat_init → init_dtc_rc OPEN 主链可概括为：db_open → open precheck → db_mount_to_recovery → log_load → 等待相应 reform 恢复阶段；集群场景刷新控制信息并等待 reform → 加载 tablespace / system table → undo_init / lock_area_init / btree_area_init / lob_area_init → tx_area_init / ckpt_load / arch_start → db_recovery_to_initphase2 → redo recovery → 主库触发 full checkpoint → 保存 control 信息 → 按角色释放 transaction area → db_initphase2_to_open → 集群模式等待 REFORM_OPEN → dc_init → callback / switchover / cluster runtime analyzer 等初始化 → undo preload → DB_STATUS_OPEN 这说明集群启动不是“数据库先完全 OPEN，再启动 RAC”。在 MOUNT/OPEN 阶段，Kernel 生命周期和 DTC/Reform 生命周期已经交织。 8. 从客户端连接到 SQL 命令 8.1 建连和命令分派srv_start_lsnr → cs_start_tcp_lsnr → listener accept4 → srv_tcp_app_connect_action → IP 白名单检查 → srv_create_session → srv_attach_reactor → reactor_register_session socket 可读后：reactor epoll → srv_attach_agent → 通知已经运行的 agent 线程 → srv_try_process_multi_sessions → srv_process_single_session → srv_process_command → srv_process_command_core → g_server_cmd_hander[cmd] srvagententry 是 agent 线程创建时的一次性入口，不是 reactor 每次收到 socket 事件后同步调用的普通函数；agent 线程长期运行，在 srvtryprocessmultisessions() 一带等待事件并处理被绑定的 session。首包会由 srvdiagprototype 校验协议码、协商字节序、SSL 和连接能力。之后 srvprocesscommand 通过 csread 读取 packet 和 command。命令处理表在：pkg/src/server/srv_session.c:889 典型映射：协议命令处理函数 CSCMDPREPARE sqlprocessprepare CSCMDEXECUTE sqlprocessexecute CSCMDFETCH SQL fetch 处理 CSCMDQUERY sqlprocessquery CSCMDPREPANDEXEC sqlprocessprepandexec COMMIT/ROLLBACK 对应事务命令处理 8.2 一条 Query 的完整时序 9. SQL 引擎内部架构 9.1 目录分工目录/文件职责 ogsql_service.c 协议命令到 SQL statement 操作的服务入口 ogsql_stmt.c statement 生命周期、prepare、execute、fetch ogsql_context.c SQL context、共享 SQL 等 parser/ SQL 词法、语法和 DML/DCL 解析 parser_ddl/ DDL 解析 verifier/ 名称解析、类型和语义校验 optimizer/ 逻辑改写 plan/ 扫描、连接、聚合、排序等物理计划 executor/ SELECT/DML/DDL/DCL 执行器 function/、node/ 内置函数和表达式节点 pl/ 存储过程、函数、触发器等 PL 能力 catalog/、gdv/ SQL 层目录和动态视图相关能力 9.2 DML 编译主链以 CSCMDQUERY 的 DML 硬解析路径为例：sql_process_query → sql_prepare → sql_parse → sql_parse_core / sql_parse_by_lang_type → sql_parse_dml → sql_parse_dml_directly → sql_create_dml_currently → sql_create_dml → sql_create_dml_context → sql_verify → check_table_stats → ogsql_optimize_logically → sql_create_dml_plan → sql_execute sqlparsedml() 并不总是直接进入上述链路：它会在 direct/hard parse 与 ogfindthenparsedml() 的共享 SQL/软解析路径之间选择。因此，verify → optimize → plan 这组调用应理解为创建新 DML context 时的硬解析主链，而不是每次执行都会完整重复。最直接的代码证据位于：pkg/src/ogsql/parser/dml_parser.c:1123sql_create_dml_context(...) sql_verify(...) check_table_stats(...) ogsql_optimize_logically(...) sql_create_dml_plan(...) 9.3 逻辑优化和物理计划逻辑改写入口：pkg/src/ogsql/optimizer/ogsql_transform.c 可见规则包括： ●消除不必要的 ORDER BY ●OR 转 UNION ●谓词传递和下推 ●子查询改写 ●外连接消除 ●IN 转 EXISTS ●投影裁剪 ●DISTINCT 消除 ●ORDER BY 下推等物理计划位于 pkg/src/ogsql/plan： ●plan_dml.c：DML 计划总入口 ●ogsqljoinpath.c：连接路径 ●plan*：scan、range、join、aggregate、sort 等没有可用统计信息时，计划可能设置 optby_rbo；有统计信息时主要走 CBO。因此代码同时保留规则路径和代价路径。 9.4 执行和 Kernel 下沉执行总入口：sql_execute → sql_execute_dml_and_send → sql_try_execute_dml → sql_issue_dml → sql_execute_single_dml SELECT：sql_execute_select → sql_execute_select_plan → sql_execute_query / sql_execute_query_plan → sql_execute_scan → knl_open_cursor fetch： sql_fetch_query → sql_fetch_scan → sql_fetch_one_part → knl_fetch → cursor->fetch DML：INSERT → knl_insert → knl_internal_insert → TABLE_ACCESSOR(cursor)->do_insert → 按需 knl_insert_appendix UPDATE → knl_update → do_update + index maintenance DELETE → knl_delete → do_delete + index maintenance 表访问器选择位于：pkg/src/kernel/catalog/dc_tbl.c::dc_set_table_accessor 典型表映射： ●CR_ROW 表 → heap accessor ●CRPAGE 表 → PCR heap accessor 索引访问器由同一文件中的 dcsetindexaccessor() 绑定： ●普通 B-Tree → btree accessor ●PCR B-Tree → PCR btree accessor 10. Kernel / 存储引擎内部架构 10.1 knl_interface.c 是主要门面 SQL 层调用 Kernel 时，优先从以下文件建立索引：pkg/src/kernel/knl_interface.c pkg/src/kernel/include/knl_interface.h 常用接口：knl_open_dc knl_open_cursor / knl_close_cursor knl_fetch knl_insert knl_update knl_delete knl_commit knl_rollback 10.2 Kernel 子模块子目录职责 buffer/ 页面缓存、latch、页面读取、脏页管理、CR buffer catalog/ 数据字典、table accessor 绑定、元数据缓存 table/ heap、PCR heap、临时表、行操作 index/ B-Tree、PCR B-Tree、索引扫描和维护 xact/ transaction、undo、XA、锁和可见性 persist/ redo、checkpoint、recovery、archive replication/ 日志发送、回放、RBP 等复制能力 backup/ 备份、恢复、build tablespace/ space/datafile 管理 lob/ LOB 存储 sequence/ sequence statistics/ 统计信息 daemon/ 部分后台任务 common/ Kernel 公共上下文、同步点、控制文件恢复等 10.3 一次物理写入的关键动作以普通 heap insert 为例，正确的层次是：knl_internal_insert → TABLE_ACCESSOR(cursor)->do_insert → heap_insert → undo_prepare → 找到/进入 buffer page → heap_insert_row 或 chain_insert → log_put 写 redo → 标记 buffer dirty → 满足 knl_need_insert_appendix(cursor) 时 → knl_insert_appendix → 普通索引维护等附加动作也就是说，heapinsert() 负责 heap 行本身的 undo/redo/buffer 修改；普通索引维护是在 accessor 返回后的上层 Kernel 流程完成，而不是 heapinsert() 内部直接完成。PCR heap 走对应的 pcrh_* 路径。持久化由不同后台机制完成： ●redo 由 log writer 刷盘。 ●dirty data page 由 DBWR/checkpoint 推进。 ●undo 用于事务回滚和一致性读。 ●WAL 规则要求必要的 redo 在脏页或页面所有权转移前达到要求的持久化点。集群模式没有绕开这套单实例存储引擎，而是在 buffer、transaction、lock、recovery 等位置插入 DTC 协同。 11. DTC、MES、RC、CMS 的职责边界组件所在位置主要职责是否在普通页面热路径 DTC pkg/src/cluster，在 ogracd 内集群数据库能力总入口，装配 DRC/DCS/DLS/DMon/Recovery 是 DRC dtc_drc.* 维护全局资源 master、owner、lock mode、转换队列、remaster 是 DCS dtc_dcs.* 页面请求、授权、传输、失效、CR 页面、EDP 是 DLS dtc_dls.* 非页面分布式锁、latch、事务等待和唤醒通常否；操作涉及全局非页面锁或结构 latch 时进入 MES/MEC pkg/src/mec TCP/UC/RDMA 通道、消息发送接收、队列、worker、ACK waiting room 是，作为消息底座 DMon dtc_dmon.* SCN、min_scn、LSN 等周期广播间接 RC/Reform pkg/src/rc + dtc_reform.c 把 CMS 成员变化编排成一轮有版本的 reform 否，属于控制面 CMS Client pkg/src/cms/interface 数据库进程通过本机 UDS 访问 CMS 否 CMS Service pkg/src/cms/cms，独立进程成员、资源、投票、故障检测、GCC、脑裂防护、I/O fencing 否 TMS pkg/src/tms 线程监测否 FDSA pkg/src/fdsa 长 I/O 检测和自愈适配间接最需要避免的误解是：CMS 不负责每次页面读写和锁仲裁。 CMS 决定“哪些节点存活、资源状态是什么、谁是 master、何时需要 fence”；DRC/DCS/DLS 才处理数据库数据面的高频协调。 12. MES/MEC 消息体系核心文件：pkg/src/mec/mes_func.[ch] pkg/src/mec/mes_queue.[ch] pkg/src/mec/mes_tcp.[ch] pkg/src/mec/mes_uc.[ch] pkg/src/mec/mes_type.h 关键对象：对象作用 mesprofilet 实例拓扑、传输类型、通道数、worker 数、buffer pool mescontextt 连接、通道、消息池、waiting room mesmessagehead_t command、源/目标实例、session、RSN、校验信息 meswaitingroom_t 按 session 保存请求序号、ACK bitmap 和响应消息 mqcontextt worker、任务组和消息队列通用链路：业务模块构造 MES_CMD_* → mes_send_data / mes_send_data3 → TCP 或 UC/RDMA → 接收端直接处理或进入任务队列 → dtc_process_message → g_processors[cmd].proc 请求端通常用 session id、RSN 和 timeout 等待 ACK。DDL/DC 广播等需要顺序保证的命令会进入串行任务组。 MES 承载的消息不仅有页面传输，还包括： ●DLS 锁请求/释放 ●事务等待和唤醒 ●远端事务状态和快照 ●SCN/LSN ●DDL/DC 广播 -checkpoint/log/backup ●remaster/recovery/reform ●跨节点死锁 13. DRC、DCS、DLS 的工作方式 13.1 DRC：全局资源目录核心文件：pkg/src/cluster/dtc_drc.[ch] pkg/src/cluster/dtc_drc_util.[ch] DRC 并不保存用户表数据本身，而是保存“谁管理、谁拥有、当前是什么模式”的全局目录信息： ●页面资源 master ●页面 owner 和 lock mode ●只读副本 ●历史脏副本 edp_map ●资源转换队列 ●非页面锁 owner/granted map ●事务等待资源 ●remaster 分区迁移状态当前代码把 DRC 划分为 1024 个分区。页面按 extent 等信息哈希到分区，再由 part_map 确定当前 master；扩缩容或故障后会重新均衡并迁移这些目录。需要区分： ●master：负责仲裁某个资源目录的节点。 ●owner：当前真正持有页面或锁权限的节点。 master 和 owner 可以是不同节点。 13.2 DCS：全局页面缓存一致性典型页面访问链：buf_enter_page / buf_read_page → 集群模式 dtc_read_page → 本地 lock_mode 足够：直接使用本地页 → 否则 dcs_request_page → drc_get_page_master_id → master 执行 drc_request_page_owner → 没有 owner：授权请求者从共享存储加载 → 已有 owner：通知原 owner 发送最新页面 → 请求者 claim ownership 页面以共享或排他模式持有。原排他 owner 转出 dirty/marked 页面前会确保 redo 满足刷盘要求；转出后可能形成 EDP，DRC 的 edp_map 记录历史脏副本关系，供恢复、CR 和 checkpoint 清理等流程使用。关键理解：共享存储里有同一份持久数据 ≠ 所有节点的 buffer cache 自动一致缓存的一致性、最新页传输和页面权限由 DRC/DCS 负责。 13.3 DLS：非页面锁和事务等待 DLS 处理的不是 data page 本身，而是数据库、表、DDL、索引、heap、分区、undo、用户等资源锁，以及跨节点事务等待。典型锁链：dls_spin_lock / dls_latch_s / dls_latch_x → 检查本地 drc_local_lock_res → 本地权限不足时 dls_request_lock → 定位 lock master → master 按 compatibility matrix 仲裁 → 必要时通知旧 owner 释放 → lock master 代表 requester 执行 drc_claim_lock_owner → master 返回 ACK → requester 更新本地 lock_mode / latch state 事务等待：tx_wait → dls_wait_txn → MES_CMD_WAIT_TXN → 事务 owner 或 DRC txn queue 登记 waiter → 提交/回滚 → MES_CMD_AWAKE_TXN → 携带 SCN 唤醒等待节点 Reform version 会阻止旧成员视图下的请求继续完成，避免故障或成员变化期间使用过期授权。 14. 分布式 MVCC 和 SCN 代码中没有一个单独名为“Distributed MVCC Manager”的孤立模块。当前实现更适合这样理解：每实例 transaction / undo 区 + 全局单调推进的 SCN + 远程事务状态查询 + 本地或远程 CR 页面构造 + reform 后故障事务区接管 = 分布式 MVCC 相关机制： 1.PCR ITL 指向远端活跃事务时，通过 dtcgettxn_info 获取状态。 2.远端事务查询使用 MESCMDTXNINFOREQ/ACK、MESCMDTXNSNAPSHOTREQ/ACK。 3.返回 active/committed、commit SCN、rmid 等信息。 4.收到远端页面、SCN、事务信息后，用 dtcupdatescn 单调推进本地 Lamport SCN。 5.DMon 周期广播 SCN、min_scn、LSN；部分提交路径还会执行带 ACK 的 SCN 广播。 6.dtcheap.c、dtcbtree.c 和 dtc_dcs.c 协调远程 PCR/CR 构造。 7.故障节点的 transaction/undo area 会在 reform 中被存活节点接管。这里“分布式 MVCC 是上述机制的组合”属于根据源码形成的架构归纳；不应把它外推成当前仓库未明确提供的独立服务。 15. CMS、RC 与 Reform 15.1 CMS pkg/src/cms/CMakeLists.txt 生成独立 cms 可执行文件。数据库进程只链接 pkg/src/cms/interface 客户端。 CMS 启动可概括为：cms_main → 参数/GCC/磁盘锁初始化 → cms_startup → cms_load_gcc → cms_instance_init → cms_uds_srv_init → cms_startup_mes → 心跳、资源检测、投票、GCC、UDS、MES 等线程数据库与本机 CMS 主要通过 UDS client 交互，CMS 节点之间使用 MES。重要接口：cms_res_inst_register cms_set_res_work_stat cms_get_res_stat_list cms_set_res_data / cms_get_res_data 资源视图包含 ONLINE/OFFLINE、inst id、work status、心跳、version、master instance 等。 15.2 RC/Reform RC 在数据库进程内，负责把 CMS 的成员视图变化转换成一轮有版本号的 reform。初始化：init_dtc_rc → 注册 DTC reform callback → init_cms_rc → cms_cli_init → cms_res_inst_register → 创建 rc_reform_trigger_proc → 创建 rc_reform_proc → work status = JOINING 触发：CMS 状态变化 → rc_notify_cluster_change → rc_reform_trigger_proc → 刷新 current/target cluster view → 唤醒 rc_reform_proc → rc_start_reform → DTC callback 执行具体动作 15.3 Reform 闭环下图严格限定为：partial restart 中 reform master/reformer 处理 out-of-plan 故障时的典型主线。Follower、planned reform 和 full restart 都有不同分支，不会完整执行图中的每一个步骤；例如 planned 模式可能直接广播 redo done，而不实际重放故障 redo。核心状态可概括为；不同 reform 模式不一定逐一经过每个中间状态：PREPARE → FROZEN → MOUNTING 或 RECOVERING → RECOVER_DONE → OPEN → DONE 最核心的闭环是：成员变化 → 冻结旧视图请求 → 网络通道重建 → 全局资源目录 remaster → redo 恢复共享页 → REFORM_RECOVER_DONE → undo/transaction 接管并加载 → reform 达到 OPEN，恢复允许的集群访问 → 后台回滚、checkpoint 和必要的 archive 收尾 → 发布新稳定视图这里的 REFORMOPEN 是 grcctx 的 reform 状态：它在接管 transaction area 并启动后台 rollback 后即可设置，后台 rollback 会继续完成。它不等同于 partial reform 中重新把数据库对象执行一遍 DBSTATUS_OPEN 生命周期。 15.4 集群恢复 Reform 中的主要入口：dtc_partial_recovery → dtc_start_recovery(..., full_recovery = false) 公共初始化大体包括：dtc_recovery_init → 为故障实例建立 recovery node → 确定 checkpoint/redo 起点 → 读取 online/archive/DBStor redo 之后明确分成两条路径：Full recovery → 可选 analysis → full redo replay → recover check → 广播 redo replay done / REFORM_RECOVER_DONE → full checkpoint → 更新 checkpoint/log point Partial recovery → analysis 并构造 recovery set → 把 recovery set 发送给存活 master，等待修订结果 → 仅针对 recovery set 执行 partial redo replay → recover check → 广播 redo replay done / REFORM_RECOVER_DONE → incremental checkpoint → 更新 partial-recovery checkpoint 信息 recovery set 的构造、分发和修订是 partial recovery 的核心步骤；full recovery 不走 dtcsendrcy_set 这套协议。完成 redo 恢复后，还需要接管故障实例 undo/transaction area，处理未提交事务。仅仅重放 redo 并不等于整轮 reform 已完成。 16. DSS、DBStor 和 I/O fencing 16.1 统一设备抽象 Kernel 的控制文件、redo、datafile、archive、backup 等大量路径统一使用：pkg/src/common/cm_device.[ch] 当前定义的设备类型包括：DEV_TYPE_FILE DEV_TYPE_RAW DEV_TYPE_CFS DEV_TYPE_ULOG DEV_TYPE_PGPOOL DEV_TYPE_DBSTOR_FILE 路径前缀会参与设备类型判断，例如： ○→ RAW ○→ PGPOOL ○→ ULOG ●普通路径 → FILE ●DSS 在这里主要体现为：DEV_TYPE_RAW + raw_device_op_t + srv_device_adpt.c 动态加载 libdssapi.so pkg/src/server/srvdeviceadpt.c 会解析 dssfopen、dsspread、dsspwrite 等符号，再把操作表注册给 cmdevice。 DBStor 适配主要在：pkg/src/common/cm_dbs_ulog.c pkg/src/common/cm_dbs_pgpool.c pkg/src/common/cm_dbs_file.c pkg/src/common/cm_dbstor.c pkg/src/common/cm_dbs_intf.h 因此：Kernel I/O → cm_device → FILE / RAW(DSS) / ULOG / PGPOOL / DBSTOR_FILE 当前 DSS/ 是空 gitlink，只能确认本仓库中的 DSS client 适配，不能据此分析 DSS 服务端内部架构。 16.2 I/O fencing dbmount() 早期调用 dbregister_iof()，按存储后端注册 fencing 能力： ●DBStor：按 namespace kick ●DSS：按 instance id kick ●普通共享文件：对应文件型 fencing CMS 检测数据库资源离线时，会进行 I/O fencing，再把资源推进到 OFFLINE 和新视图。目的不是普通的“断开连接”，而是阻止故障节点继续写共享存储，避免脑裂节点破坏数据。 CMS fencing 失败会进入非常严格的失败处理，因为在共享写架构下，不能确认旧节点失去写能力时，就不能安全地让新视图继续服务。 17. 兼容性 A/B/C 的代码落点这是兼容性改造最需要关注的一节。 17.1 兼容模式怎样进入会话数据库级兼容模式保存在：db.ctrl.core.dbcompatibility session 创建、复用或命令处理的相关阶段，会复制到：session->dbcompatibility 当前代码明确支持字符值：A / B / C 本文不把 A/B/C 映射成具体数据库品牌，因为当前仓库证据只稳定地证明了模式字符和代码分支。涉及产品语义时，应以项目正式定义为准。 17.2 语法入口三套语法生成目录：pkg/src/ogsql/parser/dialect_a/backend_parser pkg/src/ogsql/parser/dialect_b/backend_parser pkg/src/ogsql/parser/dialect_c/backend_parser 关键分派位于：pkg/src/ogsql/parser/dml_parser.c::raw_parsersession->dbcompatibility == 'A' → a_format_raw_parser session->dbcompatibility == 'B' → b_format_raw_parser session->dbcompatibility == 'C' → c_format_raw_parser 构建阶段使用 Flex/Bison，从公共的 scan.l、gram.y 生成三套 dialect parser 变体。因此语法兼容问题需要同时区分： 1.公共 grammar 是否应该修改。 2.只应影响某个 dialect 的规则是否有正确条件。 3.生成代码是否需要重新生成。 4.lexer keyword 和 parser token 是否同步。 17.3 兼容性不只在 parser 差异类型优先检查位置关键字、语法、优先级 ogsql/parser、三个 dialect_* DDL 语法和定义 ogsql/parser_ddl 名称解析、类型推导、隐式转换 ogsql/verifier 表达式和内置函数 ogsql/function、ogsql/node/ogsql_func.c 逻辑改写差异 ogsql/optimizer 执行语义、返回值、错误时机 ogsql/executor Kernel 数据类型或存储语义 kernel/include、table/index/xact 等具体模块系统表、视图、函数初始化 pkg/admin/dialectbscripts、pkg/admin/dialectcscripts 建库/升级脚本选择 kernel/catalog/knl_dc.c、安装部署脚本回归测试 pkg/test/og_regress/sql、expected、schedule pkg/src/kernel/catalog/knldc.c 会根据兼容模式选择不同系统脚本目录。安装入口 build/localinstall.sh 支持 -c A|B|C。 17.4 推荐的兼容性改造闭环需求语义 → 确定影响的兼容模式 → lexer/grammar → parse tree → verifier/type inference → optimizer 是否保持语义 → executor / kernel 行为 → 系统对象和初始化脚本 → 正向/负向/跨模式回归至少要验证： 1.目标模式下新语法/语义正确。 2.其他两种模式没有被公共 grammar 或公共 verifier 误伤。 3.prepare、execute、query 三类协议路径一致。 4.DDL 后的数据字典和重连行为一致。 5.错误码、错误时机、NULL 和隐式转换符合目标要求。 6.单节点和 cluster 模式执行结果一致；若涉及事务、DDL、sequence、临时对象，还要验证跨节点可见性。 18. 构建、打包、部署和配置 18.1 构建体系主构建体系：build/Makefile.sh → 准备/编译第三方依赖 → cmake .. → make → 生成运行包、数据库包、symbol 包 build/build_ograc.sh → 调用 Makefile.sh → 打包 og_om → 可选打包 DSS → 生成统一 ograc_connector 交付包常用动作包括：all debug release package-debug package-release incremental-package-debug test make_regress_test make_ograc_pkg_test 全局产物通常进入：output/bin output/lib output/symbol README 也明确建议使用 CMake。仓库中的 Bazel 文件标注为 cmake2bazel 生成，覆盖不完整，例如真实源码是 pkg/src/ogsql，部分 Bazel 文件仍有旧 pkg/src/sql 痕迹；应把 Bazel 当作辅助或历史生成物，不应作为当前完整架构的唯一依据。 18.2 包结构oGRAC-RUN- -64bit.tar.gz ├─ bin ├─ lib ├─ add-ons ├─ data ├─ log ├─ protect ├─ var ├─ admin ├─ cfg └─ package.xml oGRAC-DATABASE- -64bit.tar.gz ├─ install.py ├─ funclib.py ├─ installdb.sh ├─ oGRAC-RUN-*.tar.gz └─ oGRAC-RUN-*.sha256 统一部署包：ograc_connector ├─ action ├─ config ├─ common ├─ repo ├─ odbc ├─ dss # 目录始终创建，--with-dss 时填充 DSS 产物 └─ versions.yml 18.3 新部署框架主入口：pkg/deploy/action/appctl.sh → ograc_deploy.py → 各组件 appctl.sh → Python deploy/ctl 编排器主要编排顺序：安装/启动：cms → dss → ograc → og_om → ograc_exporter 卸载： og_om → ograc_exporter → ograc → dss → cms 核心配置来自：pkg/deploy/action/config_params_lun.json module_config deploy_mode=dss 走当前组件编排；dbstor/combined 的部分动作会路由到历史 storage deploy 流程。 18.4 运维管理 og_om 的主要结构：ogcli → Unix Domain Socket → ogmgr/uds_server.py → tasks.json / task.py → 审计、巡检、日志查询、日志采集 ograc_exporter → 周期采集 CMS、DBStor、DR 等状态 → 保存有限数量的 JSON 快照 18.5 主要配置文件配置作用 pkg/cfg/ogracd.ini 数据库实例参数模板 pkg/cfg/cms.ini CMS 参数 pkg/cfg/cluster.ini 集群参数 pkg/cfg/oghba.conf 客户端访问控制 pkg/cfg/nodeconfigtcp.xml MES TCP 节点拓扑 pkg/cfg/nodeconfigrdma.xml MES RDMA 节点拓扑 pkg/cfg/*_cms.xml CMS 对应节点通信配置 pkg/cfg/rbps.conf RBPS 配置 pkg/src/server/params 参数加载、校验和动态设置实现 19. 测试体系 19.1 SQL 回归入口：pkg/test/og_regress 主要内容：sql/ SQL 用例 expected/ 期望输出 results/ 实际结果 og_schedule_part1 og_schedule_part2 do_all_test.sh 执行链：pkg/test/og_regress/do_all_test.sh → CI/build/script/run_ograc_test.sh part_all → CI/script/Dev_ograc_regress.sh → 编译并安装临时实例 → ogdb_regress_ograc.sh → og_regress --schedule=... 兼容性改造应优先在这里增加： ●目标模式正向用例 ●目标模式负向用例 ●另外两种模式的防串扰用例 ●prepare/execute 和直接 query 的差异用例 ●必要的多节点一致性用例 19.2 单元测试当前 CMake 可见的 GoogleTest 目标：knl_test mes_test cms_test server_test common_test ogbackup_test 统一脚本 CI/script/Devunittest.sh 会构建测试、运行目标、输出 gtest XML 并生成 LCOV 覆盖率。另有 CMS、MES、DTC/集群专项脚本，以及 pkg/test/omtest/pythonLLT.py 的部署模块 Python 测试。 19.3 CI 特点仓库没有 GitHub Actions、GitLab CI 或 Jenkinsfile；CI/ 中主要是供外部流水线调用的 Shell 入口。部分旧脚本引用的目录或文件在当前 checkout 已不存在，执行前必须核对真实路径。 20. 当前 checkout 的构建限制当前目录不适合直接在 Windows 上尝试完整构建： 1.构建流程依赖 Linux、Bash、GCC、pthread、NUMA、RPM/yum 等。 2.open_source 和 DSS 是空 gitlink。 3..gitmodules 只有 open_source 映射，没有 DSS 映射。 4.library 没有完整预编译依赖。 5.DBStor、xnet、KMC、gtest/gmock/mockcpp 等依赖需要项目规定的依赖包或 CI 基础环境。 6.output/ 当前不存在。 7.CMake 还引用当前 checkout 中不存在的 pkg/src/shard、pkg/src/zenfs、pkg/src/extproc、platform、build_dependence 等遗留路径。 8.部分 cluster/basic/默认 regression 旧入口引用缺失目录或脚本，不能不加核对地直接执行。 9.版本源存在不一致：CMake 侧可见 7.0.0-RC3，部分已检入配置、RPM 和 versions.yml 为 1.0.0，正式打包前应确认权威版本来源。 10.build/local_install.sh 的 compile 动作会用 sed 改源码中的硬编码路径，适合一次性容器或干净工作树，不适合在有本地改动的目录中直接使用。推荐在项目提供的 Linux/CI 依赖环境中构建：cd oGRAC/build sh Makefile.sh package-debug sh Makefile.sh package-debug --without-deps sh Makefile.sh incremental-package-debug 统一部署包：cd oGRAC/build sh build_ograc.sh debug sh build_ograc.sh debug --with-dss --third-party-path /path/to/third_party 21. 架构耦合特点和阅读注意事项 21.1 概念分层不等于严格依赖分层从产品角度可以清晰地说 Server、SQL、Kernel、DTC、CMS、Storage；从实现角度则存在： ●大量全局 include_directories ●静态库循环符号依赖 ●--start-group/--end-group ●SQL 直接访问 g_instance ●sessiont 内嵌 knlsession_t ●instance_t 同时内嵌 SQL 和 Kernel ●Kernel 通过 gknlcallback 回调 SQL/Server ●多个全局单例所以不要用“上层只能调用下一层，下一层绝不认识上层”的理想分层去套代码。 21.2 目录名和运行概念不总是一一对应 ●mec 目录构建 ogmes，代码和消息 API 大量使用 MES。 ●DTC 是一组集群能力的总称，不只对应一个文件。 ●分布式 MVCC 是 transaction/SCN/CR/reform 的组合，不是一个孤立目录。 ●DSS 服务端不在当前 checkout 中，仓库内主要可见 client device adapter。 ●Bazel 里的旧路径不能替代当前真实目录和 CMake。 21.3 阅读时优先查看对象建议始终关注以下对象怎样向下传递：g_instance session_t / knl_session_t sql_stmt_t sql_context_t knl_cursor_t buf_ctrl_t page_id_t drid_t mes_message_head_t reform_ctx_t 只看函数名容易迷失；把“当前 session、当前 cursor、当前 page、当前 resource id、当前 reform version”串起来，调用链会清晰很多。 21.4 区分事实和推断当前源码可以明确证明： ●具体调用链、函数表、结构体和消息命令 ●DRC 分区、owner/master、页面和锁转换 ●CMS/RC/DTC 的协作 ●DSS 动态客户端适配但以下内容不应过度外推： ●DSS 服务端内部机制 ●DBStor 服务端内部实现 ●A/B/C 与具体品牌的产品映射 ●某些模式名背后的完整商业语义 ●未出现在当前 checkout 中的组件行为 22. 推荐阅读路线路线 A：先建立全貌README.md → CMakeLists.txt → pkg/src/CMakeLists.txt → pkg/src/server/CMakeLists.txt → pkg/src/server/srv_main.c → pkg/src/server/srv_instance.c 目标：知道有哪些进程、库，以及 ogracd 启动了什么。路线 B：追一条普通 SQLsrv_lsnr.c → srv_session.c → srv_reactor.c → srv_agent.c → ogsql_service.c → ogsql_stmt.c → parser/dml_parser.c → verifier/ogsql_verifier.c → optimizer/ogsql_transform.c → plan/plan_dml.c → executor/dml_executor.c → kernel/knl_interface.c 再从 knl_fetch/insert/update/delete 下钻到 heap、PCR heap 和 btree。路线 C：做兼容性开发parser/dml_parser.c::raw_parser → dialect_a/b/c → gram.y / scan.l → verifier → function / node → optimizer → executor → pkg/admin/dialect_*_scripts → og_regress 先找一个与需求相似的既有 A/B/C 分支，沿完整路径复制其设计方法，不要只改 grammar。路线 D：理解 RAC 页面热路径kernel/buffer → dtc_buffer.c → dtc_dcs.c → dtc_drc.c → mes_func.c / mes_queue.c → 对端 dtc_process_message 兼容性重点观察： ●page master ●page owner ●lock mode ●request/claim ●EDP ●redo flush 路线 E：理解故障恢复cms_stat.c / cms_node_fault.c / cms_iofence.c → cms/interface → rc_reform.c → dtc_reform.c → dtc_drc.c remaster → dtc_recovery.c → dtc_tran.c → knl_recovery.c 重点观察 current/target view、reform version、reformer、recover list、undo deposit。 23. 按问题找代码想回答的问题优先入口 ogracd 从哪里启动？ pkg/src/server/srv_main.c 实例初始化顺序是什么？ pkg/src/server/srvinstance.c::srvinstance_startup Kernel 何时启动？ pkg/src/server/srvinstance.c::srvkernel_startup、pkg/src/kernel/common/ knlcontext.c::knlstartup MOUNT/OPEN 做了什么？ pkg/src/kernel/knldatabase.c::dbmount/db_open listener 怎样接收连接？ pkg/src/server/srvlsnr.c、pkg/src/protocol/cslistener.c reactor/agent 怎样调度？ pkg/src/server/srvreactor.c、pkg/src/server/srvagent.c 协议命令在哪里分派？ pkg/src/server/srvsession.c::gservercmdhander 一条 Query 的入口？ pkg/src/ogsql/ogsqlservice.c::sqlprocess_query SQL 编译顺序？ pkg/src/ogsql/parser/dmlparser.c::sqlcreate_dml 语义校验在哪里？ pkg/src/ogsql/verifier/ogsql_verifier.c 逻辑改写有哪些规则？ pkg/src/ogsql/optimizer/ogsql_transform.c 物理计划从哪里生成？ pkg/src/ogsql/plan/plan_dml.c SELECT 怎样下沉？ pkg/src/ogsql/executor/ogsqlselect.c、pkg/src/ogsql/executor/ogsqlscan.c INSERT/UPDATE/DELETE 怎样下沉？ pkg/src/ogsql/executor/ogsqlinsert.c、pkg/src/ogsql/executor/ogsqlupdate.c、pkg/src/ogsql/executor/ogsql_delete.c SQL/Kernel 边界在哪里？ pkg/src/kernel/knlinterface.c、knlcursor_t heap/PCR accessor 怎样选择？ pkg/src/kernel/catalog/dctbl.c::dcsettableaccessor Buffer page 怎样访问？ pkg/src/kernel/buffer、pkg/src/cluster/dtc_buffer.c 页面 master/owner 在哪里？ pkg/src/cluster/dtc_drc.c 页面传输在哪里？ pkg/src/cluster/dtc_dcs.c 分布式锁在哪里？ pkg/src/cluster/dtc_dls.c 远程事务状态在哪里？ pkg/src/cluster/dtc_tran.c SCN/LSN 广播在哪里？ pkg/src/cluster/dtc_dmon.c、相关 log/transaction 路径 MES 消息怎样收发？ pkg/src/mec/mesfunc.c、pkg/src/mec/mesqueue.c Reform 怎样触发？ pkg/src/rc/rc_reform.c Reform 具体执行什么？ pkg/src/cluster/dtc_reform.c 故障 redo 怎样恢复？ pkg/src/cluster/dtcrecovery.c、pkg/src/kernel/persist/knlrecovery.c CMS 怎样判故障和 fence？ pkg/src/cms/cms/cmsstat.c、pkg/src/cms/cms/cmsnodefault.c、pkg/src/cms/cms/cmsiofence.c DSS 怎样接入？ pkg/src/server/srvdeviceadpt.c、pkg/src/common/cm_device.c DBStor 怎样接入？ pkg/src/common/cmdbs*、pkg/src/common/cm_dbstor.c A/B/C 语法怎样分派？ pkg/src/ogsql/parser/dmlparser.c::rawparser 兼容模式系统脚本怎样选择？ pkg/src/kernel/catalog/knldc.c、pkg/admin/dialect*_scripts 参数在哪里定义和校验？ pkg/src/server/params SQL 回归在哪里？ pkg/test/og_regress 单元测试入口？ pkg/test/unittest、CI/script/Devunit_test.sh 构建和打包入口？ build/Makefile.sh、build/build_ograc.sh 新部署入口？ pkg/deploy/action/appctl.sh、ograc_deploy.py 24. 最小必读文件清单如果只保留一组核心入口，建议是：CMakeLists.txt pkg/src/CMakeLists.txt pkg/src/server/CMakeLists.txt pkg/src/server/srv_main.c pkg/src/server/srv_instance.[ch] pkg/src/server/srv_lsnr.c pkg/src/server/srv_session.[ch] pkg/src/server/srv_reactor.c pkg/src/server/srv_agent.c pkg/src/server/srv_sga.h pkg/src/ogsql/ogsql_service.c pkg/src/ogsql/ogsql_stmt.c pkg/src/ogsql/parser/ogsql_parser.c pkg/src/ogsql/parser/dml_parser.c pkg/src/ogsql/verifier/ogsql_verifier.c pkg/src/ogsql/optimizer/ogsql_transform.c pkg/src/ogsql/plan/plan_dml.c pkg/src/ogsql/executor/dml_executor.c pkg/src/kernel/knl_interface.c pkg/src/kernel/include/knl_interface.h pkg/src/kernel/include/dml_defs.h pkg/src/kernel/common/knl_context.c pkg/src/kernel/knl_database.c pkg/src/kernel/catalog/dc_tbl.c pkg/src/kernel/buffer/* pkg/src/kernel/table/knl_heap.c pkg/src/kernel/table/pcr_heap.c pkg/src/kernel/index/knl_index.c pkg/src/kernel/xact/knl_tran.c pkg/src/kernel/persist/knl_log.c pkg/src/kernel/persist/knl_recovery.c pkg/src/cluster/dtc_context.[ch] pkg/src/cluster/dtc_drc.[ch] pkg/src/cluster/dtc_dcs.[ch] pkg/src/cluster/dtc_dls.[ch] pkg/src/cluster/dtc_tran.[ch] pkg/src/cluster/dtc_reform.[ch] pkg/src/cluster/dtc_recovery.[ch] pkg/src/mec/mes_func.[ch] pkg/src/mec/mes_queue.[ch] pkg/src/rc/rc_reform.[ch] pkg/src/cms/cms/cms_main.c pkg/src/cms/cms/cms_stat.c pkg/src/cms/cms/cms_vote.c pkg/src/cms/cms/cms_node_fault.c pkg/src/cms/cms/cms_iofence.c pkg/src/cms/interface/cms_interface.h pkg/src/common/cm_device.[ch] pkg/src/server/srv_device_adpt.c build/Makefile.sh build/build_ograc.sh pkg/deploy/action/appctl.sh pkg/deploy/action/ograc_deploy.py pkg/test/og_regress/do_all_test.sh CI/script/Dev_unit_test.sh 25. 最终结论 oGRAC 的核心不是在传统单机内核旁边简单增加一个“集群插件”，而是把集群协调深入到了数据库生命周期、buffer、锁、事务、SCN、redo/undo 恢复和设备 fencing 中。理解它时，可以始终抓住三组关系：Server session → SQL stmt → Kernel cursor Kernel page/lock/txn → DRC/DCS/DLS → MES → 对端节点 CMS 成员视图 → RC/Reform → Remaster/Recovery → 新稳定集群对于兼容性开发，主要工作面仍然从 SQL parser/verifier/executor 开始，但不能忽略 Kernel 语义、系统脚本、跨模式防串扰和集群可见性。对于 RAC 问题，则要从具体 page/lock/transaction resource 出发，串起 DRC master、owner、MES 消息和 reform version。这两条阅读主线结合起来，基本就能覆盖 oGRAC 日常代码定位和后续兼容性改造所需的整体架构知识。