企业官网建设流程全解析

先说一个真实场景：一个 Oracle DBA 第一次拿到 OceanBase 环境，习惯性敲下ps -ef | grep -i oracle，结果屏幕上除了 grep 本身什么都搜不到。第一反应是“是不是没装上”，第二反应是“是不是崩了”。实际上服务跑得好好的，只是这台机器上已经没有一个叫oracle的进程了。如果你也有过类似经历，或者正准备从 Oracle 体系迁移到 OceanBase，这篇内容建议先收藏。它的核心就一句话：把“多进程”这个思维惯性忘掉，OceanBase 用的是单进程多线程架构。

这个差异不是概念层面的，它会直接影响你的日常巡检方式、故障排查路径、性能诊断习惯，甚至影响你对“数据库是不是正常”的判断。比如在 Oracle 里，pmon挂了会有人紧张，smon异常会有人看日志，进程数量对不上就要查是不是PMON退出。但在 OceanBase 里，没有pmon/smon/dbwr/lgwr/ckpt这组进程，只有一个observer主进程和若干周边进程。再看ps的时候，判断依据完全变了。这不是说 Oracle 的判断方法错了，而是说 OceanBase 的进程模型本来就不是按 Oracle 的思路设计的。

本文会从架构差异、进程排查、资源管理、性能诊断、安装部署这几个方面拆开讲，最后给出一份 Oracle DBA 转 OceanBase 初期的避坑清单。文章里的命令和示例，都按常见部署环境做了通用化处理，具体路径和版本信息以你本机环境为准。

1. 核心能力速览

先给一张“架构对照速览表”，把 Oracle 和 OceanBase 最关键的差异列出来。这张表不是为了全面对比两款数据库，而是聚焦在“为什么不能沿用多进程思维”这件事上。

从这张表能看出，OceanBase 并不是把 Oracle 的进程拆成不同名字，而是从底层换了一套运行模型。所以 Oracle DBA 转型时，第一步不是去记新进程名，而是先接受“进程维度”已经不是首要排查维度这件事。

2. 架构思维转换：为什么 OceanBase 没有“多进程”

Oracle 用多进程，本质上是把数据库的不同职责拆给不同进程，比如日志写入专门由 LGWR 负责，数据文件写入由 DBWR 负责，实例异常监控由 PMON 负责。这带来的好处是职责清晰，出了问题可以盯着某个进程查；坏处是进程间通信开销大，内存共享要特别小心，遇到异常退出还要处理进程级故障恢复。

OceanBase 的选择是单进程多线程。一个observer进程内部包含了网络处理、SQL 引擎、事务引擎、存储引擎、日志模块等所有核心组件，不同模块用线程来并发。这样做的好处是线程共享进程内存，通信成本低，也能更灵活地控制连接数、CPU 时间片和内存边界。代价是——你以前那套“ps看进程”的方法，在 OceanBase 上基本失效了一半。

用一条命令来看：

ps -ef | grep observer

典型的输出是：

root 12345 1 0 10:00 ? 00:00:00 /home/admin/oceanbase/bin/observer

只有一个 observer 进程。如果你再数一下它内部的线程数，会发现数量多到让你怀疑人生：

# 找到 observer 的 PID 后，按线程统计 ps -eLf | grep 12345 | wc -l

在负载正常的节点上，observer 的线程数达到几百个是常见情况。线程分别负责网络 IO、SQL 处理、事务提交、clog 落盘、合并压缩、后台巡检等。想再细看线程级别，可以用top -Hp <pid>，或者用pidstat -t -p <pid>按线程观察 CPU 使用。这一步和 Oracle 上ps -L看线程的思路类似，但观察对象从“多个进程”变成了“一个进程下的多个线程”。

所以，架构思维的转变可以浓缩成三点：

1. 巡检时不再问“这个进程还在不在”，而是问“observer 是否存活、内部关键线程是否正常、租户资源是否健康”。
2. 排查异常时不再按“哪个进程出问题”分线索，而是按“哪个模块出问题”分线索，比如网络模块、SQL 模块、事务模块、存储模块。
3. 杀进程、重启服务时不再有“先杀 PMON 还是先杀 SMON”这种操作，而是按集群运维规范统一启停。

