Vamos por partes : primeiro, vc não diz Claramente mas estou ** SUPONDO ** que essa tal trigger xyz é uma trigger DE DML, do tipo ON INSERT nalguma tabela T, certo ?? Sendo isso, rigorosamente Não Importa se o INSERT na tabela T está sendo feito por um bloco anônimo, por um código PL/SQL, não importa…
Isso posto, para vc poder debugar código stored PL/SQL no Oracle SQL Developer (o que inclui triggers, packages, functions e procedures) é necessário que :
– o stored PL/SQL TENHA sido compilado em DEBUG MODE. IMPORTANTE, se teu stored PL/SQL com o nome de xyz chama/executa um outro stored pl/sql A, que chama um outro B, TODOS ELES tem que estar compilados em DEBUG MODE
– o usuário que vai fazer o DEBUG tem que ter recebido privilégios de debug no database em questão
– haja uma PORTA DE REDE habilitada para o SQL DEVELOPER conseguir conectar no banco : DEBUG significa que o Oracle SQL Developer vai abrir uma conexão extra ao banco, acessando-o através de uma package de sistema chamada DBMS_DEBUG. Não é incomum que por questões de Segurança no servidor Oracle de produção o DBA tenha ** fechado ** todas as portas de rede afora a default 1521 e/ou tenha Proibido packages internas como essa DBMS_DEBUG de acessar a rede, nesse caso OU o DBA relaxa os procedimentos OU vc tem que fazer o debug no ambiente Homologação ou teste
Isso tudo OK, o procedimento de DEBUG é simples : veja meu exemplo no meu velho blog em https://jlc1967.wordpress.com/2016/10/13/debugando-triggers-com-oracle-sql-developer/ , é basicamente vc escrever (DENTRO DO SQL DEVELOPER!!) um bloco anônimo que faça o DML que dispara a trigger E o executar via a opção de Executar em depuração : com isso (E com TODOS os pré-reqs que citei acima PRESENTES!!) automagicamente a janela do depurador vai ser aberta, aí vc pode marcar breakpoints, executar passo-a-passo, o que for, que NECESSARIAMENTE as packages, procedures, functions, etc, que a trigger chamar VÂO SER EXECUTADAS pelo debugador…
[]s
Chiappa