Discussion :

[marchand_de_sable]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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

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

[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

[McM]

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

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.

[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.

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
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.

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 ?

[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

[marchand_de_sable]

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...

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 ??

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...

[McM]

pour la trace sous sqlplus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[marchand_de_sable]

OK merci.

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

A+