Ressources, temps de réponse, requète ...

**_____M_____** · 30/03/2004, 10h20

Bonjour,
Mon premier post sur ce forum que je lis depuis déjà qq temps.

J'ai une question concernant la quantité de ressources utilisée par Oracle 817/9iR2 sous W2K, Linux, ou un autre unix.

Ma requète utilise des sous select dans le from et des jointures externes
sur ces sous requètes. (La requète est assez longue, je ne la colle pas mais je peux l'envoyer si besoin)

D'un point de vue plan, tout parait normal, c'est à dire création de vues dynamiques, mais le temps de réponse sur des volumétries importantes
est très important (de l'ordre de la minute)

Il faut savoir que ces requètes sont générées "à la volée" par un logiciel et qu'elles sont systématiquement reparsées.

Voici ma question :
Lorsque j'execute ma requète, toutes les ressources machines sont utilisées par Oracle.
De plus ma machine est puissante, plus il y a de mémoire plus le problème est flagrant !!!

Sur quels paramètres Oracle / système puis je jouer afin de palier à ce problème ?

Merci de votre aide

Mathieu

**Marc Musette** · 30/03/2004, 11h11

générer à la volée = ???

une des base de l'optimisation est de réutiliser le plus souvent possible les plans d'exécution d'une requête --> il faut pour cela utiliser des bind variables

de mauvaises performances sont bien souvent liées à l'application et non à la configuration matérielle

lorsque tu rajoutes de la ram, modifies-tu les paras d'initialisation de ta db ??

as-tu seulement une db oracle qui tourne sur ce server ?

sache également qu'un trop grand shared area est néfaste

il n'y a pas vraiment de recettes ou formules miracles : que des tests et surtout pas mal d'expérience (via forum interposé, c'est un peu long à expliquer)

donne nous au moins les détails de ta mémoire (SHOW SGA command sous sql*plus

merci

**_____M_____** · 30/03/2004, 15h17

Le terme "généré à la volée" vient d fait que j'utilise les apis d'un logiciel qui génére la requète en fonction de paramètres.
Donc pour le moment je ne peux pas modifier la requète que j'utilise.
Par contre, je vois bien qu'Oracle utilise toutes les ressources disponibles pour executer cette requete.

Je ne suis pas un spécialiste des paramètres de l'init.ora, d'où ma question.
J'essaie de faire avancer le plus vite possible une base.
J'espère que les qq parametres qui suivent sont suffisants pour donner une piste pour mes recherches.

J'utilise Orasnap afin d'obtenir quelques infos sur la répartition de la mémoire (entre autre).

C'est une base 8.1.7.4

Voici donc quelques parametres

cpu_count ............. 2
db_block_buffers ... 102400
db_block_size ........ 4096
db_file_direct_io_count ... 64
db_file_multiblock_read_count ... 8
hash_area_size ... 4194304
hash_join_enabled ... TRUE
hash_multiblock_io_count ... 8
java_pool_size ... 20000K
shared_pool_reserved_size ... 1572864
shared_pool_size ... 31457280
sort_area_retained_size ... 0
sort_area_size ... 524288

Information SGA
Fixed Size ... 75,804
Variable Size ... 70,615,040
Database Buffers ... 419,430,400
Redo Buffers ... 77,824
TOTAL SGA ... 490,199,068

Buffer Hit Ratio
Consistent Gets | DB Blk Gets | Physical Reads | Hit Ratio
7,546,852,710 | 7,805,836 | 1,833,396 | 99,976

Library Cache Hit Ratio
Executions | Execution Hits | Hit Ratio | Misses | Hit Ratio
4,373,572 | 4,245,621 | 97,074 | 1,511 | 99,965

Data Dictionary Hit Ratio
Gets | Cache Misses | Hit Ratio
1,542,815 | 4,602 | 99,702

Merci pour vos réponses

**SheikYerbouti** · 30/03/2004, 15h28

Vos ratios semblent excellents...

Comme le rappelle justament Marc, les problèmes viennent souvent principalement des requêtes.
En affichant les traces ou les plans d'exécution, vous avez des chances de vérifier l'absence ou la non utilisation d'index qui peuvent être responsables de vos problèmes.

**_____M_____** · 30/03/2004, 16h30

Je comprend bien, c'est juste que je ne voulais pas mettre 3 tonnes de lignes dans le post.

Donc voici, ça aide, on peut voir des full scan, mais je ne peux les enlever qu'en forçant les index ou en passant en mode RULE.
(Le temps de réponse est alors encore plus dégradé)

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
37
38
39
40
41
42
43
44
45
 
SELECT T.id, N.name, W.procedure_id, I.name, R.name,
       TV1.variable, TV1.type, TV1.value, TV2.variable, TV2.type, TV2.value,
       TV3.variable, TV3.type, TV3.value, TV4.variable, TV4.type, TV4.value,
       'NOT_USED',   0,        'NOT_USED',
       CV1.variable, CV1.type, CV1.value,  CV2.variable, CV2.type, CV2.value,
       'NOT_USED',   0,        'NOT_USED', 'NOT_USED',   0,        'NOT_USED',
       'NOT_USED',   0,        'NOT_USED'
  FROM node N,
       Actor I,
       CATEGORY R,
       ( SELECT tcid, variable, value, type FROM case_variable WHERE variable = ( 'VAR1' ) ) TV1,
       ( SELECT tcid, variable, value, type FROM case_variable WHERE variable = ( 'VAR2' ) ) TV2,
       ( SELECT tcid, variable, value, type FROM case_variable WHERE variable = ( 'VAR3' ) ) TV3,
       ( SELECT tcid, variable, value, type FROM case_variable WHERE variable = ( 'VAR4' ) ) TV4,
       ( SELECT tcid, variable, type, value FROM case_variable WHERE variable = ( 'VAR5' ) ) CV1,
       ( SELECT tcid, variable, type, value FROM case_variable WHERE variable = ( 'VAR6' ) ) CV2,
       workcase W,
       task T
 WHERE ( T.actor_id = 2863
      OR ( ( T.role_id IN ( SELECT actor_role.role_id FROM actor_role WHERE actor_role.actor_id = 2863
                            UNION
                            SELECT role_hierarchy.sub_role_id FROM role_hierarchy, CATEGORY, actor_role
                             WHERE role_hierarchy.sub_role_id = CATEGORY .id
                               AND CATEGORY.name LIKE 'role%'
                               AND role_hierarchy.upper_role_id = actor_role.role_id
                               AND actor_role.actor_id = 2863
                          )
           )
           AND actor_id IS NULL
         )
       )
   AND T.state < 7
   AND T.proc_name LIKE 'proc%'
   AND TV1.tcid ( + ) = T.id
   AND TV2.tcid ( + ) = T.id
   AND TV3.tcid ( + ) = T.id
   AND TV4.tcid ( + ) = T.id
   AND CV1.tcid ( + ) = T.workcase_id
   AND CV2.tcid ( + ) = T.workcase_id
   AND N.id = T.node_id
   AND W.id = T.workcase_id
   AND I.id = W.initiator_id
   AND R.id = W.resp_role_id
 ORDER BY T.priority DESC, T.creation_date ASC

Le plan :

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
37
38
39
40
41
 
SELECT STATEMENT   **CHOOSE**  Cost=68
  SORT ORDER BY 
    FILTER  
      HASH JOIN OUTER 
        HASH JOIN OUTER 
          HASH JOIN  
            HASH JOIN  
              TABLE ACCESS FULL W4COB.CATEGORY **ANALYZED**
              NESTED LOOPS  
                HASH JOIN OUTER 
                  HASH JOIN OUTER 
                    HASH JOIN OUTER 
                      HASH JOIN OUTER 
                        HASH JOIN  
                          TABLE ACCESS FULL W4COB.TASK **ANALYZED**
                          TABLE ACCESS FULL W4COB.NODE **ANALYZED**
                        TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
                          INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
                      TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
                        INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
                    TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
                      INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
                  TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
                    INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
                TABLE ACCESS BY INDEX ROWID W4COB.WORKCASE **ANALYZED**
                  INDEX UNIQUE SCAN W4COB.SYS_C008543
            TABLE ACCESS FULL W4COB.ACTOR **ANALYZED**
          TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
            INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
        TABLE ACCESS BY INDEX ROWID W4COB.CASE_VARIABLE **ANALYZED**
          INDEX RANGE SCAN W4COB.INX_VARIABLE_INDEX
      SORT UNIQUE 
        UNION-ALL  
          INDEX UNIQUE SCAN W4COB.SYS_C008561
          NESTED LOOPS  
            NESTED LOOPS  
              TABLE ACCESS BY INDEX ROWID W4COB.CATEGORY **ANALYZED**
                INDEX UNIQUE SCAN W4COB.SYS_C008559
              INDEX FAST FULL SCAN W4COB.SYS_C008546
            INDEX UNIQUE SCAN W4COB.SYS_C008561

Power Explain permet d'avoir plus d'infos mais je n'arrive pas à les récupérer pour les coller ici.
D'un point de vue volumétrie :

SQL> select count(*) from node; 536
SQL> select count(*) from task; 28 969
SQL> select count(*) from case_variable; 1 476 788
SQL> select count(*) from workcase; 7 764

Sinon j'ai essayé de partitionner Table et Index de la table CASE_VARIABLE qui est lue le plus souvent et les résultats sont interessants.

Merci de votre aide

**SheikYerbouti** · 30/03/2004, 17h03

Vous n'avez pas indiqué la volumétrie de la table CATEGORIE

**orafrance** · 30/03/2004, 17h23

Envoyé par _____M_____

Sinon j'ai essayé de partitionner Table et Index de la table CASE_VARIABLE qui est lue le plus souvent et les résultats sont interessants.

Merci de votre aide

MArc_musette va encore bondir

Effectivement, le partitionnement peut aider puisque les collections de données sont plus petites

Pourquoi ne pas remplacer les TVn et CVn par :

Code :

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

1
2
 ( SELECT tcid, variable, value, type FROM case_variable WHERE variable IN ( 'VAR1','VAR2','VAR3','VAR4' ) ) TV,
       ( SELECT tcid, variable, type, value FROM case_variable WHERE variable IN ( 'VAR5', 'VAR6'  ) ) CV,

Parce que les 6 jointures externes ne doivent probablement pas aider Oracle

Il y a un FULL SCAN mais ce n'est pas sûr qu'il soit couteux

**_____M_____** · 30/03/2004, 17h25

SQL> select count(*) from category; 67
SQL> select count(*) from actor; 441

Je profite de ce post, j'ai des infos supplémentaires sur le plan:

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
37
38
39
40
41
42
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=68 Card=40 Bytes=13840)
   1    0   SORT (ORDER BY) (Cost=68 Card=40 Bytes=13840)
   2    1     FILTER
   3    2       HASH JOIN (OUTER) (Cost=65 Card=40 Bytes=13840)
   4    3         HASH JOIN (OUTER) (Cost=60 Card=38 Bytes=11856)
   5    4           HASH JOIN (Cost=54 Card=36 Bytes=10008)
   6    5             HASH JOIN (Cost=51 Card=36 Bytes=9216)
   7    6               TABLE ACCESS (FULL) OF 'CATEGORY' (Cost=1 Card=67 Bytes=1340)
   8    6               NESTED LOOPS (Cost=49 Card=36 Bytes=8496)
   9    8                 HASH JOIN (OUTER) (Cost=31 Card=36 Bytes=7812)
  10    9                   HASH JOIN (OUTER) (Cost=28 Card=34 Bytes=6222)
  11   10                     HASH JOIN (OUTER) (Cost=24 Card=32 Bytes=4768)
  12   11                       HASH JOIN (OUTER) (Cost=21 Card=30 Bytes=3450)
  13   12                         HASH JOIN (Cost=17 Card=28 Bytes=2268)
  14   13                           TABLE ACCESS (FULL) OF 'TASK' (Cost=15 Card=28 Bytes=1540)
  15   13                           TABLE ACCESS (FULL) OF 'NODE' (Cost=1 Card=536 Bytes=13936)
  16   12                         TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  17   16                           INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  18   11                       TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  19   18                         INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  20   10                     TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  21   20                       INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  22    9                   TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  23   22                     INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  24    8                 TABLE ACCESS (BY INDEX ROWID) OF 'WORKCASE'(Cost=1 Card=7764 Bytes=147516)
  25   24                   INDEX (UNIQUE SCAN) OF 'SYS_C008543' (UNIQUE)
  26    5             TABLE ACCESS (FULL) OF 'ACTOR' (Cost=1 Card=441 Bytes=9702)
  27    4           TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  28   27             INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  29    3         TABLE ACCESS (BY INDEX ROWID) OF 'CASE_VARIABLE' (Cost=2 Card=3190 Bytes=108460)
  30   29           INDEX (RANGE SCAN) OF 'INX_VARIABLE_INDEX' (NON-UNIQUE) (Cost=1 Card=3190)
  31    2       SORT (UNIQUE) (Cost=8 Card=4 Bytes=116)
  32   31         UNION-ALL
  33   32           INDEX (UNIQUE SCAN) OF 'SYS_C008561' (UNIQUE) (Cost=1 Card=1 Bytes=8)
  34   32           NESTED LOOPS (Cost=3 Card=3 Bytes=108)
  35   34             NESTED LOOPS (Cost=2 Card=2 Bytes=56)
  36   35               TABLE ACCESS (BY INDEX ROWID) OF 'CATEGORY' (Cost=1 Card=1 Bytes=20)
  37   36                 INDEX (UNIQUE SCAN) OF 'SYS_C008559' (UNIQUE) (Cost=1 Card=1)
  38   35               INDEX (FAST FULL SCAN) OF 'SYS_C008546' (UNIQUE) (Cost=1 Card=2 Bytes=16)
  39   34             INDEX (UNIQUE SCAN) OF 'SYS_C008561' (UNIQUE)

[/code]

**SheikYerbouti** · 30/03/2004, 17h31

Les vues en lignes fonctionnent bien et je ne pense pas qu'elles soient à l'origine du problème.

Par contre je vois des IS NULL, LIKE, UNION...

dans le plan d'exec il y a un SORT UNIQUE suivi par UNION...

UNION ALL aurait peut-être arrangé les choses...

Mais puisque il n'y a pas la main sur la requête, il faut vérifier que les index soient posés, et peut être modifier les fameux paramètres
optimizer_index_cost_adj et optimizer_max_permutations

**orafrance** · 30/03/2004, 17h37

Envoyé par SheikYerbouti

Les vues en lignes fonctionnent bien et je ne pense pas qu'elles soient à l'origine du problème.

certes mais faire 6 requêtes quand on peut en faire 2 (a priori

) c'est dommage

le cout de chacune des jointures externes est assez concéquent pour essayer de le réduire

Il y a bien un index sur TASK.node_id ?

**_____M_____** · 30/03/2004, 17h42

oui, il y a bien un index sur

Task.node_id

et aussi sur

Task.role_id
Task.actor_id
Task.workcase_id
Task.state

ouf !

Mais 2 requetes en lieu et place de 6 ça m'interesse .

**orafrance** · 30/03/2004, 17h59

Comme je le disais, la requête pourrait être de ce style (à vérifier bien sûr

)

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
37
38
39
SELECT T.id, N.name, W.procedure_id, I.name, R.name, 
       DECODE(TV.variable,'VAR1',TV.variable,NULL), DECODE(TV.variable,'VAR1',TV.type,NULL), DECODE(TV.variable,'VAR1',TV.value,NULL), 
       DECODE(TV.variable,'VAR2',TV.variable,NULL), DECODE(TV.variable,'VAR2',TV.type,NULL), DECODE(TV.variable,'VAR2',TV.value,NULL), 
       DECODE(TV.variable,'VAR3',TV.variable,NULL), DECODE(TV.variable,'VAR3',TV.type,NULL), DECODE(TV.variable,'VAR3',TV.value,NULL), 
       DECODE(TV.variable,'VAR4',TV.variable,NULL), DECODE(TV.variable,'VAR4',TV.type,NULL), DECODE(TV.variable,'VAR4',TV.value,NULL), 
       'NOT_USED',   0,        'NOT_USED', 
       DECODE(CV.variable,'VAR5',CV.variable,NULL), DECODE(CV.variable,'VAR5',CV.type,NULL), DECODE(CV.variable,'VAR5',CV.value,NULL), 
       DECODE(CV.variable,'VAR6',CV.variable,NULL), DECODE(CV.variable,'VAR6',CV.type,NULL), DECODE(CV.variable,'VAR6',CV.value,NULL), 
       'NOT_USED',   0,        'NOT_USED', 'NOT_USED',   0,        'NOT_USED', 
       'NOT_USED',   0,        'NOT_USED' 
  FROM node N, 
       Actor I, 
       CATEGORY R, 
       ( SELECT tcid, variable, value, type FROM case_variable WHERE variable IN ( 'VAR1','VAR2' ,'VAR3','VAR4' ) ) TV, 
       ( SELECT tcid, variable, type, value FROM case_variable WHERE variable IN ( 'VAR5' , 'VAR6' ) ) CV, 
       workcase W, 
       task T 
 WHERE ( T.actor_id = 2863 
      OR ( ( T.role_id IN ( SELECT actor_role.role_id FROM actor_role WHERE actor_role.actor_id = 2863 
                            UNION 
                            SELECT role_hierarchy.sub_role_id FROM role_hierarchy, CATEGORY, actor_role 
                             WHERE role_hierarchy.sub_role_id = CATEGORY .id 
                               AND CATEGORY.name LIKE 'role%' 
                               AND role_hierarchy.upper_role_id = actor_role.role_id 
                               AND actor_role.actor_id = 2863 
                          ) 
           ) 
           AND actor_id IS NULL 
         ) 
       ) 
   AND T.state < 7 
   AND T.proc_name LIKE 'proc%' 
   AND TV.tcid ( + ) = T.id 
   AND CV.tcid ( + ) = T.workcase_id 
   AND N.id = T.node_id 
   AND W.id = T.workcase_id 
   AND I.id = W.initiator_id 
   AND R.id = W.resp_role_id 
 ORDER BY T.priority DESC, T.creation_date ASC

Voir même CV et TV réunis aussi

**SheikYerbouti** · 30/03/2004, 18h03

Et bien si le monsieur a accès à la requête, autant aussi modifier AND actor_id IS NULL par Nvl( actor_id,0 = 0 ) et changer le UNION par UNION ALL...

**orafrance** · 30/03/2004, 18h06

c'est peut être pas si simple

La requête est générée mais peut-être y a-t-il moyen de biaisais

En faisant des vues par exemple pour maitriser la requête si c'est possible

EDIT : la modif que je mentionne est peut-être possible en donnant la liste des valeurs au logiciel plutôt qu'une liste d'égalité, voila pourquoi je propose cette modif

**_____M_____** · 31/03/2004, 09h54

Je n'ai pas la main sur la requète mais je peux toujours proposer à l'éditeur des pistes de modif. Et là c'est une bonne piste

Dans mes recherches, J'avais mis des select dans le select pour chaque valeur à chercher et donc plus de jointure externe

Mais c'est vraiment cracra !!
J'ai remarqué que les plans ne sont pas générés pour ce type de requète.

Toujours sur ce meme sujet, est ce qu'on peux voir qq part dans les tables system ou autres vues quelle quantité de mémoire prend ce type de requète.

En clair, ou savoir quelle quntité de mémoire les 2 full intérieurs prennent-ils ?

Code :

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

1
2
3
HASH JOIN 
TABLE ACCESS FULL W4COB.TASK **ANALYZED**
TABLE ACCESS FULL W4COB.NODE **ANALYZED**

J'ai d'autres questions mais plutot orientées sur les paramètres OS et je pense que je posterai sur un autre thread.
Mais qu'en meme : Quelle partie de la mémoire Oracle les vues dynamiques vont-elles utilisées ?
Comment faire pour quelles soient performantes et que l'OS ne swappe pas ? (en cas de charge)

Merci pour toutes ces avancées, ça ouvre des horizons.

**Marc Musette** · 31/03/2004, 15h59

1) je ne suis pas contre le partitionnement ; je dis simplement que partitionner <> "plus rapide dans tous les cas" --> tests

2) utilise tkprof sur une trace pour avoir également des infos sur les temps d'exécutions

3) pour ce qui est des contrôle sur la quantité de mémoire allouées à tes opérations, il convient, je crois, de parcourir la vue v$sql_workarea sur base des données de V$SQL_PLAN (operation_id) et de v$SQL (PARENT_HANDLE, HASH_VALUE et CHILD_NUMBER )

