Principes de base d'optimisation de requête

**SheikYerbouti** · 22/11/2008, 08h17

Conernant l'ordre des colonnes dans un index composite, cela était important au moment de l'écriture de l'article. En effet, jusqu'en (de mémoire) 9i, l'ordre des colonnes était discriminatif pour l'utilisation de l'index. Si la recheche portait sur une autre partie de la clé que la première, l'index n'était tout simplement pas utilisé. Aujourd'hui, ce n'est plus le cas.
S'il est vrai qu'il faut rappeler à quel point l'optimisation se nourrit de beaucoup de paramètres, et que les moyens mis en oeuvre peuvent être très différents d'un système à l'autre, certains "principes de base" (car c'est bien le titre donnée par le posteur initial) demeurent, et restent "vrais" même si les nouvelles versions de l'optimisateur "récupèrent" de mieux en mieux les "conneries" de certains développeurs.

**Bruno2r** · 22/11/2008, 12h41

Bojour à tous,
Très intéressante discussion.
Justement je me demandais pourquoi vous n'évoquiez pas plus tôt l'impact de ... la version Oracle.

C'est en cela que le tuto (fort bien expliqué) peut être incomplet et non pas obsolète.
Au boulot, j'ai des Bases en V7, 8, 10g dont je ne suis pas propriétaire il est donc important de savoir comment procéder au mieux dans chacune d'elles.

**Emmanuel Lecoester** · 22/11/2008, 16h23

Envoyé par Bruno2r

Au boulot, j'ai des Bases en V7, 8, 10g dont je ne suis pas propriétaire

ben merde alors

la 7 n'est plus maintenue par oracle depuis combien de temps ?

**mnitu** · 23/11/2008, 15h32

Envoyé par SheikYerbouti

Conernant l'ordre des colonnes dans un index composite, cela était important au moment de l'écriture de l'article. En effet, jusqu'en (de mémoire) 9i, l'ordre des colonnes était discriminatif pour l'utilisation de l'index. Si la recheche portait sur une autre partie de la clé que la première, l'index n'était tout simplement pas utilisé. Aujourd'hui, ce n'est plus le cas.
S'il est vrai qu'il faut rappeler à quel point l'optimisation se nourrit de beaucoup de paramètres, et que les moyens mis en oeuvre peuvent être très différents d'un système à l'autre, certains "principes de base" (car c'est bien le titre donnée par le posteur initial) demeurent, et restent "vrais" même si les nouvelles versions de l'optimisateur "récupèrent" de mieux en mieux les "conneries" de certains développeurs.

Malheureusement ni à cette époque, ce conseil n'était pas correct. Mais, je dois vous avouer que à l'époque j'étais mois aussi convaincu que c'est vrai. Plus tard j'ai trouvé un test proposé par Tom Kyte pour Oracle 8 (et repris pour Oracle9 et 10) et encore plus tard j'ai compris le mécanisme qui m'a fait tiré cette mauvaise conclusion. Le mécanisme que vous décrivez du mémoire et qui est apparu en Oracle 9 concerne une nouvelle méthode d'accès qui est l'index skip scan mais cella n'a rien à voir avec la sélectivité des colonnes d'un index composé. En fait plutôt le contraire est vrai vu la possibilité d'utiliser la compression des indexes.

Pour dissiper toute malentendu je déclare que je porte le respect qui se doit à votre travail concernant les tutoriels que vous avez rédigé. Mais cela ne m'empêche pas de me poser certaines questions, voir de ne pas être d'accord toujours avec vous, bien sûr dans un sens constructif. Prenons aussi ce conseil

Si vous utilisez des curseurs ou du SQL dynamique, ne codez pas vos instructions avec des
valeurs en dur, ce qui empêche la réutilisation du code SQL dans le pool partagé. Utilisez des
variables liées.

Il est vrai que pour des applications OLTP ce conseil est correct, mais à ce que j'ai compris le contraire est toute à fait vrai pour les DSS.

Et j'ai un peu aussi du mal avec ce conseil:

Si vous devez créer des tables et les alimenter, regroupez l’opération
Create table X ( col1 number, col2 varchar2(30) … ) ;
Insert into X select col1, col2 from Y … ; -- Mauvais
Create table X ( col1 number, col2 varchar2(30) … ) as select col1,
col2 from Y … ; -- Bon

Pourriez-vous expliquer que est-ce qu'on gagne effectivement ?

**Waldar** · 24/11/2008, 11h41

Envoyé par mnitu

Pourriez-vous expliquer que est-ce qu'on gagne effectivement ?

