dbms_application_info.set_module 必须显式调用才生效，oracle 不会自动填充 v$session.module/action；module 最大 48 字节、action 最大 32 字节，自治事务需重设，set_action 应动态标记关键步骤，set_client_info 仅存短标识且不参与 client_identifier 跟踪。
DBMS_APPLICATION_INFO.SET_MODULE 必须显式调用，不会自动生效
Oracle 不会在进入存储过程时自动把过程名填进 v$session.module 或 v$session.action。这两个字段默认是 NULL 或仅显示客户端工具名（比如 sqlplus.exe），对定位具体逻辑毫无帮助。你必须在 PL/SQL 块里主动调用 DBMS_APPLICATION_INFO.SET_MODULE 才能写入。
常见错误现象包括：查 v$session 时看到 module 是空的，或仍是 JDBC 连接池名、应用服务器进程名；AWR 报告中 SQL 没归属到业务模块，无法按模块聚合耗时。
-
module_name最大 48 字节，超长会被截断，建议用包名（如'ORDER_PKG'）或业务域名（如'INVENTORY_PROC'） -
action_name最大 32 字节，适合填当前操作（如'validate_stock'），可设为NULL，后续用SET_ACTION单独更新 - 模块结束前应重置为
NULL，否则下次查询可能误判为仍在执行该模块
SET_ACTION 适合标记关键执行节点，而非只设一次
把 SET_ACTION 当成“打点”用，不是初始化完就不管了。它真正价值在于动态反映执行进度——一旦过程卡住，查 v$session 就能立刻知道停在哪一步。
使用场景典型如长事务：校验库存 → 锁定订单 → 扣减库存 → 更新日志 → 提交。每步前都调一次 DBMS_APPLICATION_INFO.SET_ACTION，就能准确定位卡点。
- 不要只在开头设一个
action然后全程不变，那样失去监控意义 - 避免用模糊词如
'processing'，应具体到动作，如'lock_order_row'、'update_log_table' - 自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）中需重新调用SET_MODULE和SET_ACTION，否则新事务里这些字段仍是NULL
SET_CLIENT_INFO 存轻量上下文，别塞结构化数据
SET_CLIENT_INFO 是补充字段，最大 64 字节，查 v$session.client_info 获取。它和 module/action 独立存储，也不参与基于 client_identifier 的跟踪（比如 DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE）。
常见误用是往里塞 JSON、完整参数列表或堆栈，结果被截断还污染监控视图。
- 适合存请求 ID（如
'req_abc123'）、用户 ID（'uid_789'）、批次号（'batch_20260928'）这类短标识 - 不推荐存路径、SQL 片段、错误消息等动态长内容
- 若需读取，用
DBMS_APPLICATION_INFO.READ_CLIENT_INFO，不能直接在 SQL WHERE 子句里调用函数
所有设置仅当前会话有效，自治事务需手动重设
这是最容易被忽略的一点：所有 SET_MODULE、SET_ACTION、SET_CLIENT_INFO 都只影响当前会话，且不会跨自治事务传播。一旦你在主过程中开启 PRAGMA AUTONOMOUS_TRANSACTION，新事务就运行在全新上下文里，v$session 中对应字段全部清空。
这意味着：如果自治事务里也想被监控，必须在 BEGIN 后立刻重设 module 和 action，否则 AWR、ASH 或实时诊断就断了线索。
- 不要假设“主事务设过了，子事务自然继承”
- 重设时 module 名可沿用主逻辑（如仍用
'ORDER_PKG'），但 action 应体现自治事务职责（如'log_error_auton'） - 没有机制能自动同步这些值，全靠开发人员在代码里显式补全
