Oracle 后台进程详解

适用版本：Oracle Database 19c / 23ai 阅读基础：了解 SGA / PGA 内存结构文档版本：v1.0 / 2026-07

1. 概述：为什么 Oracle 用多进程模型

Oracle 在 Linux/Unix 上采用多进程架构（Multi-Process Architecture），每个后台功能由独立的 OS 进程实现。这与 MySQL / PostgreSQL 的多线程模型有显著差异[1][4]。

多进程模型的优劣：

维度	多进程（Oracle）	多线程（MySQL/PG）
进程隔离	强，单进程崩溃不影响其他	弱，线程崩溃可能拖垮整个实例
IPC 通信	共享内存（SGA），需要同步	线程内直接访问，开销小
资源消耗	每连接一个 PGA，内存占用高	线程栈小，连接成本低
CPU 利用	多进程天然多核	需协调线程调度
故障诊断	进程独立 trace 文件，易定位	全栈 trace，杂糅
单实例连接数	数千（专用服务器）/ 数万（共享服务器）	数万到十万

核心思想：通过 SGA 共享内存 + 多进程协作，在保证 ACID 与高隔离的前提下提升性能。

Oracle 设计的四大哲学[5]：

内存优先：所有数据操作先在 SGA 完成，避免直接磁盘 I/O
日志先行（WAL）：数据修改前必须先写 redo log
批量异步：将随机 I/O 转化为顺序 I/O + 批量写入（DBWn/LGWR/ARCn 都是异步）
一致性兜底：多进程协同保证 ACID

2. Oracle 进程分类

┌─────────────────────────────────────────────────────┐
│             Oracle Instance Processes                │
├─────────────────────────────────────────────────────┤
│  1. User Process（用户进程）                        │
│     - 客户端应用程序进程（sqlplus/JDBC/SQL Developer）│
│     - 位于客户端或应用服务器                          │
├─────────────────────────────────────────────────────┤
│  2. Server Process（服务器进程）                    │
│     - 专用服务器：一个会话对应一个 server process    │
│     - 共享服务器：多个会话复用 server process 池     │
│     - 解析 SQL、读取数据块、返回结果                 │
├─────────────────────────────────────────────────────┤
│  3. Background Process（后台进程）                  │
│     - 必需：SMON/PMON/DBWn/LGWR/CKPT                │
│     - 可选：ARCn/MMON/RECO/CJQn/DBRM/DIAG 等        │
│     - RAC 特有：LMSn/LMD/LMON/LCK0                  │
└─────────────────────────────────────────────────────┘

查看所有后台进程：

-- 查看实例后台进程
SELECT pname, description
FROM v$bgprocess
WHERE pname IS NOT NULL
ORDER BY pname;

-- 查看进程对应的 OS PID
SELECT p.pname, p.spid, p.program, b.description
FROM v$process p, v$bgprocess b
WHERE p.addr = b.paddr
  AND p.pname IS NOT NULL
ORDER BY p.pname;

-- Linux 下查看 oracle 后台进程
ps -ef | grep ora_ | grep -v grep

典型输出：

oracle  1234  1  0  Jul15  ?  00:00:12 ora_pmon_orcl
oracle  1236  1  0  Jul15  ?  00:00:08 ora_vktm_orcl
oracle  1238  1  0  Jul15  ?  00:00:05 ora_gen0_orcl
oracle  1240  1  0  Jul15  ?  00:00:03 ora_mman_orcl
oracle  1242  1  0  Jul15  ?  00:00:07 ora_diag_orcl
oracle  1244  1  0  Jul15  ?  00:00:09 ora_dbrm_orcl
oracle  1246  1  0  Jul15  ?  00:00:06 ora_dia0_orcl
oracle  1248  1  0  Jul15  ?  00:00:11 ora_dbw0_orcl
oracle  1250  1  0  Jul15  ?  00:00:08 ora_lgwr_orcl
oracle  1252  1  0  Jul15  ?  00:00:05 ora_ckpt_orcl
oracle  1254  1  0  Jul15  ?  00:00:07 ora_smon_orcl
oracle  1256  1  0  Jul15  ?  00:00:04 ora_reco_orcl
oracle  1258  1  0  Jul15  ?  00:00:09 ora_mmon_orcl
oracle  1260  1  0  Jul15  ?  00:00:06 ora_mmnl_orcl