Sur ce dernier point je peux répondre, le CREATE AS SELECT ne passe pas par les rollback segment, et est donc nettement plus rapide que CREATE TABLE + INSERT / COMMIT.

Ca se ressent sur les volumétries fortes, par contre c'est plutôt à utiliser pour des tables temporaires ou de travail sur lesquelles aucune référence ne pointe.

**SheikYerbouti** · 24/11/2008, 16h56

Code :

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

1
2
3
4
5
6
7
8
9
SQL*Plus: Release 9.0.1.3.0 - Production on Lu Nov 24 16:54:08 2008
 
(c) Copyright 2001 Oracle Corporation.  All rights reserved.
 
 
Connecté à :
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production

Code :

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

1
2
CREATE TABLE TEST3 (col1 NUMBER, col2 NUMBER, col3 NUMBER)
/

Code :

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

1
2
3
4
5
6
7
8
9
10
11
BEGIN
FOR i IN 1..1000 LOOP
  INSERT INTO TEST3 VALUES
  (
    ROUND(dbms_random.VALUE(1, 1000)),
    ROUND(dbms_random.VALUE(1, 1000)),
    ROUND(dbms_random.VALUE(1, 1000))        
  );
END LOOP;
END;
/

Indexes créés sur cette table:

Code :

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

1
2
3
4
5
6
7
Tablespace   Table Name                                 Nb   Column
Owner   Name         Index Name                                Ext U Name                 Pos
------- ------------ ---------------------------------------- ---- - -------------------- ---
XXXXX   YYYY     A   TEST3.ID_COL1                               1 N COL1                   1
                     TEST3.ID_COL123                             1 N COL1                   1
                                                                   N COL2                   2
                                                                   N COL3                   3

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
SQL> set autot traceonly
SQL> SELECT * FROM TEST3  WHERE col1 BETWEEN 48 AND 52;
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   INDEX (RANGE SCAN) OF 'ID_COL123' (NON-UNIQUE)
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        703  bytes sent via SQL*Net to client
        651  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed
 
SQL> SELECT * FROM TEST3  WHERE col3 BETWEEN 48 AND 52 ;
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'TEST3'
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          6  consistent gets
          0  physical reads
          0  redo size
        710  bytes sent via SQL*Net to client
        651  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          4  rows processed

l'index 2 sur clé composite n'est clairement pas utilisé lorsque la recherche ne porte pas sur la première partie de la clé.

**mnitu** · 24/11/2008, 19h14

Envoyé par Waldar

Sur ce dernier point je peux répondre, le CREATE AS SELECT ne passe pas par les rollback segment, et est donc nettement plus rapide que CREATE TABLE + INSERT / COMMIT.

Ca se ressent sur les volumétries fortes, par contre c'est plutôt à utiliser pour des tables temporaires ou de travail sur lesquelles aucune référence ne pointe.

Je viens de faire ce test qur une base 11g. Je suis d'accord que ça génére nettement moins de rollback mais je ne vois pas une grosse différence en temps d'exécution.

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
 
SQL> set timi on
SQL> select b.value
  2    from v$statname a, v$mystat b
  3   where a.statistic# = b.statistic#
  4    and a.name = 'redo size'
  5  /
 
     VALUE
----------
      2076
 
EcoulÚ : 00 :00 :00.03
SQL> create table t_redo as
  2    select * from all_objects
  3  /
 
Table crÚÚe.
 
EcoulÚ : 00 :00 :10.01
SQL> select b.value
  2    from v$statname a, v$mystat b
  3   where a.statistic# = b.statistic#
  4    and a.name = 'redo size'
  5  /
 
     VALUE
----------
    166696
 
EcoulÚ : 00 :00 :00.01
SQL> create table t_redo2(
  2  OWNER                                     VARCHAR2(30),
  3  OBJECT_NAME                               VARCHAR2(30),
  4  SUBOBJECT_NAME                            VARCHAR2(30),
  5  OBJECT_ID                                 NUMBER,
  6  DATA_OBJECT_ID                            NUMBER,
  7  OBJECT_TYPE                               VARCHAR2(19),
  8  CREATED                                   DATE,
  9  LAST_DDL_TIME                             DATE,
 10  TIMESTAMP                                 VARCHAR2(19),
 11  STATUS                                    VARCHAR2(7),
 12  TEMPORARY                                 VARCHAR2(1),
 13  GENERATED                                 VARCHAR2(1),
 14  SECONDARY                                 VARCHAR2(1),
 15  NAMESPACE                                 NUMBER,
 16  EDITION_NAME                              VARCHAR2(30)
 17  )
 18  /
 
Table crÚÚe.
 
