La raison pour laquelle il fonctionne sous SYS c'est qu'il s'agit d'un compte privilégié spécial. Vous devez créer un nouveau justificatif d'identité et le mapper au poste
La solution serait de créer un identifiant avec DBMS_SCHEDULER.CREATE_CREDENTIAL avec un compte de système d'exploitation disposant de suffisamment de privilèges et attribuez ces nouvelles informations d'identification à votre travail.
Pour être honnête, je ne sais pas encore pour le problème de déclenchement.
Modifier - solution basée sur la fonction de sous-transaction d'Oracle
Après la mise à jour de l'OP et la réaction aux commentaires :
Sur la base du flux de travail, je pense qu'il est préférable d'utiliser la notification interne d'Oracle pour faire le responsive Audit. Je pense qu'essayer de vous pirater dans le journal des événements Windows via une application externe apporte une autre couche inutile de complexité.
Je créerais une table dans la base de données où je stockerais tous les événements et au-dessus de cette table, je créerais un travail avec des notifications (SMS, courrier, etc.) qui serait exécuté en cas de modification de la table de journal.
Pour utiliser des déclencheurs lorsqu'une erreur se produit, vous devez utiliser PRAGMA autonomous_transaction
depuis votre périmètre principal (permet de faire une sous-transaction). Cela vous permettra de commettre n'importe quel DML vous pouvez avoir, mais effectuez une restauration du reste.
