DBMS_APPLICATION_INFO 是最实用的实时进度标记方式，因其是Oracle官方推荐、稳定且无需额外权限即可动态更新会话元信息的唯一机制，不依赖跟踪文件、不触发审计、不污染共享池。
为什么 DBMS_APPLICATION_INFO 是最实用的实时进度标记方式
因为 oracle 本身不提供“存储过程执行到第几行”的原生接口，dbms_application_info 是唯一被官方推荐、稳定且无需额外权限就能在运行时动态更新会话元信息的机制。它不依赖跟踪文件、不触发审计开销、不污染共享池，适合长期在线业务中轻量嵌入。
SET_MODULE 和 SET_ACTION 怎么配合写进存储过程
在存储过程的关键逻辑节点插入 DBMS_APPLICATION_INFO.SET_MODULE 或 DBMS_APPLICATION_INFO.SET_ACTION，让监控方能通过 V$SESSION 实时查到当前状态。注意：模块名（module）建议固定为过程名，动作名（action）用于表达阶段，比如“读取主表”“生成临时索引”“提交事务前校验”。
DBMS_APPLICATION_INFO.SET_MODULE('PKG_DATA_SYNC', 'LOAD_SOURCE_TABLE');DBMS_APPLICATION_INFO.SET_ACTION('FETCHING CUSTOMER_IDS');- 避免在循环体内高频调用（如每行都设一次 action），否则会轻微增加 latch 竞争；一般每个大步骤设一次即可
- 模块和动作长度总和不能超过 48 字节（Oracle 12c+），超长会被截断，不报错但不可靠
怎么从外部实时查到它正在哪一步
只要存储过程已开始执行且设置了 module/action，你就可以随时在另一个会话里查 V$SESSION。关键不是查 SQL 文本，而是抓 MODULE 和 ACTION 字段 —— 它们反映的是当前正在做的“业务动作”，比 SQL_ID 更贴近语义。
- 查所有活跃的该过程会话：
SELECT sid, serial#, module, action, status, last_call_et FROM v$session WHERE module = 'PKG_DATA_SYNC' AND status = 'ACTIVE'; -
last_call_et是秒级倒计时（上次调用至今），值越大越可能卡住，结合action可快速定位瓶颈环节 - 如果查不到，说明过程还没走到
SET_MODULE那行，或已结束/异常退出（此时module会被自动清空） - 不要依赖
V$SQL查当前执行语句——PL/SQL 块里的多条语句共用同一个sql_id，无法区分进度
容易被忽略的细节和坑
很多人以为设了 SET_MODULE 就万事大吉，实际部署时几个点常导致监控失效：
- 存储过程里没加
EXCEPTION块清理 module/action：一旦异常退出，MODULE仍残留，误导判断；建议在EXCEPTION最后加DBMS_APPLICATION_INFO.SET_MODULE(NULL, NULL); - 用绑定变量拼接
action（如'PROCESSING ID=' || v_id）导致长度超标或内容混乱，应只用静态标识符 - 开发环境测试时看到效果，上线后因连接池复用会话，旧
module未被重置，造成“假进度”；需确保应用层在获取连接后主动初始化SET_MODULE('', '') -
V$SESSION中的MODULE/ACTION是会话级，不是事务级——即使过程里开了自治事务，也不会影响主会话的标记
真正难的不是怎么写那几行 SET_MODULE，而是想清楚哪些节点值得标记、标记后谁来查、查到之后怎么响应。进度监控的价值，永远取决于你是否把 MODULE 和 ACTION 当作可操作的信号，而不是装饰性的日志。
