Oracle : existe-t-il un outil pour tracer les requêtes, comme Profiler pour sql server ?

Question

Je travaille avec sql server, mais je dois migrer vers une application avec Oracle DB. Pour tracer les requêtes de mon application, j'utilise dans Sql Server le merveilleux outil Profiler. Existe-t-il quelque chose d'équivalent pour Oracle ?

Answer 1

Vous pouvez utiliser The Oracle Enterprise Manager pour surveiller les sessions actives, avec la requête en cours d'exécution, son plan d'exécution, les verrous, certaines statistiques et même une barre de progression pour les tâches les plus longues.

Voir : http://download.oracle.com/docs/cd/B10501_01/em.920/a96674/db_admin.htm#1013955

Allez dans Instance -> sessions et regardez l'onglet SQL de chaque session.

Il y a d'autres moyens. Enterprise Manager ne fait que mettre en couleur ce qui est déjà disponible dans les vues spéciales comme celles documentées ici : http://www.oracle.com/pls/db92/db92.catalog_views?remark=homepage

Et, bien sûr, vous pouvez aussi utiliser l'outil Explain PLAN FOR, TRACE et des tonnes d'autres moyens d'instrumentalisation. Il existe des rapports dans le gestionnaire d'entreprise pour les requêtes SQL les plus coûteuses. Vous pouvez également rechercher les requêtes récentes conservées dans le cache.

Answer 2

alter system set timed_statistics=true

--ou

alter session set timed_statistics=true --if want to trace your own session

-- doit être assez grand :

select value from v$parameter p
where name='max_dump_file_size' 

-- Trouvez le nom et le numéro de série de la session qui vous intéresse :

 select sid, serial# from v$session
 where ...your_search_params...

--Vous pouvez commencer le suivi avec l'événement 10046, le quatrième paramètre définit le niveau de suivi (12 est le plus élevé) :

 begin
    sys.dbms_system.set_ev(sid, serial#, 10046, 12, '');
 end;

--Désactiver le traçage en fixant le niveau zéro :

begin
   sys.dbms_system.set_ev(sid, serial#, 10046, 0, '');
end;

/*Niveaux possibles : 0 - désactivé 1 - niveau minimal. Un peu comme set sql_trace=true 4 - Les valeurs des variables de liaison sont ajoutées au fichier de suivi. 8 - les événements d'attente sont ajoutés 12 - les valeurs des variables de liaison et les événements d'attente sont ajoutés. */

-- de même si vous voulez tracer votre propre session avec un niveau plus élevé :

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

-- éteindre :

alter session set events '10046 trace name context off';

--Le fichier contenant les informations brutes de la trace sera localisé :

 select value from v$parameter p
 where name='user_dump_dest'

--nom du fichier (*.trc) qui contiendra le spid :

 select p.spid from v$session s, v$process p
 where s.paddr=p.addr
 and ...your_search_params...

--Vous pouvez également définir le nom vous-même :

alter session set tracefile_identifier='UniqueString'; 

--Enfin, utilisez TKPROF pour rendre le fichier de trace plus lisible :

C:\ORACLE\admin\databaseSID\udump>
C:\ORACLE\admin\databaseSID\udump>tkprof my_trace_file.trc output=my_file.prf
TKPROF: Release 9.2.0.1.0 - Production on Wed Sep 22 18:05:00 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
C:\ORACLE\admin\databaseSID\udump>

-pour voir l'état d'utilisation du fichier de trace :

set serveroutput on size 30000;
declare
  ALevel binary_integer;
begin
  SYS.DBMS_SYSTEM.Read_Ev(10046, ALevel);
  if ALevel = 0 then
    DBMS_OUTPUT.Put_Line('sql_trace is off');
  else
    DBMS_OUTPUT.Put_Line('sql_trace is on');
  end if;
end;
/

Juste une sorte de traduction http://www.sql.ru/faq/faq_topic.aspx?fid=389 L'original est plus complet, mais c'est quand même mieux que ce que les autres ont posté, à mon avis.

Answer 3

Vu que je viens de voter une question récente comme étant un doublon et que je l'ai dirigée dans cette direction

Quelques autres - dans SQL*Plus - SET AUTOTRACE ON - donneront un plan d'explication et des statistiques pour chaque déclaration exécutée.

TOAD permet également le profilage côté client.

L'inconvénient de ces deux méthodes est qu'elles ne vous indiquent que le plan d'exécution de l'instruction, mais pas comment l'optimiseur est parvenu à ce plan - pour cela, vous aurez besoin d'un traçage côté serveur de niveau inférieur.

Les instantanés de Statspack sont un autre élément important à comprendre : ils constituent un bon moyen d'examiner les performances de la base de données dans son ensemble. Les plans d'exploration, etc., sont utiles pour trouver les instructions SQL individuelles qui constituent des goulots d'étranglement. Statspack est bon pour identifier le fait que votre problème est qu'une simple instruction avec un bon plan d'exécution est appelée 1 million de fois en une minute.

Answer 4

EXPLIQUER LE PLAN et tkprof

http://www.dbspecialists.com/files/presentations/use_explain.html

De nombreux utilitaires (par exemple TOAD, Oralce Enterprise Manager, Oracle SQLDeveloper) disposent d'interfaces qui rendent cette opération plus simple que de nombreux jeux en ligne de commande.

Answer 5

Essayez ceci (c'est également gratuit) : http://www.aboves.com/Statement%5FTracer%5Ffor%5FOracle.exe