3. 进程与线程排查：日常运维操作差异

Oracle DBA 最熟的运维动作，在 OceanBase 里多半要换个做法。下面挑几个高频场景对比。

3.1 查看实例是否活着

Oracle 一般先ps -ef | grep pmon，如果 pmon 在，再sqlplus / as sysdba看实例状态。OceanBase 的对应操作更简单，但也有讲究：

# 检查 observer 进程是否存在 ps -ef | grep observer # 连接 observer 本机 SQL 端口，执行系统租户查询 obclient -h127.0.0.1 -P2881 -uroot@sys -p -A

登录到 sys 租户后，可以检查集群状态：

SELECT * FROM GV$OB_SERVERS;

这个视图会返回每个 observer 节点的状态、CPU 容量、内存容量、磁盘使用情况。只要这里能看到节点，进程层面那份ps只是参考，不用太较真。

3.2 观察线程使用

在 Oracle 里，遇到性能问题会ps -ef | grep ora_看看哪个后台进程 CPU 高。在 OceanBase 里，重点是看 observer 进程内部哪些线程在消耗 CPU：

# 按 CPU 排序看 observer 的线程 top -H -p $(pgrep -f "observer" | head -1)

进去后按大写P排序，就能看到线程名和 CPU 占用。常见线程名包括Tsys、TMySQL、Txn、Clog、Merge等，具体名字在不同版本里会有差异。通过线程名可以大致判断瓶颈在网络、事务还是合并任务。

3.3 重启和停止服务

Oracle 用sqlplus执行shutdown immediate，OceanBase 的常规方式是用 OBD 或 OCP 操作，也可以在系统租户里执行ALTER SYSTEM STOP SERVER或SHUTDOWN，但生产环境推荐走管控平台或 OBD：

# 停止整个集群（以 OBD 部署为例） obd cluster stop <部署名> # 启动整个集群 obd cluster start <部署名>

这里要特别提醒：不要在生产环境随意kill -9observer 进程。observer 内部有大量状态在内存里，强杀可能导致异常恢复流程、回放日志或者触发副本重新选择。日志模块有自己的落盘机制，但 “observer 可以随便杀” 是一个错误的观念。正常操作应该用kill（不带 -9）触发优雅退出，或在管控层执行标准停止命令。

3.4 查看运行日志

Oracle 的告警日志路径一般叫alert_<sid>.log，OceanBase 的日志目录和文件命名不同。默认情况下，observer 日志在~/store/log或logs目录下：

• observer.log：主服务日志
• rootservice.log：RootService 相关日志
• election.log：选举相关日志
• clog相关日志可能在独立目录

日常排查先看observer.log，用grep按关键字和日志级别过滤：

cd /home/admin/oceanbase/log grep -i -E "error|warn" observer.log | tail -n 100

日志格式通常包含时间、模块、线程号、级别、日志内容等字段。排查的时候先定位时间段，再按WARN和ERROR级别过滤，效率更高。

4. 资源管理：从 SGA/PGA 到租户资源单元

Oracle 的内存用 SGA 和 PGA 区分，DBA 很习惯调shared_pool_size、db_cache_size、pga_aggregate_target这类参数。OceanBase 不是这个思路，它把资源管理的核心单位改成了“租户”，租户资源由资源单元（UNIT）定义。

一个租户会占用一组 CPU 和内存配额，资源单元在创建时指定min_cpu、max_cpu、memory_size等参数。同一个 OB 集群里可以有多个租户，租户之间通过资源单元的配额做隔离。所以你在 OceanBase 里查内存，不是在查“共享池还有多少”，而是查“租户资源是否够用”、“内存是否触达上限”。

常用检查语句如下：