进程命名规则：ora_<进程名>_<SID>，如 ora_pmon_orcl 即 SID 为 orcl 的 PMON 进程。

3. 五大核心后台进程

3.1 SMON 系统监视器

全称：System Monitor[1][3]

核心职责：

3.1.1 实例恢复（Crash Recovery）

实例崩溃后重新启动时，SMON 自动执行恢复：

崩溃前 SCN=1000（已提交事务）
       SCN=1005（未提交事务在 Undo 中）
       SCN=1010（最新检查点 SCN，已被 CKPT 写入控制文件）
       
崩溃！

重启 → SMON 接管：
  1. 前滚（Roll Forward）：
     - 从控制文件读取最新检查点 RBA（Redo Byte Address）
     - 重放 redo log 中所有 SCN > 1000 的 redo entry
     - 包括已提交和未提交的事务
     - 此时数据文件同时包含已提交和未提交的修改
  
  2. 打开数据库（OPEN 状态，允许用户连接）
  
  3. 回滚（Roll Back）：
     - 利用 Undo 表空间中的前镜像
     - 回滚所有未提交的事务
     - 使用 SMON 后台进程异步执行，不阻塞用户

关键点：先开库后回滚，保证用户尽快访问数据库，未提交事务的回滚在后台异步进行。

3.1.2 临时段清理

回收临时表空间中的临时段（如排序操作异常终止遗留的段）[3]。

3.1.3 空间合并（Free Space Coalescing）

在字典管理表空间（DMT）中合并相邻的空闲区。本地管理表空间（LMT）不需要此操作。

3.1.4 触发机制

实例启动时自动唤醒
每隔约 5 分钟自动唤醒一次
其他进程可主动唤醒（通过 wait event 通知）

3.2 PMON 进程监视器

全称：Process Monitor[1][3]

核心职责：

3.2.1 异常进程清理

当用户进程异常终止（如客户端崩溃、网络中断、kill -9）时，PMON 负责：

检测 dead 进程
回滚该进程未提交的事务（用 Undo 数据）
释放该进程持有的所有资源：
- 锁（TX/TM 锁）
- Latch
- PGA 内存
- 回滚段
终止对应的服务器进程

3.2.2 监听器动态注册

PMON 定期将实例信息（服务名、实例状态）注册到监听器，使监听器能转发客户端连接[3]。

坑 1：监听器无法连接新会话，常见原因是 PMON 未注册。可用 lsnrctl services 查看注册状态：

lsnrctl services

# 若服务列表为空，强制注册
SQL> ALTER SYSTEM REGISTER;

3.2.3 触发机制

每 3 秒自动唤醒一次
其他进程可主动唤醒

3.3 DBWn 数据库写进程

全称：Database Writer[1][3]

核心职责：将 Buffer Cache 中的脏块（dirty buffer）写入磁盘数据文件，释放 Buffer Cache 空间。

进程数量：

-- 查看当前 DBWn 数量
SHOW PARAMETER db_writer_processes

-- 配置多 DBWn（CPU 核数较多时）
ALTER SYSTEM SET db_writer_processes = 4 SCOPE=SPFILE;
-- 重启生效

触发条件[3][4]：

CKPT 发出检查点指令（最常见）
dirty list 达到阈值（40% of buffer cache）
服务器进程在 LRU 链表搜索超过阈值未找到 free buffer
每 3 秒自动唤醒
表空间 offline / read only / begin backup
表空间 drop / truncate 表
实例正常 shutdown

关键规则：WAL（Write-Ahead Logging）[5]

DBWn 在写脏块前，必须确保该脏块对应的 redo entry 已被 LGWR 写入 redo log file。否则 DBWn 会先通知 LGWR 写日志，再写数据。

为什么有多个 DBWn？

单 DBWn 在大量写场景下会成为瓶颈
多 DBWn 并发写不同数据文件，提升 I/O 并行度
一般推荐 DB_WRITER_PROCESSES = min(CPU 核数, 8)

坑 2：DBWn 写入过慢会导致 Buffer Cache Free 不足

现象：free buffer waits 等待事件高。

可能原因：

磁盘 I/O 慢
DBWn 数量不够
Buffer Cache 过大但 DBWn 跟不上

解决：

-- 1. 增加 DBWn
ALTER SYSTEM SET db_writer_processes = 4 SCOPE=SPFILE;

-- 2. 启用异步 IO
SHOW PARAMETER disk_asynch_io  -- 应为 TRUE

