Bonjour,
 
Après plus de 6 ans que je ne touchais à Oracle je m'y suis remis très récemment.
 
Cependant je rencontre quelques problèmes.
J'aimerai voir les requêtes arrivant sur la base de données, requêtes ou appel de procédures stockées effectuées par une appli asp.net.
 
Les commandes un peu obscure d'Oracle pour effectuer quelque chose qui me semble relativement courant (un outil tel sql profiler pour sql server le fait), ne m'ont pas permis d'obtenir ce que je souhaitais, c'est à dire le sql exécuté.
 
J'ai essayé TOAD, j'ai réussi UNE FOIS. Depuis je ne vois plus le process de .net c'est à dire WebServ.webserver.exe dans la liste des process de SQL TRACKER, même losque je demande à afficher tous les process.
C'est pourtant tout à fait ce que je voulais.
 
SQL Developper me présente bien le process, me dit activer la trace de la session mais je ne vois rien de neuf du côté des fichiers *.trc.
 
Je suis vraiment perdu, j'ai parcouru tout google (probablement mal vu que je n'ai pas trouvé).
J'ai parcouru la doc Oracle, franchement pas clair quand on "débute", surtout que c'est un morceau sur une page à droite, puis un autre morceau sur une autre page à gauche.
 
Quelqu'un aurait il une idée suggestion tuto, quelque chose qui me permette de me dépatouiller ?
 
Merci.

Es-tu sûr que tu n'utilises qu'une seule session ? Il arrive que des api crée plusieurs process sur la base.
Dans le doute tu peux activer sql_trace pour toute la base, ensuite avec tkprof tu lances une analyse en excluant les process système

Je ne suis pas du tout sur.
Pour une raison simple, c'est que le serveur va créer une session si nécessaire, et en générer une nouvelle si entre temps la première a été tuée pou rune raison X ou Y.
 
Je sents que je vais galérer encore, je n'ai vu aucune réponse claire sur ce sujet, juste des affirmations disant il suffit de ou on peut faire, mais rien n'expliquant la démarche, enfin aucune démarche ne m'ayant donné un début de solution.
 
Je vais voir pour le sql_trace sur toute la base, le pb c'est que par défaut, je ne sais pas ce qu'Oracle décide ou non de conserver ni même comment identifier le bon fichier trc. Il en génère parfois plusieurs, met parfois plusieurs minutes avant d'enregistrer les données dans les fichiers etc ...
 
Merci pour ta réponse.

je t'ai donné les grandes lignes, mais si tu veux "la démarche" il faudrait que tu commences par être précis toi-même, à savoir la version d'oracle, l'OS, etc.
 
après rien ne t'empêche de chercher un peu par toi-même, je ne vais pas expliquer en détail le fonctionnement de sql_trace ni de tkprof, les docs oracle étant suffisamment explicite à ce sujet
 
le fait qu'il génère plusieurs fichiers, de mémoire c'est 1 fichier par process (ou thread sous windows), mais avec tkprof tu peux spécifier plusieurs fichiers sources : ca te permet de compiler tous les fichiers trace en 1 seule analyse
 
Pour exclure les requêtes systèmes, il faut utiliser l'option sys=no
http://docs.oracle.com/cd/B19306_0 [...] .htm#i4640

j'ai complètement zappé de préciser l'os et la version
 
C'est sur windows 7 et Oracle 11g.
 
Concernant le côté explicite des docs Oracle, de mon expérience j'ai déjà vu bien meilleur. Surtout que tout ne fonctionne pas forcément du premier coup, toutes les variables devant être initialisées ne sont pas toujours précisées. Rien qu'à voir l'installation d'Enterprise Manager qui est une vraie plaie, te demande de changer plusieurs paramètres en cours d'installation pour te dire à la fin qu'il existe un problème de port, port déjà occupé par lui même lors de sa propre installation, pour dire que j'ai quand même un peu soupé sur Oracle et personnellement en terme de qualité documentaire j'ai vu mieux.
 
Cependant j'utilise beaucoup des logiciels tel sql developper ou toad et beaucoup moins sql plus, je suis donc tributaire de la qualité de ces applis.
 