-- 查看集群资源池分布 SELECT * FROM DBA_OB_RESOURCE_POOLS; -- 查看租户的资源单元配置 SELECT * FROM DBA_OB_UNIT_CONFIGS; -- 查看租户内存使用情况 SELECT * FROM GV$OB_MEMORY WHERE TENANT_ID = <租户ID>;

这里和 Oracle DBA 直觉最大的冲突点在于：Oracle 多数情况下是“按实例全局配置资源”，OceanBase 是“按租户维度切分资源”。一个节点如果跑多个租户，CPU 和内存是提前通过资源单元划定的，不像 Oracle 的 SGA 里各组件可以动态竞争。所以做容量规划时，要先把租户的memory_size规划好，而不是上线后才发现内存不够。

CPU 方面，OceanBase 的min_cpu和max_cpu配合调度器，控制租户能使用的 CPU 上限。判断租户 CPU 是否打满，可以看GV$OB_SERVERS里的 CPU 容量和当前使用数据，或者结合 OCP 监控看。对于 Oracle DBA，比较容易理解的类比是：max_cpu像cpu_count和资源管理器配合起来的效果，memory_size像SGA_TARGET+PGA_AGGREGATE_TARGET的组合，但实现方式完全不同。

磁盘方面，Oracle 有表空间、数据文件、临时表空间，OceanBase 有数据文件（sstable）、clog 日志等。磁盘空间规划时，要同时关注数据存储、clog、日志文件以及合并带来的临时空间需求。

5. 性能诊断：从 v$session 到 GV$OB_* 视图

Oracle DBA 做性能诊断基本绕不开v$session、v$sql、v$active_session_history这一组动态性能视图。OceanBase 有对应的视图体系，名字有一定相似性，但使用方式要重新熟悉。

5.1 查当前会话和并发

Oracle 看v$session，OceanBase 看GV$OB_PROCESSLIST：

-- 查看当前租户活跃会话 SELECT * FROM GV$OB_PROCESSLIST WHERE STATE = 'ACTIVE';

这个视图能看客户端 IP、端口、SQL ID、事务状态、会话状态等信息。排查“哪个会话卡住了”，先从这里定位TRACE_ID和 SQL ID，再往 SQL 审计视图查。

5.2 查 SQL 执行历史

SQL 性能问题建议直接看审计视图：

-- 最近慢 SQL SELECT * FROM GV$OB_SQL_AUDIT WHERE ELAPSED_TIME > 1000000 ORDER BY REQUEST_TIME DESC LIMIT 50;

ELAPSED_TIME的单位是微秒，要注意换算。Oracle 中v$sql主要看累计统计，OceanBase 的GV$OB_SQL_AUDIT偏向每次执行的审计记录，按时间范围捞慢 SQL 更方便。拿一条 SQL 的TRACE_ID，可以串起一次请求在 observer 内部各个模块的执行记录，这有点像 Oracle 里用 SQL 的SQL_ID去查v$sql_plan和v$sql_monitor的组合，但追踪粒度更细。

5.3 查执行计划

OceanBase 查看执行计划有专门的接口：

-- 查看某条 SQL 的执行计划 EXPLAIN SELECT * FROM T1 WHERE ID = 1; -- 通过 SQL 审计视图拿到 plan id 后，查看对应计划 SELECT * FROM GV$OB_SQL_PLAN WHERE PLAN_ID = <plan_id>;

要注意，OceanBase 的执行计划里会出现 “表扫描”、“聚合”、“NESTED-LOOP JOIN”、“HASH JOIN” 这些算子，和 Oracle 的TABLE ACCESS BY INDEX ROWID、NESTED LOOPS概念很像，但算子命名和细节不完全一致。Oracle DBA 需要适应的是：部分调优手段从“改 hint、改索引”延伸到“看分区裁剪和副本选择”，因为 OceanBase 的分布式执行计划会考虑数据分布和节点间的数据交换。

5.4 查等待事件和底层信息

Oracle 的等待事件体系非常成熟，有v$system_event、v$session_wait。OceanBase 也有等待事件相关信息，可以通过内部视图查询，但名称不同。刚上手时不用急着背事件名，先学会看三类信息：