EcoulÚ : 00 :00 :00.02
SQL> select b.value
  2    from v$statname a, v$mystat b
  3   where a.statistic# = b.statistic#
  4    and a.name = 'redo size'
  5  /
 
     VALUE
----------
    189056
 
EcoulÚ : 00 :00 :00.01
SQL> insert into t_redo2
  2  select * from all_objects
  3  /
 
68230 ligne(s) crÚÚe(s).
 
EcoulÚ : 00 :00 :09.94
SQL> select b.value
  2    from v$statname a, v$mystat b
  3   where a.statistic# = b.statistic#
  4    and a.name = 'redo size'
  5  /
 
     VALUE
----------
   8427396
 
EcoulÚ : 00 :00 :00.01
SQL> commit
  2  /
 
Validation effectuÚe.
 
EcoulÚ : 00 :00 :00.06
SQL> select b.value
  2    from v$statname a, v$mystat b
  3   where a.statistic# = b.statistic#
  4    and a.name = 'redo size'
  5  /
 
     VALUE
----------
   8427520
 
EcoulÚ : 00 :00 :00.01

**pacmann** · 24/11/2008, 19h20

Envoyé par SheikYerbouti

[tests sur le skip scan, je suppose]

Col1 et Col2 sont assez sélectives... utiliser l'index reviendrait à lire une bonne partie de la table par l'index ?
Le SKIP SCAN s'utilise lorsque les colonnes skippées ont une faible cardinalité.

Tu peux retenter en prenant les valeurs dans (1, 2, 3, 4) par exemple pour les col1 et col2, distribuées comme tu veux, et en gardant le random sur col3 ?
(que tu répartis comme tu veux)

=> En gros, si tu as un index col1, col2 (je simplifie) et que tu as peux de valeurs distinctes sur col1, tu peux te dire qu'il est plus rapide de faire :
- col1 = val1, col2 IN RANGE
UNION ALL
- col1 = val2, col2 IN RANGE
...
UNION ALL
- col1 = valn, coln IN RANGE
(Avec n pas trop grand...)

Plutôt qu'un FULL SCAN

**Waldar** · 24/11/2008, 19h23

Essayez sur une table de plusieurs millions d'enregistrements, voire avec quelques calculs type agrégats, j'ai déjà constaté un temps de création divisé par deux.

A l'époque c'était en 8i ou 9i mais je ne crois pas que la mécanique ait changé.

**mnitu** · 24/11/2008, 19h31

Envoyé par Waldar

Essayez sur une table de plusieurs millions d'enregistrements, voire avec quelques calculs type agrégats, j'ai déjà constaté un temps de création divisé par deux.

A l'époque c'était en 8i ou 9i mais je ne crois pas que la mécanique ait changé.

Je vous propose que vous essayez de nous la démontrer par un test. Je ne dit pas que vous n'avez pas raison, j'aimerais connaître dans quelle contexte cella fait vraiment la différence.

**c6teen** · 24/11/2008, 19h34

Je suis heureux de voir toutes ces considérations sur les index et leur utilisation mais je reste assez dubitatif. Il me semble que les requêtes non optimisées sont avant tout lentes parce que mal programmées.
N'oubliez pas qu'avant de chercher à influencer l'optimiseur du SGBD, il serait sympa d'écrire des requêtes claires et qui suivent le bon sens.

**mnitu** · 24/11/2008, 19h36

Envoyé par c6teen

N'oubliez pas qu'avant de chercher à influencer l'optimiseur du SGBD, il serait sympa d'écrire des requêtes claires et qui suivent le bon sens.

Si tu peux nous les indiquer on va y tous gagner.

**mnitu** · 24/11/2008, 19h53

Envoyé par SheikYerbouti

...
l'index 2 sur clé composite n'est clairement pas utilisé lorsque la recherche ne porte pas sur la première partie de la clé.

Je suis d'accord avec vous mais malheureusement ce n'était pas ça la question.
Voilà un petit test sur 11g

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
 
SQL> set autotrace traceonly explain
SQL> SELECT * FROM TEST3  WHERE col3 BETWEEN 48 AND 52 ;
EcoulÚ : 00 :00 :00.00
 
Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 4039984554
 
-----------------------------------------------------------------------------
| Id  | Operation            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |      |     7 |    77 |     3   (0)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| IX2  |     7 |    77 |     3   (0)| 00:00:01 |
-----------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("COL3"<=52 AND "COL3">=48)

**Vincent Rogier** · 24/11/2008, 20h45

Oracle 10g et > ont pas mal modifié la gestion de la sélection des index.

Oracle s'est amélioré et utilise plus facilement les index qu'avant (avant, il était plutôt bête et discipliné... maintenant il est plus imaginatif

)

