set_module/set_action不足以监控长耗时任务，因其仅更新v$session静态字段，无法反映执行进度；需显式调用dbms_application_info.set_session_longops写入v$session_longops，并维护rindex/slno句柄，结合sofar/totalwork计算百分比。
为什么 SET_MODULE/SET_ACTION 不足以监控长耗时任务
因为 SET_MODULE 和 SET_ACTION 只更新 v$session 的静态字段，而长耗时任务（如大批量数据加载、统计信息收集）往往持续数分钟甚至小时，期间 MODULE/ACTION 不变，无法反映“执行到哪一步”或“还剩多少”。真正能体现进度的视图是 v$session_longops，但它不会自动填充——必须显式调用 DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS 才会写入。
如何用 SET_SESSION_LONGOPS 写入可追踪的进度条
这个过程不是简单设个名字，而是要维护一个“长操作句柄”，Oracle 用 rindex 和 slno 两个整型参数标识唯一行。首次调用时传入 set_session_longops_nohint（值为 -1），Oracle 返回实际的 rindex 和 slno，后续更新必须复用这两个值，否则会新增冗余行。
-
op_name是任务名，最大 64 字节，建议用业务含义明确的字符串，如'order_batch_import' -
sofar和totalwork必须是数值类型，且sofar ≤ totalwork；Oracle 用它们算百分比，sofar = totalwork表示完成 -
target_desc最大 32 字节，填被处理对象描述，如'ORDERS table'，别写成'the orders table in schema APP'（超长被截断） - 每次更新前建议加
DBMS_LOCK.SLEEP(0.1)避免高频刷写影响性能
典型循环中怎么安全更新 longops 状态
在游标循环或批量 DML 中更新 sofar 时，不能只靠计数器自增，必须确保 sofar 单调递增且不越界。常见错误是：最后一次循环把 sofar 设成 totalwork + 1，导致视图里显示负百分比或报错 ORA-20001: sofar cannot exceed totalwork。
- 初始化时调用一次
SET_SESSION_LONGOPS获取rindex/slno，存为局部变量 - 循环体内每处理 N 行（比如 1000 行）更新一次：
sofar := LEAST(sofar + 1000, totalwork) - 循环结束后显式设
sofar := totalwork，并再调用一次SET_SESSION_LONGOPS - 异常处理块中也要补全：若中途失败，设
sofar := totalwork或NULL（但 Oracle 不支持设 NULL，只能设为当前值）
容易被忽略的兼容性与权限问题
SET_SESSION_LONGOPS 要求会话有 SELECT 权限在 v$session_longops，但更关键的是：该视图默认对普通用户不可见，需 DBA 显式授权 SELECT ON SYS.V_$SESSION_LONGOPS TO your_user（注意是 V_$ 而非 V$）。另外，如果任务跑在自治事务（PRAGMA AUTONOMOUS_TRANSACTION）里，rindex/slno 不会继承，必须在自治事务内重新调用初始化。
最常漏掉的一点：SET_SESSION_LONGOPS 不会自动出现在 AWR 报告中，它只存在于实时视图；若要归档分析，得自己定时采样 v$session_longops 并落库。
