Oracle : Utilisation de l'outil TKPROF

Présentation de l'outils TKPROF qui est l’un des outils les plus utile permettant aux DBA oracle d'analyser le fichier de trace SQL et de générer des rapports qui représentent l'information "tracée" sous une forme lisible, d’identifier et de résoudre les insuffisances de performance et faire une optimisation.

Transcript

1. Utilisation de l’outils TKPROF Présenté par: Mouhammed DIOP Fatou Bintou NDOYE Bocar SY 1
2. • Introduction • Présentation de tkprof • Utilisation de TKPROF • Cas pratique d’utilisation de TKPROF 2
3. • TKPROF est l’un des outils les plus utile permettant aux DBA oracle d'analyser le fichier de trace SQL et de générer des rapports qui représentent l'information "tracée" sous une forme lisible, d’identifier et de résoudre les insuffisances de performance et faire une optimisation. 3
4. • TKPROF est un utilitaire qui est invoqué au niveau du système d'exploitation dans le but d'analyser le fichier de trace SQL et de générer des rapports qui représentent l'information "tracée" sous une forme lisible. 4
5. • Tkprof sera généralement utilisé, en faisant des recherches pour une question de performance très particulière. • Le traçage de session et tkprof peuvent être utilisés pour voir exactement à ce qui se passe sur la base de données, permettant au DBA de prendre l'action corrective. 5
7. • Préparation de l’environnement • Execution 7
8. • Type de traçage: Session  instance • Taille fichier trace max_dump_file_size • Localiser le fichier trace: user_dump_dest • Informations temporelles: timed_statistics 8
9. • TKPROF est un binaire. Il ne peut donc être appelé sous SQL*PLUS. • Pour l’exécuter il suffit de lancer une fenêtre de commande et d’appeler le binaire. • Ce dernier se trouve dans le répertoire suivant: • La syntaxe est la suivante: TKPROF nom_fichier_entrée.trc nom_fichier_sortie.prf [options] 9
11. • Localisation du fichier trace • Positionnement des informations temporelles à true(information temporelles) • Activation du traçage show parameter user_dump_dest alter session timed_statistics=true; alter session sql_trace=true; ou Paramètre INIT.ora : sql_trace=true (pour tracer une instance) 11 ALTER SESSION SET TRACEFILE_IDENTIFIER= MONFICHIER
12. • Exécution de la requête • Extrait du fichier trace obtenu Select * from employe where num=87933; 12
13. • Formatage du fichier 13
14. TKPROF: Release 10.2.0.3.0 - Production on Mar. Mars 16 18:46:01 2010 Copyright (c) 1982, 2005, Oracle. All rights reserved. Trace file: C:\oracle\product\10.2.0\admin\fatou\udump\fatou_ora_4768_monfichier.trc Sort options: default ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call select * from employe where num=87933 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 94 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.09 0.52 1487 4937 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.09 0.53 1487 5031 0 1 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: SYS 14
15. • Le temps CPU Il est à surveiller ce temps CPU ainsi que le temps elapse .En effet, le temps elapse peut être important à cause de facteurs extérieurs au select (comme un lock, par exemple) ou de problèmes de tuning de base. • Le nombre de blocks lus =Query+Current . Le nombre de blocks lus est toujours un signe que le sql est coûteux. Le temps CPU peut être faible (si le serveur est une très rapide machine), le nombre de block ne mentira pas • Rows C’est un indicateur important : si le select lit 1 million de block pour ramener un million de lignes, cela peut être normal, par contre si le select lit un million de block pour ramener une ligne, alors le select est coûteux. 15
16. select * from employe where num=87933 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.03 0.05 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 0.00 0.03 4 5 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.03 0.08 4 5 0 1 Misses in library cache during parse: 1 Optimizer mode: ALL_ROWS Parsing user id: SYS create index idxemp on Employe(num) Dans l’exemple précédent pour une requête ciblée on a parcouru un grand nombre de blocks ce qui nous pousse à une optimisation en posant un index sur l’attribut num 16
17. Pour les personnes qui désirent approfondir le sujet, il y a bien entendu la documentation officielle du manuel d'oracle9i: Performance Guide and Reference et Database Tuning with the Oracle Tuning Pack (Analyse avec un assistant graphique); "Oracle SQL Tuning Pocket Reference" aux éditions O'REILLY ; et le site d'Oracle metalink– auxquelles on pourra toujours se référer pour de plus amples connaissances. 17
18. 18 Merci