Discussion :

[kanko]

Bonjour et bonne année à tous.
apres avoir lu les divers documents du site relatif au traçage de session oracle, j'ai ecrit ce script:

CREATE OR REPLACE TRIGGER "SYS"."TRACE_USER" AFTER
LOGON ON DATABASE DECLARE v_user varchar2(30);
BEGIN
EXECUTE IMMEDIATE 'SELECT sys_context(''user_env'', ''session_user'') FROM DUAL' INTO v_user;
IF v_user !='SYSTEM' THEN
EXECUTE IMMEDIATE 'alter session set events ''10046 trace name context forever, level 8''';
END IF;
END;

mais seulement quand je me connecte avec un user autre que system, la trace n'est pas activée. la compilation du code n'a renvoyé aucun message d'érreur. y'a -t'il des droits particulier à accorder au user qu'on veut tracer?
Deuxième point: j'ai exécuter la commande :

alter session set events '10046 trace name context forever, level 8'

directement dans une session que je veux tracer; la commande marche bien mais seulement dans le fichier je m'attendais à avoir le nom du schema sous lequel les ordre sql ont été passé mais non. j'ai plutôt des "parsing user id" numérique ce qui ne me permet pas de savoir qu'elle user à fait quoi.
Merci de m'aider à résoudre ce problème.
PS: Mon but c'est de pouvoir activer la trace automatiquement après la connexion de certain user et d'analyser les fichiers produits.

[Marc Musette]

1) grant alter session nécessaire

2) dans certains cas le username s'affiche entre ( ) ; apparement pas toujours -> aucune idée d'où cela provient (peut-être la version)

en tout cas pour trouver à quel user cela correspond : table ALL_USERS, colonne USER_ID

[pifor]

Ca devrait mieux marcher avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select sys_context('userenv', 'session_user') from dual;

Merci ne pas oublier d'indiquer votre version d'Oracle: http://www.developpez.net/forums/showthread.php?t=28716

[kanko]

Bonjour,
j'ai réussi finalement à activer les traces pour certains utilisateurs; mais seulement j'ai un autre problème:

est-il possible de supprimer toutes les requêtes systèmes et ne garder dans le fichier générer par tkprof ou tout autre utilitaire que vous voudrez bien m'indiquer que les reqête effectivement saisie par l'utilisateur?

Merci.

[orafrance]

http://oracle.developpez.com/guide/tuning/tkprof/#LIV

y'a plus qu'à lire

[kanko]

Quand le fichier trace est énorme c'est pas évident de voir les requêtes utilisateurs; c'est ça mon problème.

[pifor]

L'option SYS=no (qui est l'option par défaut) de TKPROF permet de ne pas afficher le SQL récursif. Mais je ne crois pas que TKPROF peut faire la différence entre différentes sortes de requêtes SQL applicatives: il faudrait plutôt essayer d'activer la trace au bon moment.

[Marc Musette]

tu tournes quelle version d'oracle ?

[kanko]

Oracle 10G R1 sous linux

[Marc Musette]

alors tu devrais pouvoir utiliser trcsess qui te permet de fabriquer un fichier de trace propre à un user (via le paramètre client-id)

à chaque session, tu popules ce client_identifier avec DBMS_MONITOR

j'essaie de te faire un exemple concret pour demain.

ne t'en fais , il y a de l'espoir pour que cela marche

[bouyao]

Bonjour

Tu peut utiliser DBMS_FGA

[Wurlitzer]

alors tu devrais pouvoir utiliser trcsess qui te permet de fabriquer un fichier de trace propre à un user (via le paramètre client-id)

à chaque session, tu popules ce client_identifier avec DBMS_MONITOR

j'essaie de te faire un exemple concret pour demain.

ne t'en fais , il y a de l'espoir pour que cela marche

Je suis allée jeter un coup d'oeil sur DBMS_MONITOR. J'ai pas trop compris ce que cela apporte par rapport aux "anciennes" méthodes pour se mettre en mode trace ? C'est quoi les avantages selon toi ?

[Marc Musette]

1) cette façon de faire est documentée et supportée par oracle

(fini les alter session set events 10046 )

2) la possibilité d'activer des traces non plus uniquement sur base d'un sid (session id)mais sur base d'un client id, service, module, action !!!

y a pas photo ... tu peux enfin facilement tracer un utilisateur au travers un conection pool

le demandeur initial ne donnant plus signe de vie, je n'ai pas fait le forcing pour l'exemple (boulot avant tout ) mais si ça t'intéresse j'essaierai de le poster dans la semaine ou d'en faire un petit article ...

[Wurlitzer]

Oui, c'est tres interessant. J'ai effectivement le problème de suivre des clients qui passe aléatoirement par un pool de connection.

Et je n'avais pas trouvé de solution élégante. Si tu as le temps, je suis preneur des tes exemples.

[kanko]

je n'ai pas disparu, j'essaie de trouver une solution mais je n'avance pas du tout. Merci Marc de me donner l'exemple promis.

[Marc Musette]

hello

jen'ai pas disparu non plus mais manque de temps . je veux 48h dans une journée.

[Marc Musette]

un petit exemple tout simple :

lorque l'application se connecte à la db, elle s'identifie via un "client_id" ; c'est via ce client_id que lon va pouvoir tracer le run d'une application même si la connection à la db se fait au travers d'un pool de connection .

1) activer la trace sur base d'un identifiant "client" et non sur base de la session physique (sid,serial#)

SQL> exec dbms_monitor.client_id_trace_enable(client_id=>'marc');

ceci vaut pour toutes les sessions existantes et futures

2) initialisation du client_id

exec dbms_session.set_identifier('marc');
ceci doit se faire dans le code application à chaque connection --> cela permet de suivre un utilisateur réel au sein d'un connection pool

3) consolider les différents fichiers de trace, et les formatter via tkprof

>C:\...\udump> trcsess output="tracefile.trc" clientid='marc'

>C:\...\udump> tkprof marc.trc output=marc.tkp

4) disable de la trace si plus nécessaire

SQL> exec dbms_monitor.client_id_trace_disable(client_id=>'marc');