Discussion :

[LeoAnderson]

Bonjour,

J'ai un souci avec un soft qui se prend une ORA-1031 sur une instruction "mystère".

J'ai bien essayé avec les event 1031 et 10046 de trapper le privilège qui lui manque mais dans les deux cas, je n'ai que l'instruction que si c'est du SQL (autant avec l'event 10046 c'est normal, mais pour l'event 1031...)
En clair si je fais un "create view toto as select * from dual" avec un user qui n'a pas le privilège CREATE VIEW, la trace produite (par l'un ou l'autre event) me donne bien l'ordre provoquant l'exception.
par contre, si je tente un "shutdown" avec un compte non SYSDBA, c'est aussi l'exception 1031 qui est déclenchée mais la trace n'indique pas que j'ai voulu faire un shutdown. Juste un truc style "internal exception" dans la trace 1031 suivi des dumps des différentes zones mémoire.

Bref, y'a mieux que ces deux events pour savoir quelle est la commande (SQL ou non) qui a provoqué l'exception ?
ou c'est une question de level mais vu que la documentation est inexistante à ce sujet, on tâtonne légèrement... :S

Leo.

[pifor]

Le cas de la commande shutdown est particulier: shutdown n'est pas une commande SQL et n'est pas transmise telle que par le client au serveur d'après Tom Kyte. Il n'est donc pas possible de tracer cette commande avec la trace SQL ou avec la commande audit.

[LeoAnderson]

Je sais que ce n'est pas du SQL. J'ai d'ailleurs le problème avec toutes les instructions non SQL (telles que archive log list par exemple)

et la trace de l'event 1031 n'est pas la trace SQL et pourtant, elle ne me renseigne pas, alors que c'est son rôle !

pourtant, si je reprends l'exemple de l'archive log list, avec l'event 10046 et un compte SYSDBA, je ne vois certes pas la commande (et là encore, c'est normal !) mais je vois les ordres SQL induits par celle-ci...