1. 当前有没有 CPU 打满、内存触顶；
2. 慢 SQL 的执行计划是不是走了全表扫描或没切对分区；
3. 事务有没有长时间未提交，导致锁等待或 clog 压力。

判断事务冲突时，可以看GV$OB_TRANSACTION_PARTICIPANTS或通过 SQL 审计观察WAIT_CLASS、WAIT_EVENT字段。整体上，OceanBase 的性能诊断路径是：SQL 审计 → 慢 SQL → 执行计划 → 资源视图，比 Oracle 的“会话 → 等待事件 → SQL → 执行计划”更依赖 SQL 审计层的数据。

6. 安装部署体验：从手工建库到 OBD 一键部署

Oracle 安装有多繁琐，经历过的人都知道：下载补丁、配置 grid、改内核参数、跑 DBCA、处理监听问题、设置环境变量，一个环节出错整晚就没了。OceanBase 当前的本地部署体验要轻很多，社区版常用 OBD 工具，可以在测试机上快速拉起一个集群。

以下是通用操作示例，不同版本的 OBD 和安装包路径需要按实际环境调整：

# 解压软件包（假设安装包已放置到指定目录） tar -xzf oceanbase-ce-<版本>.tar.gz # 初始化部署目录（示例路径，按实际调整） mkdir -p /data/oceanbase/{store,etc,run,log} # 使用 obd 设置部署配置 obd cluster create <部署名> -c <配置文件路径>

配置文件里要写清楚节点 IP、observer 安装路径、数据目录、SQL 端口、RPC 端口等。一个最小测试配置通常包括：

obproxy: servers: - 127.0.0.1 global: listen_port: 2883 prometheus_listen_port: 2884 home_path: /home/admin/obproxy oceanbase-ce: servers: - 127.0.0.1 global: home_path: /home/admin/oceanbase data_dir: /data/oceanbase/store log_dir: /data/oceanbase/log mysql_port: 2881 rpc_port: 2882

配置完成后启动：

obd cluster start <部署名>

然后测试连接：

obclient -h127.0.0.1 -P2881 -uroot@sys -p

连接成功后可以先执行一个基础查询，确认集群状态：

SELECT * FROM GV$OB_SERVERS;

如果是第一次体验，建议直接用 OBD 装一个单节点集群，配置两个租户：一个 sys 租户用于管理，一个业务租户用于测试。这样既能感受单进程多线程架构，也能体验租户资源隔离。

很多 Oracle DBA 会关心一个兼容性问题：PL/SQL、存储过程、包这些能不能直接用。OceanBase 的 Oracle 模式在语法兼容方面已经做了很多工作，但存储过程、包的部分行为仍有差异。真实项目迁移时，不能靠“语法看起来一样”就判定可用，要在测试环境跑一轮 PL/SQL 兼容性验证。像 Oracle 的CONNECT BY START WITH、NOT EXISTS、TRUNC(SYSDATE)这类常用写法，在 OceanBase Oracle 模式下大多有对应支持，但分层查询、正则表达式等细节仍建议逐条验证。

7. 常见误区与排查清单

Oracle DBA 刚转 OceanBase 时，出错往往不是难在 SQL，而是难在运维习惯。下面列几个高频误区。

7.1 用ps找一堆进程

最容易踩的坑。看到ps -ef | grep observer只有一个进程，就觉得“是不是失败了”。实际只要GV$OB_SERVERS里能看到节点，进程就正常。

7.2 用kill -9强杀 observer 进程

这是高危操作。非正常退出可能导致恢复时间变长，极端情况要等副本重建。正确方式是使用obd cluster stop或管控平台操作。

7.3 把租户内存当成 Oracle 的 SGA 来调

Oracle 的内存参数可以调共享池、缓冲区缓存，OceanBase 的内存主要由租户资源单元管控，调整方式不同：

-- 修改租户资源单元（示例） ALTER SYSTEM ALTER RESOURCE UNIT <unit_name> SET MAX_CPU = 4, MEMORY_SIZE = '8G';