Donc, se prendre la tête sur des exemples précis sans mention de version ne sert à rien.

On sait que l'optimiseur d'Oracle ne fonctionne pas pareil entre une 8i, 9i, 10g et 11g.

On peut tourner en rond longtemps si chacun y va de sa "règle" de sélection des index valable en 8i mais plus en 10g ou vice versa...sans mentionner les versions concernées.

Donc à annoncer une règle, merci de l'annoncer avec les versions pour lesquelles elle s'applique pour plus de clarté et pour éviter les échanges stériles qui alourdissent la discussion.

D'ailleurs, je compte y faire un peu de ménage et la transformer éventuellement en débat

**bouyao** · 25/11/2008, 01h28

Envoyé par vicenzo

Oracle 10g et > ont pas mal modifié la gestion de la sélection des index.

Oracle s'est amélioré et utilise plus facilement les index qu'avant (avant, il était plutôt bête et discipliné... maintenant il est plus imaginatif

)

Donc, se prendre la tête sur des exemples précis sans mention de version ne sert à rien.

On sait que l'optimiseur d'Oracle ne fonctionne pas pareil entre une 8i, 9i, 10g et 11g.

On peut tourner en rond longtemps si chacun y va de sa "règle" de sélection des index valable en 8i mais plus en 10g ou vice versa...sans mentionner les versions concernées.

Donc à annoncer une règle, merci de l'annoncer avec les versions pour lesquelles elle s'applique pour plus de clarté et pour éviter les échanges stériles qui alourdissent la discussion.

D'ailleurs, je compte y faire un peu de ménage et la transformer éventuellement en débat

Je suis totalement d'accord.

Pour une optimisation parfaite d'une base de données, il faut posseder la source du noyau Oracle et ce qui n'est pas le cas.

Comme il a dit vicenzo qu'on se prend la tête sur des exemples précis sans mention de version, et j'ajoute en plus de mentioner
les patchs, le paramétrage de la base, les statisiques et il y a encore d'autres facteurs ...

