oracle 19c没有热补丁功能，bug 32653669等内核级缺陷必须通过ru补丁修复并重启实例，sql patch对此类空间管理错误无效。
oracle 19c **没有“热补丁”功能**——这是个常见误解。官方从未提供无需重启实例、不中断业务的“热补丁”机制；所谓“在线打补丁”，实际指部分sql层修复（如dbms_sqldiag生成的sql patch）可动态生效，但底层bug（尤其是涉及表空间、lob、内存管理的）必须通过安装ru（release update）或一次性诊断补丁（interim patch）解决，且绝大多数需重启数据库实例或至少重启相关后台进程。
为什么不能用“热补丁”修复表空间满导致的实例crash（Bug 32653669）
Bug 32653669 是一个内核级缺陷：当表空间耗尽 + SecureFile LOB操作同时发生时，GEN0进程会触发不可恢复的内部错误，直接导致实例崩溃。这类问题发生在存储层与进程调度交汇处，无法靠SQL执行计划绕过。
- SQL Repair Advisor 生成的
SQL Patch只影响优化器路径，对ORA-1652/ORA-1691等空间分配失败无任何作用 -
DBMS_SQLDIAG的CREATE_SQL_PATCH不接受空间管理类错误作为输入条件 - 该Bug的修复必须修改
ksfd（Kernel Storage File Driver）和kcb（Kernel Cache Buffer）模块，属于二进制级变更
真正有效的修复路径：RU补丁 + 表空间紧急处置
针对 Bug 32653669，唯一可靠方案是升级到已修复版本（19.12.0.0.DBRU:210720 或更高），并配合运行时规避措施：
- 立即检查表空间使用率：
SELECT tablespace_name, used_percent FROM dba_tablespace_usage_metrics; - 临时扩容前，先清理历史归档/备份文件，避免误删数据文件
- 若无法立刻打补丁，强制将LOB字段转为
BASICFILE（需业务停写）：ALTER TABLE t MOVE LOB(lob_col) STORE AS BASICFILE; - 安装补丁后，必须运行
datapatch -verbose—— 否则SYS.OPATCH_XML_INV表可能损坏，导致后续补丁校验失败
打补丁时最容易被忽略的三个实操细节
很多DBA在应用19.22 RU后仍遇到crash复现，问题往往出在这些环节：
-
OPatch版本必须 ≥ 12.2.0.1.30 —— 低于此版本会静默跳过关键组件校验，opatch lsinventory -detail中看不到35943157补丁条目 -
/tmp目录剩余空间需 ≥ 8GB —— OPatch解压RU包时会创建多个临时CLOB段，空间不足会导致ORA-01652在补丁过程中提前触发 - 打完补丁后，未检查
dba_registry_sqlpatch视图中STATUS = 'SUCCESS'的记录是否包含Bug 32653669的修复标识（DESCRIPTION字段含"SecureFile LOB space allocation"）
补丁不是万能胶——它只修复已知路径，而表空间管理问题的根因永远在容量规划和监控闭环里。哪怕打了最新RU，如果 dba_tablespace_usage_metrics.used_percent 长期 >95%，下一次crash只是时间问题。
