当然可以！在PL/SQL里，你完全能在触发器内部访问调用栈信息，刚好能解决你这种不能修改第三方封装存储过程、却要追踪INSERT操作发起方的调试需求。Oracle 12c及以后推出的UTL_CALL_STACK包就是专门干这个的利器，不用动第三方代码就能拿到你要的上下文信息。

核心原理 #

你需要的是最终触发INSERT的初始存储过程名称，而非中间调用的层级，所以关键是定位到调用栈最顶层的程序单元：

• UTL_CALL_STACK.dynamic_depth：获取当前调用栈的动态深度（也就是总共有多少层嵌套调用）
• UTL_CALL_STACK.subprogram(depth)：根据指定深度，返回对应层级的子程序信息（是一个包含模式名、程序名的数组）
• UTL_CALL_STACK.concatenate_subprogram()：把数组里的模式名和程序名拼接成完整的、可直接阅读的程序标识

触发器实现示例 #

下面是一个完整的调试触发器示例，会把调用方信息记录到专门的调试日志表中：

CREATE OR REPLACE TRIGGER trg_monitored_table_debug
AFTER INSERT ON your_monitored_table
FOR EACH ROW
DECLARE
    v_init_caller VARCHAR2(1000);
BEGIN
    -- 获取初始调用的存储过程全名（包含模式名）
    v_init_caller := UTL_CALL_STACK.concatenate_subprogram(
        UTL_CALL_STACK.subprogram(UTL_CALL_STACK.dynamic_depth)
    );

    -- 将调试信息写入日志表（你需要提前创建这个表）
    INSERT INTO debug_insert_calls (
        call_timestamp,
        target_table,
        initiating_procedure,
        inserted_row_id
    ) VALUES (
        SYSTIMESTAMP,
        'YOUR_MONITORED_TABLE',
        v_init_caller,
        :NEW.ROWID
    );
EXCEPTION
    WHEN OTHERS THEN
        -- 调试触发器尽量不要抛出异常，避免干扰主业务流程
        NULL;
END;
/

关键注意事项 #

• 版本要求：UTL_CALL_STACK是Oracle 12c才引入的特性，如果你的数据库是11g或更早版本，只能用旧的DBMS_UTILITY.FORMAT_CALL_STACK，但那个需要自己解析字符串，麻烦得多。
• 权限配置：要确保触发器所属的用户拥有EXECUTE权限在UTL_CALL_STACK包上，不然会抛出权限不足的错误。
• 调试完成后清理：这个触发器是用来调试的，定位完问题后记得禁用或删除它，避免长期运行带来不必要的性能开销。

内容的提问来源于stack exchange，提问作者Neoheurist