resumable_timeout 设置为非零值是必要条件，否则即使遇到空间类错误，系统也会直接报错并中断，不会进入挂起流程。
实例级全局启用 Resumable Space Allocation
这并非简单的“打开一个开关”，关键在于将 RESUMABLE_TIMEOUT 设置为正整数。如果设为 0，则表示禁用；只有设为正整数（单位秒），该机制才会真正生效。
- 推荐使用
ALTER SYSTEM SET RESUMABLE_TIMEOUT = 3600 SCOPE=BOTH;—— 以 3600 秒（1 小时）为起点较为稳妥，时间过短容易导致任务被误终止。 - 在 RAC 环境中，此参数属于实例级别，不会跨节点同步，因此每个实例都需要单独执行一次。
- 修改后无需重启实例，但已存在的会话不会自动继承新值，仅对新建立的会话或显式启用 resumable 的会话生效。
- 如果使用 SPFILE，
SCOPE=BOTH可以确保内存和持久化配置保持一致；若使用 PFILE，则需要手动更新配置文件并重启。
会话级启用时，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 仅响应三类空间相关错误，其他失败均直接终止，不作处理。
- 会进入挂起的操作包括：
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 流程，直接报错并回滚。- 挂起期间，事务既未提交也未回滚，所有锁和资源一直被占用，直到超时后才会自动终止并释放。
如何确认挂起发生了？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 后直接跳过整个机制。
