[Oracle 9i] Méthode pour tester les performances sur une requête.

Version imprimable

21/09/2007, 11h12
marchand_de_sable

[Oracle 9i] Méthode pour tester les performances sur une requête.

Bonjour à tous.

Je suis en train de faire évoluer un Infocentre, et je revois le plan d'indexation.
J'aimerais pouvoir comparer les performances de certaines requêtes selon les index utilisés.

Le problème est qu'après le 1er lancement de la requête, les enregistrements visés restent dans le cache de la base. Du coup je ne peux pas comparer les temps d'exécution avec les lancements suivants (qui vont directement chercher dans le cache).
Dans mes recherches antérieures, j'ai vu qu'on pouvait vider le cache à l'aide de la commande

Code:

ALTER SYSTEM flush shared_pool;

mais aux vues des temps d'exécution, je n'ai pas l'impression que cette commande change grand chose...

Je suis novice en la matière, et s'il existe une méthodologie pour faire ce travail, ça m'intéresse.
21/09/2007, 11h33
Loyd1974

Faire une trace, utiliser le v$sqlarea, cela donnera les vrais consos, de toute façon, dans la vie de tous les jours, il vaut mieux que les données soient le plus souvent accédées dans la mémoire que de devoir la relire :king:

le mieux serait de lire la doc oracle sur la partie tuning : http://download.oracle.com/docs/cd/B...b14211/toc.htm

Toute la 4ème partie est sur l'optimisation SQL
21/09/2007, 11h34
Loyd1974

pardon, j'avais pas vu que tu étais en 9i, donc la même doc mais en 9i cette fois :

http://download-uk.oracle.com/docs/c...a96533/toc.htm
21/09/2007, 11h40
McM

Citation:

Envoyé par Loyd1974

Faire une trace, utiliser le v$sqlarea, cela donnera les vrais consos, de toute façon, dans la vie de tous les jours, il vaut mieux que les données soient le plus souvent accédées dans la mémoire que de devoir la relire :king:

Dans un datawarehouse, les requetes ne sont généralement lancée qu'une fois. Donc je comprend la demande de marchand_de_sable

Pour tester ton flush, vérifie ce qu'il y a dans v$sqlarea, ça devrait être quasi vide.
21/09/2007, 13h33
marchand_de_sable

Hé ben, faut croire que le flush shared_pool fonctionne... C'est bien censé vider les données du cache au moins ???
Parce que la même requête tourne parfois plus vite après le "vidage" qu'avant...

En tout cas, merci pour vos réponses.

Citation:

Envoyé par Loyd1974

le mieux serait de lire la doc oracle sur la partie tuning : http://download.oracle.com/docs/cd/B...b14211/toc.htm

Toute la 4ème partie est sur l'optimisation SQL

Je vais regarder ça. J'avais espéré...et je sens que j'en ai pour un moment 8O
Cela dit, je ne peux pas optimiser le sql vu qu'il est généré par un outil de reporting. D'où l'idée de se pencher très sérieusement sur les index.

Citation:

Envoyé par McM

Dans un datawarehouse, les requetes ne sont généralement lancée qu'une fois. Donc je comprend la demande de marchand_de_sable

Y'a un peu de ça. Une partie de mon schéma s'apparente à du multidimensionnel. Mais pas uniquement, et les différentes requêtes sont nombreuses et variées, donc il ne faut pas compter sur le fait que les données sollicitées soit déjà dans le cache au moment d'en lancer une. Il faut que le temps de réponse soit satisfaisant dans tous les cas.

Sinon, quelle différences entre le v$sql et v$sqlarea ? Le 1er semble contenir les mêmes infos que l'autre, en plus fourni. Non ?
Quelles sont les infos importantes à visualiser pour l'optimisation ?
21/09/2007, 13h51
McM

En fait pour optimiser, c'est pas uniquement le temps qui compte, c'est le nombre de blocs parcourus, le style de parcours et le type (buffer ou disk).
Ensuite le flush ne va pas vider le cache de ton disque, mais la shared pool (buffer des ordres sql).

Au niveau développement, je dirais que le plus simple pour optimiser :
- Explain Plan
- Auto trace (pour les requetes sous TOAD, c'est super simple)
ou trace avec tkprof
21/09/2007, 14h22
marchand_de_sable

Citation:

Envoyé par McM

En fait pour optimiser, c'est pas uniquement le temps qui compte, c'est le nombre de blocs parcourus, le style de parcours et le type (buffer ou disk).

Arff, j'imagine que tant que je n'aurais pas consulter la doc sur l'optimisation, je ne comprendrais pas vraiment de quoi tu parles... :aie:

Citation:

Envoyé par McM

Ensuite le flush ne va pas vider le cache de ton disque, mais la shared pool (buffer des ordres sql).

Et les données des requêtes précédentes, elles sont dans le shared_pool ou dans le cache du disque ??

Citation:

Envoyé par McM

Au niveau développement, je dirais que le plus simple pour optimiser :
- Explain Plan
- Auto trace (pour les requetes sous TOAD, c'est super simple)
ou trace avec tkprof

L'Explain Plan, je le regarde, mais bon, je ne sais pas vraiment quoi en faire. Disons que je me doute bien qu'un FAST SCAN sur l'index est préférable à un FULL SCAN sur la table, mais de la à savoir comparer un HASH JOIN (OUTER) à un NESTED LOOPS (OUTER)...
L'Auto trace, c'est quoi ? On s'en sert comment ?

Encore merci, et désolé pour toutes ces questions de novice...:oops:

pour la trace sous sqlplus :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
>set autotrace traceonly
>select 1 from dual;
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'DUAL'
 
 
 
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        300  bytes sent via SQL*Net to client
        495  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Faut regarder les consistent gets
Même si les données sont dans le cache, ce nombre ne variera que peu entre 2 lancements.

21/09/2007, 14h51
marchand_de_sable

OK merci.

Je vais regarder ça et potasser la doc oracle sur l'optimisation.

A+