修改前要确认集群节点剩余资源足够。这类操作在 OCP 里也有可视化界面，生产环境优先走管控平台。

7.4 主备切换和 RAC 思路混淆

Oracle 的 RAC 是共享存储多实例架构，Data Guard 是主备物理复制。OceanBase 的高可用是基于 Paxos 协议的多副本架构，同一个租户的多个副本之间是强一致的，主副本故障后会自动选主。Oracle DBA 有时会下意识把“备库”当成物理 Standby 来理解，实际上 OceanBase 的备副本同样参与一致性协议，和 Data Guard 的主备模式不是一回事。

7.5 忽略分区键对执行计划的影响

Oracle 分区表需要手工管理分区；OceanBase 对分区表的支持类似，但分区键的选择会影响分布式执行计划。如果 SQL 没有裁剪到正确的分区，可能会跨节点扫描，性能差距极大。调优时不要只加索引，先看分区键是否合理。

7.6 通过内网安全访问和端口混淆

Oracle 默认 1521，OceanBase observer 默认 2881（SQL），RPC 默认 2882，OBProxy 默认 2883。很多 DBA 第一次连不上，是因为把 2883 当成了 observer 端口直连，或者防火墙没放行 RPC 端口。排查连接问题时，先把端口层次理清楚：直连 observer 用 2881，走 OBProxy 用 2883，RPC 端口只在节点内部使用，通常不对外网开放。

8. 常见问题与排查方法

9. Oracle DBA 转 OceanBase 的最佳实践

下面给一套实用的推进路径，适合刚从 Oracle 转过来、还没摸清 OceanBase 脾气的 DBA。

先不要在生产环境直接做迁移。找一台测试机，用 OBD 部署一个单节点集群，然后跑三件事：

1. 把常用的巡检命令写成新脚本。比如把ps -ef | grep pmon改成检查observer进程 +GV$OB_SERVERS；把v$session查询改成GV$OB_PROCESSLIST；把v$sql慢 SQL 查询改成GV$OB_SQL_AUDIT。
2. 把业务侧最核心的 50 条 SQL 导到测试租户执行，记录执行计划差异。重点关注分区裁剪、连接方式、隐式类型转换。Oracle 里某些 SQL 在 OB 上可能因为统计信息不同而选择完全不同的计划。
3. 验证一套备份恢复流程。OceanBase 的物理备份、逻辑导出导入和多副本机制都要在测试环境走通，再考虑生产切换。

数据迁移建议优先考虑 OMS 或逻辑导出导入工具。Oracle 的expdp/impdp在 OceanBase 不适用，命令不同，校验方式也要重新设计。字符集、字段类型长度、约束、自增列这些都要逐项比对。

日常巡检建议用好这三个维度：

日志和监控建议统一接到 OCP 或 Prometheus + Grafana。虽然命令行能查到所有信息，但告警和历史趋势还是靠监控平台更可靠。OBProxy 也要纳入监控范围，因为用户连接走 OBProxy 时，OBProxy 本身会成为新的故障点。

如果遇到官方文档没覆盖的问题，优先去 OceanBase 社区或官方资料库搜索，不要直接用 Oracle 的故障处理思路硬套。比如“日志切换慢”在 Oracle 里是 redo 相关，在 OceanBase 里可能是 clog 落盘或磁盘 IO 问题；“锁等待”在 Oracle 里查v$lock，在 OceanBase 里要通过事务参与者视图和 SQL 审计去定位。把排查思路切换到“线程 + 视图 + 日志”三位一体，很多问题会好查很多。

最后说一个最实在的操作建议：一上来别碰 OCP 的大规模部署，先手动用 OBD 装一个节点，把 observer、OBProxy、租户、备份恢复全部走一遍。只有亲手操作过，才能真正理解单进程多线程架构和 Oracle 多进程架构的差异。等到你不再下意识执行ps -ef | grep pmon的时候，这关就算过了。