-- 3. 调整 FAST_START_MTTR_TARGET（缩短检查点间隔）
ALTER SYSTEM SET fast_start_mttr_target = 300;  -- 5 分钟

3.4 LGWR 日志写进程

全称：Log Writer[1][3]

核心职责：将 Redo Log Buffer 中的 redo entries 写入在线 redo log file。Oracle 最繁忙的进程。

触发条件[3][5]：

用户提交（COMMIT）
- 提交时 redo buffer 中相关记录必须立即写盘
- 这是 commit 慢的主要原因（产生 log file sync 等待）
每 3 秒自动唤醒
Redo Log Buffer 1/3 满（默认 14 MB → 约 5 MB）
Redo Log Buffer 中未写入数据达 1 MB
DBWn 请求：DBWn 写脏块前会通知 LGWR 先写对应 redo
日志切换（Log Switch）

写入方式：

顺序写：写入当前 redo log group 的所有 member（多路复用）
同步写：commit 时必须等 LGWR 写完磁盘才能返回成功
单进程：每个实例只有 1 个 LGWR（不能配置多个）

Fast Commit 机制[5]：

用户 commit →
  LGWR 把 redo buffer 中该事务的 redo entry 写入 redo log file →
  通知用户 commit 完成 →
  DBWn 异步写脏块（不阻塞用户）

坑 3：log file sync 等待高

最常见的性能问题之一，原因：

磁盘 I/O 慢（redo log 文件放在慢盘上）
Redo Log Buffer 太小
提交过于频繁（每行 commit 一次）
Redo log file 太小导致频繁 log switch

解决：

-- 1. Redo log 文件放高速磁盘（SSD/NVMe）
-- 2. 增大 Redo Log Buffer
ALTER SYSTEM SET log_buffer = 134217728 SCOPE=SPFILE;  -- 128 MB

-- 3. 增大 redo log file（减少 log switch 频率）
-- 查看当前 redo log 切换频率
SELECT 
  TO_CHAR(first_time, 'YYYY-MM-DD') AS day,
  COUNT(*) AS switches
FROM v$log_history
WHERE first_time > SYSDATE - 7
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD')
ORDER BY day;
-- 目标：每小时 < 1 次切换

-- 4. 应用层：批量提交而非逐行提交

3.5 CKPT 检查点进程

全称：Checkpoint[1][3]

核心职责：

触发检查点事件：通知 DBWn 将脏块写盘
更新控制文件和数据文件头：写入最新检查点 SCN 和 RBA

检查点的意义：

保证数据一致性：检查点后数据文件与内存一致
缩短实例恢复时间：恢复只需重放检查点之后的 redo
同步 RBA：记录”恢复起点”

触发条件[3]：

日志切换（Log Switch）
实例正常关闭（shutdown immediate / normal / transactional）
FAST_START_MTTR_TARGET 达成（自动检查点）
手动触发：ALTER SYSTEM CHECKPOINT
表空间 offline / begin backup / datafile offline

检查点类型：

类型	触发	范围
Full Checkpoint	shutdown、log switch	所有数据文件
Partial Checkpoint	tablespace offline	该表空间数据文件
File Checkpoint	datafile offline	单个数据文件
Incremental Checkpoint	FAST_START_MTTR_TARGET	自上次以来的增量
Thread Checkpoint	RAC 中 thread 切换	该 thread 的 redo

关键参数：

-- 目标 MTTR（Mean Time To Recover），单位秒
ALTER SYSTEM SET fast_start_mttr_target = 300;  -- 5 分钟
-- 设置后 Oracle 自动控制检查点频率，使实例恢复时间 < 5 分钟

-- 查看 MTTR 顾问
SELECT mttr_target_for_estimate, estd_total_filesize, estd_total_ios
FROM v$mttr_target_advice;

坑 4：MTTR 设置过短会导致频繁检查点

FAST_START_MTTR_TARGET = 60 会让 DBWn 拼命写脏块，导致 I/O 瓶颈。生产推荐 300-900 秒。

4. 可选与辅助后台进程

4.1 ARCn 归档进程

全称：Archiver[1][3]

核心职责：当归档模式启用时，将写满的在线 redo log 复制到归档目录。

进程数量：

SHOW PARAMETER log_archive_max_processes
ALTER SYSTEM SET log_archive_max_processes = 4;

触发条件：日志切换时被 LGWR 唤醒。

坑 5：归档跟不上导致数据库 hang