Dernièrement une reqûete qui durait 9h, en passant un petit patch de 90ko et elle est maintenant à 45 secondes et ca peut être
pareil pour un mauvais paremetrage ou des statistiques qui ne sont pas à jours (biensûre suivant les versions d'oracle).

Les exemples à la Tom Kit's (pardon Kyte !)( ca me fait penser au support oracle) !!!

Moi ce que je pense dans cette situation pour optimiser une base de données avec les moyens qu'on a, c'est de (en 10g)
* vérifier que les stats sont à jours (les stats c'est comme une carte de métro, sans elle tu est perdus)
* d'utiliser les bons indexes (Dans une catre si elle ne mentionnent pas les noms des rues par un ordre précis, on perds plus de temps à chercher la rue)
* Ca ce complique !!!

**SheikYerbouti** · 25/11/2008, 07h50

Envoyé par mnitu

Je suis d'accord avec vous mais malheureusement ce n'était pas ça la question....

Il s'agissait de répondre à ceci:

Malheureusement ni à cette époque, ce conseil n'était pas correct. Mais, je dois vous avouer que à l'époque j'étais mois aussi convaincu que c'est vrai. Plus tard j'ai trouvé un test proposé par Tom Kyte pour Oracle 8 (et repris pour Oracle9 et 10) et encore plus tard j'ai compris le mécanisme qui m'a fait tiré cette mauvaise conclusion. Le mécanisme que vous décrivez du mémoire et qui est apparu en Oracle 9 concerne une nouvelle méthode d'accès qui est l'index skip scan mais cella n'a rien à voir avec la sélectivité des colonnes d'un index composé. En fait plutôt le contraire est vrai vu la possibilité d'utiliser la compression des indexes.

J'explique pourquoi le concept donné dans l'article concernant l'ordre des colonnes dans un index composite est important jusqu'en 9.2, pour le moins.

Maintenant, je vais vous laisser vous battre chacun sur chaque point de détail, ce qui nous promet un débat infini, car, effectivement, le simple fait de posséder une 9i, une 10g ou une 11g permettra à chacun de faire valoir sa spécificité.
Par contre, je mets facilement dans la peau de celui qui a démarré ce thread et qui, aujourd'hui, n'y comprend certainement plus rien.

Je rappelle que l'objet de cette question portait sur les principes "de base", et non de la spécificité particulièrement spécifique de chaque nouvelle version.
Je demeure persuadé que plus de 80% des concepts ennoncés dans ce (vieil) article sont toujours d'actualité.

Sur ce : à bon entendeur, salut !

**pacmann** · 25/11/2008, 08h38

Envoyé par SheikYerbouti

J'explique pourquoi le concept donné dans l'article concernant l'ordre des colonnes dans un index composite est important jusqu'en 9.2, pour le moins.

Hmmm, je crois que la question était un tout petit peu plus précise :

Envoyé par mnitu

Et cella est eronnée ou je le comprends mal.

Envoyé par SheikYerbouti

Utilisez des index composites. Ceux-ci doivent être classés dans l’ordre décroissant de sélectivité.

Avec comme arguments, lorsqu'il y a des colonnes peu sélectives :
- élargissement du périmètre d'utilisation de l'index et skip scan
- possibilité de compression de clef de l'index (j'ai lu ça l'autre jour, et je trouve ça sympa !)
(et ça existe au moins depuis 9.2)
- Et je reste persuadé que le choix de l'ordre des colonnes en fonction de la tronche du schema et de son alimentation, doit pouvoir jouer fortement sur le cf de l'index... (le jour où je m'achète un Oracle, je me fais des vrais tests

)

Après, l'ordre des colonnes reste important malgré tout, mais c'est juste le mot "doivent" qui peut lever des questions.
Et de manière générale, je pense aussi qu'il n'est pas très sain de s'acharner sur ton article, qui dit plein de bonnes choses...

Enfin, je trouve vraiment dommage que le sujet ait pris un arrière goût de règlement de comptes, parce qu'en soi, il est intéressant d'en discuter...

**orafrance** · 25/11/2008, 09h17

On peut aussi imaginer que les colonnes les plus sélectives sont moins encline à être modifiée et donc, créer les indexes avec les colonnes par ordre de sélectivité limiterait le chainage et la fragmentation des tablespace. Après, en terme de performance on peut aussi imaginer que le parser consomme moins de CPU s'il n'a pas à se taper les permutations qui lui permettront de retrouver l'ordre le plus adéquat.

Note que ce ne sont que des impressions, j'ai pas fait de tests en ce sens. En tout cas, on prend pas de risque à pousser les gens à procéder de la sorte, c'est bien là l'essentiel parce que c'est super de profiter des avancées du CBO en 10g et plus mais le jour où tu te retrouves sur une 8i, si t'as pas pris de bonnes habitudes tu cours au désastre

**Vincent Rogier** · 25/11/2008, 09h32

Bon,

Pour information, ce topic sera toiletté et transformé en débat et annoncé sur la rubrique afin que tout le monde puisse débattre sur ce sujet ... passionnant

PS : d'ici à demain...

**Waldar** · 25/11/2008, 10h23

Envoyé par mnitu

Je vous propose que vous essayez de nous la démontrer par un test. Je ne dit pas que vous n'avez pas raison, j'aimerais connaître dans quelle contexte cella fait vraiment la différence.

Il faudra m'excuser je ne maitrise pas SQL*Plus (je ne suis pas DBA), j'ai créé un petit bloc PL/SQL avec du DBMS_OUTPUT, donc ça reste très light comme analyse et je ne peux que reboucler sur les temps de traitement.

Pour info, la table FACTURE (en fait c'est une autre mais bon) est partitionnée par année, dans le select concerné il y a 17.000.000 de lignes.

Test effectué sur Oracle 11g.

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
begin
    dbms_output.put_line('Debut : ' || to_char(current_date, 'hh24:mi:ss'));
    execute immediate('create table X_20081125_TEST
                       as
                       select * from FACTURE 
                       where FACTURE_DT >= to_date(''01/01/2006'', ''dd/mm/yyyy'')
                       and FACTURE_DT < to_date(''01/01/2009'', ''dd/mm/yyyy'')');
    dbms_output.put_line('Fin Create as Select : ' || to_char(current_date, 'hh24:mi:ss'));
    execute immediate('truncate table X_20081125_TEST');
    dbms_output.put_line('Début insert : ' || to_char(current_date, 'hh24:mi:ss'));
    execute immediate('insert into X_20081125_TEST
                       select * from FACTURE
                       where FACTURE_DT >= to_date(''01/01/2006'', ''dd/mm/yyyy'')
                       and FACTURE_DT < to_date(''01/01/2009'', ''dd/mm/yyyy'')');    
    execute immediate('commit');
    dbms_output.put_line('Fin insert : ' || to_char(current_date, 'hh24:mi:ss'));
end;

Résultat :

Code :

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

1
2
3
4
Debut : 09:54:57
Fin Create as Select : 09:56:02
Début insert : 09:56:03
Fin insert : 09:57:56

Principes de base d'optimisation de requête

SQL Oracle

Discussions similaires

Partager

Partager