结论：别用PL/SQL解析GB级JSON——它不是干这个的，硬上必崩；应改用DBMS_LOB定位切片+SECUREFILE CLOB+子片段JSON_TABLE分层处理。
直接说结论：别用 PL/SQL 解析 GB 级 JSON —— 它不是干这个的，硬上必崩。 Oracle 19c 的 PL/SQL 运行在单会话内存空间里，JSON_VALUE、JSON_TABLE 或 pljson 库都依赖将整个 JSON 加载进 PGA，GB 级文本一读就触发 ORA-04030: out of process memory 或长时间卡死。真正可行的路径是“绕开 PL/SQL 解析”，改用数据库原生能力分层处理。
为什么 JSON_TABLE 在 GB 场景下依然会失败
很多人以为只要用上了 19c 的 JSON_TABLE 就万事大吉，但实际踩坑发现：SELECT * FROM JSON_TABLE(clob_col, '$' COLUMNS ...) 仍会把整段 JSON 加载进内存做解析。尤其当 JSON 包含深层嵌套、重复键或未格式化（无换行）时，Oracle 的 JSON 解析器消耗内存远超原始大小（实测 1.2GB 原始 JSON 可能吃掉 8GB PGA）。这不是配置问题，是设计限制。
- JSON 字段必须已声明为
CHECK (col IS JSON)，否则解析前会先做完整语法校验，耗时且不可跳过 -
JSON_TABLE不支持流式读取，无法指定“只解析第 N 个数组元素”这类偏移控制 - 若 JSON 中存在
"data": [{"id":1}, {"id":2}, ...]这类大数组，JSON_TABLE默认展开全部，结果集可能达千万行，进一步拖垮临时表空间
真正能落地的三步分流方案
把“解析 GB JSON”拆成“定位 → 切片 → 提取”三个原子操作，全程避开 PL/SQL 内存瓶颈：
- 用
DBMS_LOB.INSTR+DBMS_LOB.SUBSTR在 CLOB 中定位目标片段（例如找"items":[开始位置和匹配的结束]）—— 这步只操作 LOB locator，不加载内容，毫秒级 - 用
DBMS_LOB.CREATETEMPORARY创建新 CLOB，仅写入定位到的子片段（比如 5MB 的 items 数组），再对该子 CLOB 调用JSON_TABLE—— 内存压力可控 - 对子片段使用
JSON_TABLE(..., 'strict $[*]' COLUMNS ...)显式限定数组遍历范围，避免隐式全展开；配合LIMIT子句（需 21c+）或外层ROWNUM <= 1000控制输出规模
pljson 库在大型 JSON 中的致命缺陷
即使你已安装 pljson 并成功调用 json_list，它在 GB 场景下会立刻暴露本质：所有方法（get、count、to_char）都要求整个 JSON 结构先 parse 成内存对象树。测试表明，一个 800MB 的 JSON 文件在 json_list('...') 构造时就会报 ORA-06502: PL/SQL: numeric or value error，根本进不到循环逻辑。
- 无法跳过无关字段：哪怕你只想要
$.metadata.version，pljson仍会递归解析全部 10 万行嵌套 - 错误定位极差：一旦 JSON 有微小格式错误（如尾部多逗号），报错只显示“parse error at position 12345678”，没法反查是哪一行
- 不兼容自治数据库 AI 特性：在 Oracle Autonomous Database 上，
pljson属于非白名单 PL/SQL 包，可能被默认禁用
最常被忽略的关键点：CLOB 存储方式决定解析上限
很多人卡在“为什么同样 JSON，有的表能跑 JSON_TABLE，有的直接 ORA-04030”，答案藏在存储参数里。如果 JSON 是通过 INSERT INTO t(clob_col) VALUES (EMPTY_CLOB()) 后用 DBMS_LOB.WRITEAPPEND 写入的，它走的是 BASICFILE LOB，性能差且缓存效率低；而用 SECUREFILE 存储的 CLOB 支持压缩、去重和高效流读 —— 这直接影响 DBMS_LOB.INSTR 的定位速度和内存驻留时间。检查语句：SELECT cache, securefile FROM dba_lobs WHERE table_name = 'YOUR_TABLE' AND column_name = 'CLOB_COL'。没开 SECUREFILE，前面所有优化都打折扣。
