Если вы получите полный стек ошибок, вы сможете увидеть, какая строка какого триггера выдает ошибку.Это самый эффективный подход.Например, если вы создаете триггер, который фиксирует и выполняет INSERT, трассировка стека покажет вам, какая строка какого триггера вызвала ошибку.
SQL> create table t (
2 col1 number
3 );
Table created.
SQL> ed
Wrote file afiedt.buf
1 create trigger trg_t
2 before insert on t
3 for each row
4 begin
5 commit;
6* end;
SQL> /
Trigger created.
SQL> begin
2 insert into t values( 1 );
3 end;
4 /
begin
*
ERROR at line 1:
ORA-04092: cannot COMMIT in a trigger
ORA-06512: at "SCOTT.TRG_T", line 2
ORA-04088: error during execution of trigger 'SCOTT.TRG_T'
ORA-06512: at line 2
Вы можете искать источник всех триггеров, ищаконкретная строка.Примерно так будет искать литерал «COMMIT» в любом триггере в любых схемах, которые вы укажете.
SELECT name, text, line
FROM dba_source
WHERE owner IN (<<schemas you want to search>>)
AND upper(text) like '%COMMIT%';
С другой стороны, существует высокая вероятность того, что триггер, который не работает, вызывает хранимую процедуруи это хранимая процедура, которая совершает.Поэтому поиск по источнику ваших триггеров может быть бесполезен.
Вы можете потенциально уменьшить это, выполнив рекурсивный запрос на DBA_DEPENDENCIES
(или ALL_DEPENDENCIES
или USER_DEPENDENCIES
в зависимости от уровня ваших привилегий и объемато, что вы хотите найти), чтобы найти все процедуры, которые потенциально могут быть вызваны из любого триггера, и найти источник всех этих процедур из DBA_SOURCE
.Но это будет намного сложнее, чем просто проверка полного стека ошибок.