Bonjour,
Les performances, toujours les performances... Le nerf de la guerre pour beaucoup d'entre nous.
Mais comme pour un virus, il est toujours plus facile de le traiter quand on sait à qui on n'a à faire
Au passage, je rappelle qu'il existe des outils fournis par ORACLE (Statspack, AWR,...)
Et jr rappelle également qu'il existe une règle (non absolue) qui veut que 80 % des problèmes de performance
proviennent de requêtes mal écrite et donc consommatrices.
Il serait donc interessant de pouvoir extraire très rapidement ces fameuses requêtes afin de pouvoir
les traiter.
Oracle, notre bienfaiteur nous donne le moyen d'interroger une vue pour cela.
Il s'agit de v$sqlarea.
Bien évidemment, il faut se connecter avec un utilisateur ayant des droits sur cette vue. Si vous n'avez pas accès au compte system, demandez gentillement à votre DBA de vous créer un utilisateur ayant accès à ce type de vue.
Normalement, il devrait le faire puisque à l'avenir ca lui fera moins de travail.
Requête d'intérrogation:
Pour executer cette requête, je vous conseille d'utiliser ORACLE SQL Developer (outil gratuit téléchargable sur le site d'oracle)
http://www.oracle.com/technology/software/products/sql/index.html
Vous pouvez utiliser tout autre outil capable de lire facilement les clob.
SELECT Sql_FullText,(cpu_time/100000) "Cpu Time (s)",
(elapsed_time/1000000) "Elapsed time (s)",
fetches,buffer_gets,disk_reads,executions
FROM v$sqlarea
WHERE Parsing_Schema_Name ='UU';
Quelles informations tirons nous de cette requête ?
- Le text (entier) de la requête sql
- Le temps cpu en s
- Le temps d'execution en s
- Le nombre de lignes retournées.
- Le nombre de blocs accédés en mémoire.
- Le nombre de lectures disques
- Le nombre de fois ou cette requête a été executé.
Par ailleurs, j'ai inclus une clause where sur la colonne Parsing_Schema_Name afin d'isoler les requêtes d'un user ORACLE particulier.
Ce qui nous évite toutes les requêtes SYSTEM.
Quelques pistes:
- A partir du résultat, vous pouvez facilement extraire les requêtes qui consomment anormalement.
D'un point de vue "editeur de logiciel", ce type de requête permet de mettre facilement certains scheminements "bizarres" pour arriver à un résultat.
- Indépendamment du temps d'executions, il peut être interessant de comparer le cpu_time et le elapsed_time.
Un tros gros écart entre les deux signifie des délais d'attentes qui peuvent être divers (accès disques, verrous,...)
- On peut également surveiller les requêtes qui sont executées de nombreuses fois (parfois plusieurs millions de fois).
si il s'agit de requetes sur des tables statitques, on pourra gerer cette information en cache (au niveau logiciel).
- Toujours dans le cas de requêtes avec jointures executées de très nombreuses fois sur des tables statiques. On pourra créer des vues materialisées pour éliminer le cout de la jointure.
- Si pour une application donnée on s'est fixé des objectifs de performance (un doux rêve), on peut rechercher toutes les requêtes qui ne correspondent pas à ces critères de performance (ex: toutes les requêtes ayant un temps cpu > 1s).
- un nombre elevé de buffer_gets + disk_reads, peut indiquer un scan complet d'une table volumineuse et donc peut être l'absence d'indexes ou de statistiques qui ne sont pas à jour sur cette table.
Comme vous pouvez le voir, cette simple petite requête permet de se poser pas mal de questions et apportent parfois des réponses.
L'optimisation est un combat de tous les jours.
N'abandonnez pas, ne faiblissez pas !
LAO.
