从Oracle多进程到OceanBase单进程多线程：DBA必修的架构认知课

很多 Oracle DBA 第一次接触 OceanBase 时都会有一个类似的困惑安装好测试环境之后ps -ef一看发现只有一个observer进程没有 PMON、没有 SMON、没有 DBWn、没有 LGWR、没有 CKPT甚至连“多实例”的影子都找不到。第一反应通常是是不是装错了或者是不是进程没起来其实都不是。只是你的进程模型需要“重装”一遍认知。在不少转型团队中这个“进程模型”问题会被低估。很多 Oracle DBA 以为从 Oracle 转到 OceanBase重点是学 SQL 差异、学 PL/SQL 兼容性、学备份恢复命令。但真正到了生产环境第一次排障就会卡住想用ps定位某个后台任务、想杀掉某个 hang 住的会话、想查看 redo 日志写入有没有异常、想理解合并merge到底谁在干活……这些动作的基础全都是“进程到底怎么组织”。所以我觉得Oracle DBA 转向 OceanBase第一课不是学语法而是先把“多进程”这套认知放一放建立起“单进程多线程”的地基。本文会围绕这个主题从 Oracle 多进程架构讲起再拆解 OceanBase 的单进程多线程模型最后给出可落地的运维排查命令和转型建议。全程不涉及 Oracle 和 OceanBase 的具体版本私有细节重点讲架构思路和动手方法。1. 为什么要先“忘掉”多进程1.1 Oracle DBA 最容易踩的惯性坑Oracle 的进程模型已经深入人心。一个常规的 Oracle 数据库实例ps -ef | grep oracle能看到一大串进程名PMON、SMON、DBW0、LGWR、CKPT、MMON、MMNL 等等。即使你不是专职 DBA只要做过 Oracle 相关工作也会下意识地认为“数据库 多个后台进程 共享内存 用户进程”。这个模型实在太稳固了。结果就是很多 Oracle DBA 在转向 OceanBase 后会不自觉地把 Oracle 的思维方式套上去。比如遇到慢 SQL第一反应是去看v$session里当前会话在等什么事件看到某个后台线程占用 CPU 高第一反应是“这个进程是不是有问题要不要 kill 掉”要做日志清理第一反应是“trc 文件是不是和某个进程相关”。这些思路在 Oracle 里是对的但在 OceanBase 里会导致两个问题一是找错对象你根本找不到对应的“进程”二是用错方法你以为是进程级问题其实是线程级问题。1.2 架构认知决定了排障方向学习一个新数据库最容易犯的误区是只记命令不建模型。不理解进程模型你就很难解释为什么 OceanBase 安装完只有一个进程为什么一个 observer 能同时服务多个租户为什么top里看到 observer 占用多个 CPU 核却不知道是哪个线程在忙为什么出现了大查询Oracle 会“吃掉”PGAOceanBase 却有租户内存限制为什么 OceanBase 要做“合并”而 Oracle 没有这个术语这些问题的答案全都绕不开“单进程多线程”这个架构基础。所以本文把这套认知摆到最前面。后面讲命令、讲排查、讲运维都是基于这个模型展开的。2. 先回顾Oracle 的多进程架构在讲 OceanBase 之前有必要把 Oracle 的进程模型快速梳理一遍。这不是凑篇幅而是为了建立对比参照系。2.1 Oracle 进程的三类划分Oracle 的进程通常可以分成三类用户进程。指的是客户端程序比如运行在应用服务器上的 JDBC 连接、sqlplus命令等。它不直接操作数据库文件。服务器进程。当用户进程发起会话后Oracle 会为这个会话分配一个服务器进程dedicated server 模式下。服务器进程负责解析 SQL、执行 SQL、访问缓冲区缓存、把结果返回给用户进程。后台进程。这是数据库实例自己维护的进程负责完成各种后台维护工作比如写数据文件、写日志、做检查点、监控实例状态等。对一个 DBA 来说最熟悉的就是后台进程这一组。2.2 关键后台进程的职责简单列出几个最重要、也是 DBA 平时排查最常提到的进程进程全称核心职责如果异常会出现什么PMONProcess Monitor监控其他进程异常时清理失效进程和资源进程崩溃后资源不释放SMONSystem Monitor实例恢复、临时段清理、合并空闲空间崩溃恢复变慢或异常DBWnDatabase Writer把脏缓冲区写回数据文件检查点推进慢IO 压力异常LGWRLog Writer把 redo log buffer 写到在线日志文件提交变慢甚至 hang 住CKPTCheckpoint Process更新检查点信息触发 DBWn 写盘实例恢复时间变长可以看出Oracle 把“写数据”“写日志”“做恢复”“管进程”这些工作拆成了不同的进程各自独立运行互不阻塞。这是上世纪传统数据库架构的典型设计进程间通过共享内存SGA通信并由操作系统统一调度。2.3 多进程架构解决的核心问题多进程的好处很容易理解某一类后台任务出了问题不影响其他后台任务继续运行可以通过操作系统的进程管理工具单独观察某个进程的 CPU、内存、IO进程崩溃后PMON 可以完成清理实例具备较强的自愈能力。但这个模型也有对应的管理成本进程数量多、内存结构复杂SGA 里的 shared pool、buffer cache、redo log buffer 都要单独调优、进程间切换和通信开销更明显。DBA 需要花很多精力去管理这些进程和共享结构。对于 Oracle 这种集中式数据库多进程模型是成熟且稳定的选择。但到了分布式数据库场景这套模型会带来新的问题。3. OceanBase 为什么选择“单进程多线程”3.1 observer 进程是什么OceanBase 的数据库节点从操作系统层面看就是一台机器上跑了一个observer进程。这个进程不是“一个简单的 oracle 进程”而是把传统数据库里几乎所有的后台工作都装进去了SQL 解析、事务处理、存储管理、日志写入、合并、选举、负载均衡、RPC 通信……全在这一条进程里。一个 OceanBase 集群通常包含多个 zone每个 zone 里有若干台机器每台机器上跑一个observer。这些observer进程之间通过 RPC 通信共同组成一个分布式数据库集群。对 DBA 来说最直观的变化是你不再需要“看到一堆进程名”来判断数据库是否正常你只需要关注observer进程是否活着、线程工作是否正常。客户端应用 / 运维工具 │ ▼ ┌───────────────────────────────┐ │ observer 进程 │ │ ┌───────┬───────┬────────┐ │ │ │ 网络 │ SQL │ 事务 │ │ │ ├───────┼───────┼────────┤ │ │ │ 存储 │ 合并 │ 日志 │ │ │ └───────┴───────┴────────┘ │ └───────────────────────────────┘ │ ▼ 数据文件 / 日志文件3.2 OceanBase 的线程体系Observer 进程内部是典型的多线程模型而不是多进程模型。不同版本的 OceanBase 里线程名和划分方式会有细微差异以实际部署版本为准。但常见的线程类型可以从职责上做一个分类网络与 RPC 线程。负责监听客户端的 SQL 请求和集群内部节点之间的 RPC 请求。这类似于 Oracle 的监听器listener和内部通信机制的结合体。工作线程Worker。负责真正执行 SQL。当客户端发来请求时OceanBase 会把请求分发给空闲的 Worker 线程去执行。这和 Oracle 的 dedicated server 进程职责类似但区别是Worker 线程是池化复用的不是“一个会话一个线程”。日志写线程。负责把事务日志clog写入日志文件。可以简单理解成 OceanBase 版本的 LGWR但它不是独立进程而是 observer 里面的线程。合并线程。OceanBase 的存储层会定期做“合并”major compaction把内存中的增量数据落到磁盘上的静态数据里。这个动作由合并线程触发和执行。选举线程。OceanBase 是高可用架构分区的主副本需要通过选举产生。选举线程负责心跳和选举。这种线程模型决定了你在操作系统层面只会看到一个进程但在进程内部有几十甚至上百个线程同时在干活。3.3 为什么分布式数据库反而选择单进程很多人会问Oracle 用多进程为什么 OceanBase 反而用单进程多线程这不是倒退吗其实不是。单进程多线程在分布式场景下有一个非常关键的优势线程间共享内存更自然。分布式数据库最麻烦的事情之一是保证事务、存储、日志之间的一致性。如果有多个进程进程间通过共享内存通信会有锁竞争、内存同步、状态分散等问题。而单进程多线程模型里所有线程共享同一个地址空间事务状态、缓存、日志缓冲区的共享成本更低代码实现上更容易保证一致性。同时单进程模型让一个节点的资源分配更容易做租户隔离。OceanBase 一个 observer 可以服务多个租户tenant每个租户可以分配不同的内存和 CPU 配额。如果每个租户都对应一个进程进程之间的资源隔离和调度会很复杂。而用单进程多线程就可以在进程内部按线程组做资源隔离比如限制某个租户最多使用多少 CPU、多少内存。当然这个模型也有代价一旦 observer 进程出现严重问题比如内存泄漏、进程 hang 住影响范围是整个节点而不是单个后台进程。这也是 OceanBase DBA 需要重点监控 observer 进程健康状态的原因。4. 逐项对比进程、内存、连接、日志下面把 Oracle 和 OceanBase 的关键模块做一次逐项对比。这组对比是 Oracle DBA 转型时最需要建立的新记忆。4.1 进程模型对比对比维度OracleOceanBase操作系统进程多个后台进程 用户服务器进程单节点一个 observer 进程并发处理方式进程级并发线程级并发后台任务承载独立进程承载如 DBWn、LGWR独立线程承载如日志写线程、合并线程会话与进程关系一个会话可以对应一个服务器进程dedicated一个会话由线程池中的某个线程执行不是一一对应进程/线程异常影响单个后台进程异常可由 PMON 恢复线程异常通常影响隔离范围取决于资源组设计对 DBA 的直接影响是ps -ef | grep pmon这类命令在这里完全失效。你需要学会用top -H -p查看线程用ps -T观察线程级状态。4.2 内存模型对比Oracle 的内存模型由 SGA 和 PGA 构成。SGA 是共享内存区域包含共享池、缓冲区缓存、重做日志缓冲区等PGA 是服务器进程私有内存包含排序区、哈希区等。OceanBase 的内存模型概括说是“进程内统一内存 租户内存隔离”。OBServer 的总内存上限由memory_limit或memory_limit_percentage这类参数控制。在这个总内存里一部分是系统内存一部分分配给各个租户。租户内存里通常包含MemStore新写入数据先放在内存里类似“增量数据”区域对应的后台动作是“转储”和“合并”。Block Cache数据块的缓存功能上类似 Oracle 的 buffer cache。SQL 执行区类似 PGA 的角色用于排序、哈希等操作。这里的核心差异是Oracle 的 PGA 是“每个进程各管各的”而 OceanBase 的 SQL 执行内存是在租户的 Work Area 里统一管理。如果你在 OceanBase 里做超大排序内存用多了可能影响同一个租户里的其他 SQL 执行必须靠租户级内存限制来兜底。4.3 会话与连接管理对比Oracle 的连接方式非常经典客户端通过监听器listener默认端口 1521建立连接然后由监听器 fork 出一个服务器进程或把连接交给 dispatcher。OceanBase 的连接也走“端口监听”模式。默认情况下observer 的 SQL 端口是 2881RPC 端口是 2882。客户端比如obclient、Navicat、JDBC通过 2881 端口连接数据库。不一样的地方在于OceanBase 的连接并不直接对应一个专属进程。连接进来之后请求会被拆分成任务交给线程池里的空闲线程去执行。所以哪怕应用层同时建立了大量连接真正的执行线程数量是相对有限的不会像 Oracle 那样“一个会话一个进程”地消耗系统资源。4.4 日志与后台任务对比Oracle 里查看告警日志一般在$ORACLE_BASE/diag/rdbms/dbname/sid/trace/alert_sid.log。日志按实例组织。OceanBase 的日志目录通常位于 observer 的log/目录下核心日志文件是observer.log。除了observer.log还可能看到election.log选举相关、rootservice.logRootService 相关集群管理服务等。后台任务方面后台任务OracleOceanBase写数据文件DBWn 进程转储dump、合并merge相关线程写日志LGWR 进程clog 写线程实例恢复SMON 进程节点启动后的恢复流程后台监控统计MMON、MMNL 进程内部统计线程Merge合并是 OceanBase 里比较有特色的机制Oracle DBA 第一次听到往往不太理解。简单说OceanBase 内存里的增量数据不会像 Oracle 那样每个脏块都让 DBWn 直接写盘。它先把新写入的数据放在 MemStore 中再通过“转储”小型落盘和“合并”把增量合并到静态数据中完成持久化。合并触发时IO 和 CPU 开销会增加这也是运维巡检时要重点关注的时间窗口。5. 实战用三大命令摆脱“多进程”惯性讲完概念下面直接上手。作为一个刚转到 OceanBase 的 DBA你最需要掌握的是怎么用操作系统命令观察 observer怎么用数据库视图查会话怎么快速定位日志。5.1 用 ps、top 重新认识 observer先看进程ps -ef | grep observer正常情况下你会看到一台机器上有一个 observer 进程。注意观察它的启动时间、CPU 使用率、内存占用。如果进程不存在数据库节点肯定有问题。接下来看线程。这是 Oracle DBA 最需要养成的新习惯。查看 observer 进程内的线程状态# 先拿到 observer 的 PID pidps -ef | grep observer | grep -v grep | awk {print $2} # 按线程维度查看 CPU 占用 top -H -p $pidtop -H之后你可以看到 observer 进程内每个线程的 CPU 占用情况。如果某个线程 CPU 特别高记下它的线程名或线程号再结合日志去判断它到底在干什么。也可以使用ps -T -p $pid这个命令会列出 observer 进程的所有线程。你能看到线程名比如网络线程、工作线程、日志线程等。注意不同版本线程名会有差异不需要死记。关键是建立“进程内部还有几十个线程CPU 高必须先定位到线程”的意识。5.2 用数据库视图查询会话与等待Oracle DBA 非常熟悉v$session在 OceanBase 里也有类似的视图。在 Oracle 兼容模式下可以查询V$SESSION或GV$SESSION来查看当前会话信息。先连接到数据库obclient -h127.0.0.1 -P2881 -usystenant#cluster -p -A这里的连接字符串格式和 Oracle 的 user/passwordhost:port/sid 不一样是 OceanBase 特有的租户连接方式需要提前了解清楚。连接后查询会话SELECT sid, user, status, sql_id, event FROM v$session WHERE status ACTIVE;如果想看当前正在执行的 SQLSELECT sql_id, sql_text FROM v$sql WHERE sql_id xxx;下面这个查询在排查慢 SQL 和会话卡死时很实用类似于 Oracle 里“查当前会话等待事件”的操作SELECT s.sid, s.user, s.event, s.wait_class, s.sql_id FROM v$session s ORDER BY s.wait_time DESC;这里需要提醒一下OceanBase 的V$SESSION视图和 Oracle 的V$SESSION在列名上有交集但不完全一致。实际使用时先查看视图结构再写查询语句DESC v$session;避免拿 Oracle 的 SQL 直接套。5.3 用日志快速定位问题日志查看是最能体现“架构差异”的场景。Oracle 时代你习惯tail -f alert_SID.log日志按实例归类出了问题先看 alert log。OceanBase 里不要这样想你应该先记住 observer 的日志目录。假设 observer 安装目录是/home/admin/oceanbase常见的日志路径是/home/admin/oceanbase/log/observer.log查询错误日志可以先 grep 关键字grep ERROR /home/admin/oceanbase/log/observer.log | tail -100如果某个 SQL 执行异常可以通过observer.log里的 trace 信息定位。比如grep ERROR /home/admin/oceanbase/log/observer.log | grep tenant_id:1001在运维监控中还可以使用 OceanBase 提供的运维工具obdiag或者图形化监控平台采集日志和top -H的输出做诊断。但核心第一步仍然是快速找到 observer 日志并学会在日志和线程之间建立关联。6. 从 Oracle 运维习惯迁移到 OceanBaseDBA 的日常工作不只是“会查进程”还包括巡检、备份恢复、性能分析、扩容缩容。下面把这些环节中需要“改习惯”的地方单独拎出来说。6.1 巡检思路的调整Oracle 巡检时DBA 往往会看实例状态select instance_name, status from v$instance;监听状态lsnrctl status后台进程是否齐全告警日志里有没有 ORA-600 之类的错误OceanBase 巡检对应的动作是检查 observer 进程是否存活进程内存占用是否合理检查集群状态用SELECT * FROM oceanbase.__all_server;看每个 OBServer 是否在线查看告警日志中的 ERROR 和 WARN检查合并是否正常完成观察合并耗时和合并期间的 IO 压力。另一个很实用的巡检点是检查集群里各个节点的状态。可以用SELECT svr_ip, svr_port, zone, status, start_service_time FROM oceanbase.__all_server;这个视图在 Oracle 兼容模式和 MySQL 模式下都存在只是访问方式略有差异。建议先在自己环境的文档里确认当前版本的内部表名称。6.2 性能分析习惯的调整Oracle 的性能分析核心是 AWR 报告和等待事件。DBA 会抓 AWR看 Top 等待事件看 SQL 执行计划。OceanBase 的性能分析思路仍然是“等待事件 SQL 执行计划 资源消耗”但操作入口不同等待事件可以从V$SESSION_WAIT、V$SYSTEM_EVENT等视图查询慢 SQL 可以在GV$OB_SQL_AUDIT或对应的 SQL 审计视图中查询性能问题定位时要回到top -H看线程再对线程名和等待事件做关联。下面是一个常见的慢 SQL 查询示例用 SQL Audit 视图定位耗时排名靠前的 SQLSELECT sql_id, elapsed_time, cpu_time, executions, elapsed_time / executions AS avg_elapsed FROM gv$ob_sql_audit ORDER BY elapsed_time DESC LIMIT 10;这里的关键差异在于GV$OB_SQL_AUDIT是 OceanBase 自己提供的 SQL 审计视图不是 Oracle 的V$SQLAREA。列名有差异查询逻辑可以参考但不要直接照搬。另外Oracle DBA 习惯用DBMS_STATS收集统计信息OceanBase 里也有对应的统计信息收集手段一般通过DBMS_STATS或ANALYZE TABLE但具体支持程度要看兼容模式。生产环境中建议根据当前租户模式查阅官方文档而不是硬套 Oracle 语法。6.3 高可用与扩缩容思路Oracle 的高可用常用 RAC 或 Data Guard。RAC 的特点是多个实例同时访问同一个数据库通过集群件管理。OceanBase 的高可用核心是“多副本 选举”每个分区可以有多个副本通常 3 副本分布在不同的 zone主副本故障时通过 Paxos 协议自动选主应用几乎无感知扩缩容本质上是在集群里增加或下线 observer 节点数据会自动做负载均衡。对 DBA 来说你需要理解一个概念Oracle RAC 的扩展粒度是“实例”OceanBase 的扩展粒度是“节点 分区副本”。运维手段也从“RAC 集群命令”变成“OceanBase 集群管理工具”比如ALTER SYSTEM ADD SERVER添加节点ALTER SYSTEM STOP SERVER停节点通过 RootService 自动完成副本迁移。这里不展开命令细节因为不同版本命令略有差异。重点是调整思路OceanBase 集群里observer节点更像是“资源池”的一部分节点故障不是灾难而是触发自动选主和副本重新分布的信号。7. 常见误区与 FAQ7.1 三个高频误区误区 1用 Oracle 进程思维去看 OB 状态。很多 DBA 刚上手习惯性用ps -ef | grep找 PMON、SMON。找不到就以为数据库没启动。实际上应该看observer进程是否存在以及 2881 端口是否在监听。记住一句话OceanBase 不看进程列表看线程和视图。误区 2一个会话对应一个线程杀掉线程就解决问题。在 Oracle 里如果某个会话发生异常DBA 可能直接ALTER SYSTEM KILL SESSION。在 OceanBase 里会话和 Worker 线程是池化关系。你 kill 的通常是一个会话而不是一个“专属操作系统线程”。所以不要试图用操作系统命令去 kill 一个线程那样可能影响整个 observer 进程。应该使用数据库层的会话管理命令。误区 3不关注合并拿 Oracle 的脏块写盘经验硬套。OceanBase 的合并是存储层的核心机制。如果合并异常可能出现存储空间增长、查询性能下降的问题。Oracle DBA 一开始容易忽略这个指标需要把它纳入日常巡检。7.2 FAQ 表格问题答案OceanBase 能像 Oracle 一样看v$session吗可以OceanBase 提供兼容视图V$SESSION/GV$SESSION但列名有差异使用前先DESC查看结构。连接 OceanBase 和连接 Oracle 用同一套 JDBC 吗不完全一样。OceanBase 支持 MySQL 和 Oracle 两种模式驱动连接串、驱动类名不同需要按租户模式选择。Oracle 的分页写法ROWNUM在 OceanBase 里能用吗Oracle 兼容模式下可以但也推荐了解 OceanBase 对FETCH FIRST、LIMIT等分页方式的支持按实际版本为准。observer 日志和 Oracle 的 alert log 有什么区别observer.log 包含更细粒度的运行信息不只有错误。日常看 ERROR 级别和 WARN 级别即可。单进程会不会导致单点故障不会。OceanBase 的可靠性来自多副本和自动选主不是单机进程多么健壮。所以节点级故障是正常的设计场景。需要学会哪些新的运维工具常用的是 oceanbase 客户端、obdiag、OCP 图形化运维平台等。可以先从命令行版开始练。8. 最佳实践与转型路线建议8.1 给自己做一次“线程视角”的思维训练转型初期建议做一个刻意练习选一个测试环境每天花十分钟用top -H和ps -T观察 observer 的线程状态。看到线程名后不要只看“看不懂的字符串”而是尝试回答三个问题这个线程属于哪类职责网络、SQL 执行、日志写、合并、选举还是内部统计如果它 CPU 高数据库整体表现如何如果它长时间等待会不会影响全局这样坚持两三周你会自然形成“先看线程再看视图最后看日志”的排查路径。8.2 团队转型建议如果你是团队里的 Oracle DBA建议不要一个人埋头学而是把“进程模型变化”作为组内培训的第一讲。很多团队在迁移 OceanBase 时第一件事是培训 SQL 语法差异结果真正上线后DBA 面对异常无从下手。更好的顺序是先讲架构单进程多线程、租户隔离、多副本选举再学连接和基本操作observer、2881/2882 端口、obclient然后学监控排查top -H、V$SESSION、observer.log、合并监控最后处理 SQL 兼容性与业务改造。如果你是从 Oracle 11g、12c 等老版本转过来建议把 Oracle 的架构教科书暂时放一放不要抱着“Oracle 和 OceanBase 用法差不多”的想法。兼容性可以加速你的上手速度但架构认知必须重新建立。8.3 最后说几句说了这么多其实最核心的就是一句话Oracle DBA 转型 OceanBase不是学一个新软件而是重建一套“数据库在操作系统里怎么组织”的心智模型。多进程 vs 单进程多线程表面看只是进程数量的差异实际上决定了你查日志的方式、看监控的方式、做性能分析的方式甚至决定你在生产故障时敢不敢动手、从哪一步开始动手。如果你现在正准备转 OceanBase或已经在迁移过程中遇到了困惑可以从最简单的环境开始安装一个单机版 observerps -ef看进程top -H看线程自己执行几条 SQL再在 observer.log 里找到刚才的请求记录。把这一套闭环走通你对“忘掉多进程”这句话就会有非常具体的理解。用最小环境去安全地犯错、去熟悉线程模型比直接在生产环境踩坑要划算得多。这也是我从 Oracle 思维切换到 OceanBase 过程中最受用的一条经验。