如何配置Oracle的Resumable Space Allocation来防止任务中断

启用可恢复空间分配的关键是将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 整个机制。