Discussion :

[devplanete]

J'ai certains traitements qui sont assez longs sur mes postes clients.
Pourtant, quand je lance la même requête sur le serveur, elle est 10x plus rapide (30s sur les clients, 3s sur le serveur oracle).

Voici le plan d'exécution de la requête sur le client :

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
25
26
27
28
29
30
31
32
33
34
35
36
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1445 Card=83378 Byte
          s=6169972)
 
   1    0   SORT (ORDER BY) (Cost=1445 Card=83378 Bytes=6169972)
   2    1     HASH JOIN (OUTER) (Cost=428 Card=83378 Bytes=6169972)
   3    2       HASH JOIN (OUTER) (Cost=331 Card=83378 Bytes=5169436)
   4    3         HASH JOIN (OUTER) (Cost=246 Card=83378 Bytes=4252278
          )
 
   5    4           TABLE ACCESS (FULL) OF 'TABLE1' (Cost=1
          75 Card=83378 Bytes=3335120)
 
   6    4           TABLE ACCESS (FULL) OF 'TABLE2' (Cost=4 Card=695
          Bytes=7645)
 
   7    3         TABLE ACCESS (FULL) OF 'TABLE2' (Cost=4 Card=695 By
          tes=7645)
 
   8    2       TABLE ACCESS (FULL) OF 'TABLE3' (Cost=2 Card=41 Byte
          s=492)
 
Statistics
----------------------------------------------------------
          0  recursive calls
         13  db block gets
       1190  consistent gets
       2074  physical reads
          0  redo size
    7244483  bytes sent via SQL*Net to client
     729257  bytes received via SQL*Net from client
      11130  SQL*Net roundtrips to/from client
          0  sorts (memory)
          1  sorts (disk)
      83446  rows processed

Voici le plan d'exécution de la requète sur le serveur:

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
25
26
27
28
29
30
31
32
33
34
35
36
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1445 Card=83378 Byte
          s=6169972)
 
   1    0   SORT (ORDER BY) (Cost=1445 Card=83378 Bytes=6169972)
   2    1     HASH JOIN (OUTER) (Cost=428 Card=83378 Bytes=6169972)
   3    2       HASH JOIN (OUTER) (Cost=331 Card=83378 Bytes=5169436)
   4    3         HASH JOIN (OUTER) (Cost=246 Card=83378 Bytes=4252278
          )
 
   5    4           TABLE ACCESS (FULL) OF 'TABLE1' (Cost=1
          75 Card=83378 Bytes=3335120)
 
   6    4           TABLE ACCESS (FULL) OF 'TABLE2' (Cost=4 Card=695
          Bytes=7645)
 
   7    3         TABLE ACCESS (FULL) OF 'TABLE2' (Cost=4 Card=695 By
          tes=7645)
 
   8    2       TABLE ACCESS (FULL) OF 'TABLE3' (Cost=2 Card=41 Byte
          s=492)
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1190  consistent gets
        930  physical reads
          0  redo size
    4757780  bytes sent via SQL*Net to client
      61697  bytes received via SQL*Net from client
       5565  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      83452  rows processed

Le volume de données envoyé par SQL*Net est beaucoup + petit sur le serveur (est-ce que mon réseau peut-être en cause ?).
Enfin sur le serveur le tri est fait en mémoire alors qu'il est fait sur le disque pour le client.

Bref, je fais appelle à vous pour m'aidez à analyser ces rapports.

Merci de votre aide.

[fatsora]

Bonjour,

C'est quel OS que tu utilises ?

Il y a des parametres a configurer en foncion de l'OS ...

Sinon en Oracle pur

Quel type client Oracle tu utilise pour te connecter : (php,sqlplus ,java, ...)

[13thFloor]

Un souci avec l'arraysize ?
Essaies, sous SQL+, de modifier le paramètre arraysize : set arraysize 200 avant de lancer ta requête et compare le temps de réponse obtenu avec le temps précédent. Tu peux essayer également de positionner l'arraysize un poil plus grand. La valeur par défaut (15) est souvent bien trop petite.
Lances ta requête avec un event 10046 en level 8 afin de voir ou se situent les attentes (je parierais pour du réseau) :

Code :

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

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

Le fichier généré sera dans le répertoire défini par le paramètre user_dump_dest.

[fatsora]

Un souci avec l'arraysize ?
Essaies, sous SQL+, de modifier le paramètre arraysize : set arraysize 200 avant de lancer ta requête et compare le temps de réponse obtenu avec le temps précédent. Tu peux essayer également de positionner l'arraysize un poil plus grand. La valeur par défaut (15) est souvent bien trop petite.
Lances ta requête avec un event 10046 en level 8 afin de voir ou se situent les attentes (je parierais pour du réseau) :

Code :

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

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

Le fichier généré sera dans le répertoire défini par le paramètre user_dump_dest.

Et si le client n'est pas sqlplus ?

[13thFloor]

Si c'est du java c'est le paramètre setDefaultRowPrefetch à augmenter.
Sql+ permettra de tester le temps de réponse client et serveur car cet outil est présent sur les 2 (en principe).
Cela permettra d'isoler la piste réseau.
Il faudra sans doute optimiser le paramètre tdu du listener et du tnsnames s'il n'est pas possible d'accroître l'arraysize de l'outil client de connexion à la base.
C'est clair que coté client, les requêtes ne doivent pas être envoyées sous sql+.

[devplanete]

Serveur : Windows 2003 R2 SP2 et oracle 9.2i
Clients : Windows 2000 Pro avec Client Oracle 9.0.1 i.

J'utilise bien sqlplus pour mes tests (java pas utilisé).

je vais tester set arraysize 200 et ALTER session SET events '10046 trace name context forever, level 8'; je vous tiens au courant.

Merci pour ces pistes