ORA-00036是递归SQL层级超限（默认50层），主因是多表触发器循环调用或隐式递归链导致dep值持续增长，而非单纯触发器调用次数多；需通过10046跟踪、v$sql分析定位链路，根本解法是解耦逻辑、加防重入标识或改由应用层统一协调。
ORA-00036 是递归 SQL 层级超限，不是“触发器调用太多次”那么简单
ORA-00036 报错的直接原因是：当前会话执行的递归 SQL（即 Oracle 内部为完成某条语句而自动发起的隐式 SQL）嵌套深度超过了 max_recursive_sql 限制（默认值通常为 50）。触发器本身不直接算“递归层级”，但一旦触发器里执行 DML，又恰好再次触发同名或关联触发器，就可能快速推高递归层级——尤其是存在循环依赖时。
典型诱因不是单个触发器写得复杂，而是多个对象之间形成隐式调用链，比如：A 表 INSERT → 触发器修改 B 表 → B 表 UPDATE → 触发器再改 A 表。Oracle 把整个链路视为同一递归上下文，每跳一次就 +1 层。
哪些触发器结构最容易踩中 ORA-00036
以下模式在真实业务中高频引发该错误，且往往在数据量增大或并发上升后才暴露：
-
INSTEAD OF触发器中执行了对同一视图所依赖基表的 DML，而该基表上又有BEFORE/AFTER触发器，且后者又反向操作了视图或关联表 - 两个表互为外键，且各自有
AFTER INSERT/UPDATE触发器去同步对方，未加INSERTING/UPDATING条件判断或防重入标记 - 触发器内调用存储过程，而该过程内部又执行了触发当前触发器的同类 DML（例如：触发器调用
pkg_log.write()，而write内部插入日志表，该表恰有审计触发器） - 使用了
PRAGMA AUTONOMOUS_TRANSACTION但误以为它能隔离递归层级——其实自治事务只隔离事务上下文，不降低递归计数
怎么定位和验证是不是触发器导致的 ORA-00036
不能只看报错堆栈里有没有触发器名。关键是抓递归调用链：
- 开启 SQL 跟踪：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';，复现问题后用tkprof分析 trace 文件，搜索recursive关键字，观察 SQL 的dep（dependency）列是否持续增长到 50+ - 检查
V$SESSION和V$SQL中当前会话最近执行的递归 SQL：SELECT sql_id, sql_text FROM v$sql WHERE is_recursive = 'Y' AND parsing_schema_name = 'YOUR_SCHEMA'; - 临时禁用可疑触发器（
ALTER TRIGGER xxx DISABLE;），逐个排除；注意：禁用前确认无强一致性依赖，避免数据不一致
修复思路不是“删触发器”，而是切断隐式递归路径
根本解法是让触发逻辑明确区分“主动操作”和“被动响应”，避免 Oracle 把它们全纳入同一递归帧：
- 在触发器开头加标识变量（如
g_in_trigger BOOLEAN := FALSE;），首次进入设为TRUE，后续递归进入时直接RETURN；需配合包变量或会话级上下文（DBMS_SESSION.SET_CONTEXT） - 把多表联动逻辑从触发器移出，改由应用层或调度作业统一处理；触发器只做轻量校验或状态标记
- 若必须跨表更新，改用
INSERT /*+ APPEND */或MERGE替代多次单行 DML，减少触发次数 - 确认是否真需要
FOR EACH ROW：对批量操作，考虑改用STATEMENT级触发器 + 批量收集逻辑（:OLD/:NEW在语句级不可用，需配合LOGGING表暂存中间态）
最常被忽略的一点：ORA-00036 往往是症状，不是病因。它背后大概率藏着设计层面的耦合——比如本该由一个服务协调的事务，被拆到了多个触发器里靠“悄悄联动”维持一致性。这种隐式契约一旦打破，排查成本远高于初期重构。
