LogMiner 必须用 SYSTEM 用户或具备 SELECT_CATALOG_ROLE 和 EXECUTE_CATALOG_ROLE 权限的账号启动，因其依赖系统级字典和日志元数据访问权限；JDBC 安全读取需拼接具体 SCN 条件、设置 fetchSize、及时调用 END_LOGMNR；SQL_REDO 需正则解析表名与主键；LogMiner 不适合长期实时 CDC，建议用于批式增量快照。

LogMiner 为什么必须用 SYSTEM 用户启动

因为 oracle 的 dbms_logmnr 包底层依赖系统级字典和日志元数据访问权限，普通用户即使被授予 logminer 角色，也无法执行 add_logfile 或 start_logmnr —— 常见报错是 ora-01308: initialization parameter utl_file_dir is not set 或直接 ora-01306: dbms_logmnr.start_logmnr() must be called after dbms_logmnr.add_logfile()，但根本原因常是权限不足。jdbc 连接时，必须确保 connection 是用 system（或具备 select_catalog_role + execute_catalog_role 的等效账号）建立的。

实操建议：

• 不要在应用里硬编码 SYSTEM 密码；改用专用低权限账号，通过 GRANT SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE TO cdc_reader 授权
• 确认数据库已开启补充日志：ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;，否则 DML 的 ROWID 和列值可能缺失
• DBMS_LOGMNR.START_LOGMNR() 的 OPTIONS 参数必须包含 DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG，离线字典方式在 JDBC 动态连接场景下几乎不可靠

JDBC 怎么安全读取 LogMiner 视图结果集

Oracle 不允许在 V$LOGMNR_CONTENTS 上直接建物化视图或创建只读副本，JDBC 只能通过标准 SELECT 查询该动态性能视图。但这里有两个硬限制：一是该视图不支持绑定变量（WHERE SCN BETWEEN ? AND ? 会报 ORA-00933: SQL command not properly ended），二是结果集可能极大，一次性拉取易 OOM 或触发 Oracle 的游标超时。

实操建议：

• SQL 必须拼接具体数值条件，例如：SELECT SCN, SQL_REDO, OPERATION, TABLE_NAME FROM V$LOGMNR_CONTENTS WHERE SCN BETWEEN 123456789 AND 123456999
• 务必设置 Statement.setFetchSize(100)，避免 Oracle 默认一次返回全部结果
• 每次查询后立即调用 DBMS_LOGMNR.END_LOGMNR()，否则下次 START_LOGMNR() 会失败（状态冲突）
• 注意 V$LOGMNR_CONTENTS 中的 SQL_REDO 是字符串，含换行和空格，解析前先 trim().replaceAll("\s+", " ")

如何从 SQL_REDO 字符串提取表名、操作类型和主键值

SQL_REDO 不是标准 SQL，而是 Oracle 内部重做语句表示法，比如 insert into "SCOTT"."EMP"("EMPNO","ENAME") values (7900,'JAMES'); 或更糟的 update "SCOTT"."EMP" set "SAL" = '1250' where "EMPNO" = '7900' and ROWID = 'AAAFdDAAFAAAABmAAB';。不能直接交给通用 SQL 解析器处理。

实操建议：

• 优先匹配开头关键字：sqlRedo.startsWith("insert into") → OPERATION = "INSERT"；同理识别 "update "、"delete from"
• 表名从第一个双引号对中提取：Pattern.compile(""([^"]+)"\."([^"]+)"").matcher(sqlRedo).find()
• WHERE 条件中的主键值需结合 ALL_TAB_COLUMNS 查询对应表的 PRIMARY_KEY 列，再正则提取 "PK_COL" = 'value' 形式；别信 ROWID，它在跨库/跨平台 CDC 中不可移植
• 遇到 SQL_UNDO（回滚语句）时，忽略它——LogMiner 的 CDC 场景只关心最终生效的变更，不是事务过程

为什么 LogMiner 不适合长期运行的实时 CDC

LogMiner 本质是日志解析工具，不是流式引擎。它不维护位点（LSN/SCN）自动推进，也不提供 checkpoint 机制。每次重启都要重新指定日志范围，且 V$LOGMNR_CONTENTS 查询性能随归档日志量线性下降。当数据库每秒产生 >100 条 DML，单次 SELECT 耗时很容易超过 30 秒，导致 JDBC 连接超时或 SCN 落后太多。

实操建议：

• 把 LogMiner 当作“批式增量快照”用，比如每 5 分钟查一次最新归档日志，而非监听在线日志文件
• 归档路径必须对 Oracle 数据库进程可读，JDBC 所在机器无需访问磁盘——所有解析都在服务端完成
• 真正需要亚秒级延迟时，放弃 LogMiner，改用 Oracle GoldenGate 或 Debezium + Oracle Connector，它们封装了日志挖掘细节并内置容错

SCN 推进逻辑容易写错，特别是跨日志文件边界时，漏掉一条 ADD_LOGFILE 就会导致中间变更丢失——这种问题不会报错，只会静默跳过。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南