tu dois savoir qu'en cas de sql complexes et couteux ta work_area_size est très importante

sous 9i, il est dès lors extrêmement recommandé d'utiliser l'option pga_aggregate_target où tu spécifies la quantité de mémoire dédiée à la PGA(WORKAREA_SIZE_POLICY = AUTO) avec pour commencer, 1mega par connexion (sort_area_size n'est donc plus nécessaire)

!!! ceci pour autant que tu sois en dedicated server

4) les vues dynamiques fonctionnent à ma connaissance comme les autres vues ; c'est plutôt les tables sur lesquelles elles reposent qui sont différentes : virtuelles et maintenues à jour tout au long de la durée de vie de l'instance par le server Oracle, elles doivent dès lors exister dans la dictionary cache

tu peux voir les stats associées à cette cache via vsrowcache mais sincèrement, l'explication de toutes ces infos est très poussée, voire trop poussée pour ma petite tête

bonne chance, j'espère que ces quelques infos t'aideront

**_____M_____** · 31/03/2004, 16h12

Merci, je pense que déjà mon problème est très (trop) spécifique.

Enfin toutes ces informations m'ont fait avancer et j'ai pas mal de pistes.

merci encore.

Ressources, temps de réponse, requète ...

Administration Oracle

Discussions similaires

Partager

Partager