现象：alert log 报 ORA-00257: archiver error，所有 DML 阻塞。

原因：

归档目录满
归档进程数不足
归档目标盘 I/O 慢

解决：

# 1. 检查归档目录空间
df -h /archivelog

# 2. 增加归档进程
ALTER SYSTEM SET log_archive_max_processes = 8;

# 3. 紧急删除已备份的归档
RMAN> crosscheck archivelog all;
RMAN> delete noprompt expired archivelog all;
RMAN> delete noprompt archivelog all completed before 'sysdate-7';

4.2 MMON / MMNL 与 AWR

MMON（Manageability Monitor）[3]：

每小时自动收集 AWR 快照
写入 SYSAUX 表空间的 WRH$_* 表
触发 server-generated alert（如 tablespace full）

MMNL（Manageability Monitor Light）：

实时收集 ASH 采样数据
写入 V$ACTIVE_SESSION_HISTORY
每秒采样一次活跃会话

查看 AWR 快照：

SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
ORDER BY snap_id DESC
FETCH FIRST 10 ROWS ONLY;

4.3 RECO 分布式事务恢复

全称：Recoverer[1]

职责：自动解决分布式事务的 in-doubt 状态。

当分布式事务（跨多个数据库）部分节点 commit 成功、部分失败时，RECO 定期与各节点通信，最终统一 commit 或 rollback。

-- 查看 in-doubt 事务
SELECT * FROM dba_2pc_pending;

4.4 CJQn / Jnnn 作业调度

CJQn（Job Queue Coordinator）：

协调 job 的执行
启动 Jnnn 进程执行具体 job

SHOW PARAMETER job_queue_processes
ALTER SYSTEM SET job_queue_processes = 20;

-- 查看运行中的 job
SELECT job, last_date, this_date, next_date, what
FROM dba_jobs_running;

4.5 DBRM 资源管理

DBRM（Database Resource Manager）：

实施资源计划（Resource Plan）
限制不同 consumer group 的 CPU / PGA / 活动会话数

4.6 DIAG 诊断进程

DIAG（Diagnosability）：

捕获实例错误（ORA-00600 / ORA-07445）
写入 ADR（Automatic Diagnostic Repository）
生成 incident 包

4.7 FBDA Flashback Data Archive

FBDA：

后台进程，负责将受保护表的历史数据写入 flashback archive
18c 起支持 DDL 兼容（修改表结构时仍保留历史）

5. RAC 特有后台进程

5.1 LMSn 全局缓存服务

全称：Lock Manager Server[3]

职责：

处理 GCS（Global Cache Service）消息
在 RAC 节点间传输数据块
是 RAC 性能最关键的进程

通常每个节点有多个 LMS 进程：

SHOW PARAMETER gcs_server_processes
-- 默认 = min(CPU 核数, 4)

5.2 LMD 全局队列服务

职责：

管理 GES（Global Enqueue Service）
处理全局锁请求（如 TM 锁、Library Cache Lock）
协调队列资源

5.3 LMON 全局队列监视

职责：

监控 RAC 集群节点状态
处理节点加入/离开
触发集群重新配置

5.4 LCK0 全局锁

职责：

管理非 cache 资源的全局锁
如 library cache / row cache 的全局锁

6. 进程协同：一次 UPDATE 的完整流程

参考[5]中的案例。以下是一条 UPDATE 语句的完整生命周期：

UPDATE orders SET status = 'PAID' WHERE order_id = '20260424001';

步骤 1：连接建立

客户端 → TCP → Listener（监听 1521）
Listener 验证身份 → fork Server Process
Server Process 分配 PGA
返回连接成功

涉及组件：Listener、PMON（已注册服务）、Server Process、PGA

步骤 2：SQL 解析

Server Process 接收 SQL →
  1. 语法检查 → 通过
  2. 语义检查 → 查 Data Dictionary Cache（在 Shared Pool）
  3. Shared Pool 检查 → 查 Library Cache 是否有相同 cursor
     - Hit：软解析，复用执行计划
     - Miss：硬解析，生成执行计划
  4. 计算 hash value，存入 Library Cache

涉及组件：Server Process、Shared Pool（Library Cache + Row Cache）

步骤 3：数据读取

Server Process 根据执行计划访问数据：
  - 通过索引/全表扫描定位行
  - 先查 Buffer Cache → Hit 直接读
  - Miss → 从数据文件读入 Buffer Cache（产生 db file sequential read）