Oui j'aimerai bien une démarche, non pas que je n'ai pas cherché (pas très gentil de dire cela ), j'ai trouvé je l'ai fais fonctionner mais depuis plus rien ne fonctionne, je ne vois pas ce que j'ai modifié pouvant provoquer cela, ni la variable que j'ai pu atteindre ayant une telle conséquence ou encore la manipulation qui m'a échappée. D'un autre côté le fait de l'avoir fait fonctionner ne m'a pas donné le résultat que j'attendais, j'ai donc un problème d'utilisation.
 
C'est un peu pour cela que je demande de l'aide .

 
Tu peux monitorer plus finement tes requêtes en les "marquant" grâce à :

DBMS_APPLICATION_INFO.SET_MODULE(monModule);
-- et
DBMS_APPLICATION_INFO.SET_ACTION(monAction);

 
cf. :
http://docs.oracle.com/cd/B19306_0 [...] appinf.htm
 
Il suffit qu'à chaque ouverture de connexion Oracle dans ton application tu appels ces deux fonctions avec ce que tu veux en paramètres
Ensuite dans les vues types V$SQL, tu aura le module et l'action de renseigné, donc pour filtrer c'est impeccable.

DBMS_APPLICATION_INFO.SET_MODULE(monModule);
-- et
DBMS_APPLICATION_INFO.SET_ACTION(monAction);

 
Je n'ai pas encore tester ces deux méthodes, mais j'essaierai merci.
 
Cependant, j'ai finis par récupérer les traces et les variables binder (le fichier TRC est véritablement bizarre, quand on lui demande de binder les variables il ne fait que les appeler B1 B2 B3 et ensuite affiche un petit paragraphe avec Bind#0 Bind#1 etc ... qui ne correspondent en rien à B1 B2 B3 mais à la première occurence d'une des variable, si B9 est présent en premier sa valeur se trouvera dans Bind#0, c'est vraiment pas sérieux ).
 
J'ai récupérer les traces en récupérant la session dans TOAD, je n'ai pas encore la requête pour le faire.
Browser session dans TOAD, je vois mon appli, je récupère le SID.
 
J'exécute cette petite requête pour récupérer le serial et le nom du fichier trc avec son chemin :
 
SELECT s.sid,
       s.serial#,
       pa.value || '/' || LOWER(SYS_CONTEXT('userenv','instance_name')) ||    
       '_ora_' || p.spid || '.trc' AS trace_file
FROM   v$session s,
       v$process p,
       v$parameter pa
WHERE  pa.name = 'user_dump_dest'
AND    s.paddr = p.addr
 
Une fois armé du SID et du SERIAL, j'exécute : EXEC DBMS_MONITOR.session_trace_enable(MonSID, MonSerial, FALSE, TRUE);
 
Et miracle, le fichier finit par s'afficher après quelques requêtes et plusieurs secondes.

C'est normal, c'est ce qu'on appelle le bind peeking.
 
En fait quand tu met une bind variable, l'optimiseur ne peut pas faire de plan d’exécution car il ne connais pas encore la sélectivité de la requête. Il attends donc la première valeur envoyée, et ne calculera qu'à ce moment le plan d’exécution.
 
Et oui tu touches un point essentiel, si tu ré-exécute ensuite la même requête, et que les valeurs sont tout autres, et que la sélectivité change du tout au tout, le plan d’exécution pourrais ne pas être optimal.
 
De mémoire dans la trace 10053 tu as les informations exacte.

Merci pour l'explication.
 
La lecture n'est vraiment pas simple dans le fichier trc, parfois les variables et leurs valeurs sont indiquées bien plus loin que l'endroit ou il y fait référence.
 
Avec tkprof je ne récupère pas les binds. A priori c'est encore un autre outil qu'il faut utiliser Trace Analyzer TRCANLZR, j'ai l'impression qu'il n'est plus d'actualité.
 
Tu parlé de la trace 10053, je n'en ai pas.
A quoi servait cette trace ? Il y aurait donc un moyen de récupérer de manière plus clair, l'appel d'une requête ou d'une procédure avec ses variables alimentées ?
SQL TRACKER ne veut pas tracker mon appli.net, c'était pourtant super pratique.

La trace 10053 c'est plutôt destiné au support Oracle et en principe c'est super détaillé.
 
Si tu goole sur "trace 10053 oracle" t'aura plein d'explication sur comment la récupérer et la lire.
 
En gros tu faire un alter session avant tes requêtes et ça te génère un fichier dans le répertoire des traces utilisateurs.

Je vais étudier cela, merci.
La trace 10053 n'est actuellement pas présente dans le répertoire.