启用可恢复空间分配的关键是将resumable_timeout设为非零值（如3600），该动态参数在实例级生效，rac需逐节点设置，无需重启；会话级启用需配合显式timeout与业务name，仅对空间类错误（ora-01536/01653/01654）生效，挂起期间事务保持锁定，超时后自动中止。
resumable_timeout 非零值是启用可恢复空间分配的必要条件，否则所有空间类错误（如 ora-01536、ora-01653、ora-01654）仍会直接报错中断。
怎么在实例级全局启用 Resumable Space Allocation
关键不是“开启开关”，而是设置 RESUMABLE_TIMEOUT 参数为非零值。设为 0 相当于禁用，设为正整数（单位：秒）才真正生效。
-
ALTER SYSTEM SET RESUMABLE_TIMEOUT = 3600 SCOPE=BOTH;—— 推荐从 3600（1小时）起步，避免过短导致误 abort - RAC 环境下，该参数在每个 instance 单独生效，不能跨节点同步；需逐个 instance 执行
- 修改后无需重启实例，但已有会话不会自动继承新值，仅对新建立的会话或显式启用的会话生效
- 如果使用 SPFILE，
SCOPE=BOTH保证内存和持久化配置一致；若用 PFILE，需手动更新并重启
session 级启用时 timeout 和 name 怎么配才不踩坑
会话级启用更灵活，但容易忽略默认行为和命名歧义。
- 只执行
ALTER SESSION ENABLE RESUMABLE;会使用实例级RESUMABLE_TIMEOUT值；若实例级为 0，则此语句实际无效 -
ALTER SESSION ENABLE RESUMABLE TIMEOUT 1800 NAME 'load_job_202606';—— 显式指定 timeout 更可靠，NAME字段建议带业务标识，方便后续查DBA_RESUMABLE视图定位 -
NAME默认格式是User username (userid), Session sessionid, Instance instanceid，纯数字 ID 在多会话场景下难区分 - 一旦启用，当前会话所有后续 DML/DDL（含
INSERT ... SELECT、CREATE INDEX、ALTER TABLE MOVE）都自动进入 resumable 模式，无需重复执行
哪些操作能挂起？哪些错误根本不会触发 resumable
resumable 只响应三类空间相关错误，其他失败一律立即终止。
- 会挂起的操作包括：
INSERT、UPDATE、CREATE TABLE AS SELECT、CREATE INDEX、ALTER INDEX REBUILD、IMPDP等涉及段扩展或排序的操作 - 触发挂起的错误只有三个条件：
out of space（ORA-01653）、maximum extents reached（ORA-01631）、space quota exceeded（ORA-01536） -
ORA-00600、ORA-00060（死锁）、网络中断、权限不足等——完全不走 resumable 流程，直接报错 rollback - 挂起期间，事务未提交也未回滚，所有锁和资源保持占用；超时后才自动 abort 并释放
怎么确认挂起发生了？DBA 该看什么
用户端通常无感知，DBA 必须主动监控，否则任务可能静默失败。
- 检查告警日志：搜索
statement suspended, wait error to be cleared，这是最直接信号 - 查视图：
SELECT * FROM DBA_RESUMABLE WHERE STATUS = 'SUSPENDED';—— 注意TIMEOUT和START_TIME，判断是否快超时 -
V$SESSION_WAIT中对应会话的EVENT列会出现statement suspended, wait error to be cleared - 触发器方案（如
AFTER SUSPEND ON DATABASE）能自动干预，但必须确保触发器中调用DBMS_RESUMABLE.SET_TIMEOUT()成功，且用户有EXECUTE ON DBMS_RESUMABLE权限
实际运维中，最容易被忽略的是：实例级 RESUMABLE_TIMEOUT=0 时，即使会话执行了 ALTER SESSION ENABLE RESUMABLE，也不会生效——因为 Oracle 优先检查实例参数，为 0 就直接 bypass 整个机制。