涉及组件：Buffer Cache、Server Process

步骤 4：数据修改（关键）

Server Process 在 Buffer Cache 中修改数据块：
  1. 该 buffer 标记为 dirty
  2. 在 Undo 表空间生成前镜像（用于回滚和读一致性）
     - Undo 块也在 Buffer Cache
     - Undo 块也标记为 dirty
  3. 生成 redo entry 写入 Redo Log Buffer：
     - 修改数据块的 redo
     - 修改 Undo 块的 redo

涉及组件：Buffer Cache、Redo Log Buffer、Undo Segment

步骤 5：用户 COMMIT

用户发出 COMMIT：
  1. Server Process 通知 LGWR
  2. LGWR 将 Redo Log Buffer 中相关 redo entry 写入 online redo log file
     - 同步写（等待磁盘确认）
  3. LGWR 通知 Server Process：写入完成
  4. Server Process 返回用户：commit complete
  5. 释放 TX 锁、释放 Undo 资源（延迟）

涉及组件：LGWR、Redo Log File、PMON（如会话异常）

关键点：commit 时数据还没写到数据文件！只写了 redo log。脏块在 Buffer Cache 中等待 DBWn 异步写入。

步骤 6：DBWn 异步写脏块

触发条件（任一）：
  - dirty list 达到阈值
  - 检查点触发
  - LRU 搜索超阈值

DBWn 流程：
  1. 检查脏块对应的 redo 是否已写入 redo log file
     - 否：通知 LGWR 先写
     - 是：继续
  2. 将脏块批量写入数据文件
  3. 释放 Buffer Cache 空间

涉及组件：DBWn、CKPT（可能触发）、Data File

步骤 7：检查点（CKPT）

触发条件（任一）：
  - 日志切换
  - 实例正常关闭
  - FAST_START_MTTR_TARGET 达成

CKPT 流程：
  1. 通知 DBWn 写所有脏块
  2. 更新控制文件：写入最新检查点 SCN 和 RBA
  3. 更新数据文件头：写入 SCN

涉及组件：CKPT、DBWn、Control File、Data File Header

步骤 8：归档（ARCn）

日志切换时：
  1. LGWR 切换到下一个 redo log group
  2. ARCn 被唤醒，复制写满的 redo log file 到归档目录
  3. 归档完成后该 redo log file 可被覆盖

涉及组件：ARCn、Archive Log File

7. 进程监控与诊断

7.1 进程状态查看

-- 所有后台进程
SELECT pname, spid, username, program, pga_used_mem/1024/1024 AS "PGA(MB)"
FROM v$process p, v$bgprocess b
WHERE p.addr = b.paddr
  AND p.pname IS NOT NULL
ORDER BY p.pname;

-- 服务器进程
SELECT spid, program, pga_used_mem/1024/1024 AS "PGA(MB)", traceid
FROM v$process
WHERE background IS NULL
ORDER BY pga_used_mem DESC;

-- 会话对应的进程
SELECT s.sid, s.serial#, s.username, s.program, p.spid, p.pname
FROM v$session s, v$process p
WHERE s.paddr = p.addr
ORDER BY s.sid;

7.2 等待事件查看

-- Top 10 等待事件
SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE wait_class != 'Idle'
ORDER BY time_waited DESC
FETCH FIRST 10 ROWS ONLY;

-- 进程级等待
SELECT s.sid, s.username, w.event, w.wait_time, w.seconds_in_wait
FROM v$session s, v$session_wait w
WHERE s.sid = w.sid
  AND w.event NOT LIKE '%SQL*Net%'
ORDER BY w.seconds_in_wait DESC;

7.3 进程 trace

-- 启用进程级 SQL Trace
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(sid => 123, serial => 456, waits => TRUE, binds => TRUE);

-- 停止
EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(sid => 123, serial => 456);

-- trace 文件位置
SELECT value FROM v$diag_info WHERE name = 'Diag Trace';

7.4 关键诊断视图

视图	用途
`V$PROCESS`	OS 进程信息
`V$BGPROCESS`	后台进程列表
`V$SESSION`	会话信息
`V$SESSION_WAIT`	实时会话等待
`V$SESSION_EVENT`	会话历史等待统计
`V$SYSTEM_EVENT`	系统级等待统计
`V$WAITCLASSMETRIC`	等待类指标
`V$DIAG_INFO`	诊断文件位置

8. 常见坑与最佳实践

坑 1：DBWn 配置过少

现象：free buffer waits 高、write complete waits 高。

诊断：

SELECT event, total_waits, time_waited
FROM v$system_event
WHERE event IN ('free buffer waits', 'write complete waits');

解决：

ALTER SYSTEM SET db_writer_processes = 4 SCOPE=SPFILE;
-- 重启生效。建议 = min(CPU 核数, 8)

坑 2：log file sync 等待过高

现象：应用响应慢，AWR 显示 log file sync 是 Top 等待。

诊断：

-- 比较 log file sync 和 log file parallel write 的平均等待时间
SELECT event, total_waits, time_waited, average_wait
FROM v$system_event
WHERE event IN ('log file sync', 'log file parallel write');

如果 log file parallel write 也很慢 → 磁盘 I/O 问题
如果 log file parallel write 不慢 → 应用提交过于频繁

解决：

原因	方案
磁盘慢	Redo log 放 SSD/NVMe
Redo log file 太小	增大到每 30 分钟切换一次
Redo Log Buffer 太小	`LOG_BUFFER = 128M+`
应用过度 commit	改为批量 commit
Redo log 与数据文件同盘	物理分离

坑 3：归档目录满导致 hang

现象：DML 完全无法执行，alert log 报 ORA-00257。

解决：

# 1. 紧急清理
rman target /
RMAN> crosscheck archivelog all;
RMAN> delete noprompt archivelog all completed before 'sysdate-3';

# 2. 增加归档进程
SQL> ALTER SYSTEM SET log_archive_max_processes = 8;

# 3. 增加归档目录空间或挂载新盘

坑 4：PMON 未注册监听器

现象：新连接报 ORA-12514: TNS:listener does not currently know of service requested。

解决：

-- 1. 查看 PMON 注册情况
lsnrctl services

-- 2. 强制立即注册
ALTER SYSTEM REGISTER;

-- 3. 检查 LOCAL_LISTENER 参数
SHOW PARAMETER local_listener
-- 若使用非默认端口，需配置 LOCAL_LISTENER 指向监听器

坑 5：异常 kill 进程导致 SMON 忙

现象：-9 杀掉大量会话后，SMON 占用 CPU 高。

原因：SMON 在回滚所有未提交事务，回滚慢可能持续数小时。

解决：

-- 加速回滚
ALTER SYSTEM SET fast_start_parallel_rollback = HIGH;

-- 监控回滚进度
SELECT usn, state, undoblocksdone, undoblockstotal
FROM v$fast_start_transactions;

最佳实践总结

DBWn 数量 = min(CPU 核数, 8)
归档进程 ≥ 4，高写入场景 ≥ 8
Redo Log File 大小确保每 30 分钟切换一次
Redo Log Buffer ≥ 64 MB
FAST_START_MTTR_TARGET = 300-900 秒
生产启用归档模式，必须有完整备份策略
Redo log 文件放高速盘，与数据文件物理分离
多路复用 redo log（每组至少 2 个 member，不同磁盘）
监控 alert log，关注 ORA-00600 / ORA-07445 错误
不要 kill -9 oracle 进程，用 ALTER SYSTEM KILL SESSION

9. 参考资料

[1] Oracle Database 19c 概念文档，第 15 章 Process Architecture： https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/process-architecture.html

[2] Oracle Database 19c Administrator’s Guide，后台进程管理： https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/

[3] 百分，《Oracle 数据库后台进程详解》，墨天轮： https://www.modb.pro/db/1734595646039597056

[4] 周同学带您玩 AI，《解析 Oracle 数据库架构：实例、内存和进程的完美结合》，墨天轮： https://www.modb.pro/db/1822855013329285120

[5] 尚雷，《从电商订单支付更新，吃透 Oracle 数据修改的底层设计哲学与全组件协同原理》，墨天轮： https://www.modb.pro/db/2047626878333313024

[6] 暮雨，《Oracle 数据库体系结构的综合架构》，墨天轮： https://www.modb.pro/db/1962805535552581632

[7] Oracle Database Reference 19c，V$ 视图参考： https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/

相关文章

SMON 系统监视进程职责详解

DBWn 数据库写进程与 Checkpoint

LGWR 日志写进程与日志切换

ARCn 归档进程与归档日志

MMON/MMNL 与 AWR 自动工作负载仓库

RAC 后台进程（LMS/LMD/LMON/LCK）