Discussion :

[Alexandre T]

Est-il possible comme en mySQL d'ajouter une colonne en première position d'une table ? En mysql la requête est :

Code :

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

ALTER TABLE maTable ADD maColonne integer NOT NULL FIRST ;

Oracle ne comprend pas le mot FIRST.
Suis-je obligé de
1- créer une table temporaire,
2- de transvaser les données,
3- de virer la première table en "m'ennuyant" avec les contraintes de références sur les clefs étrangères
4- de renommer ma table tampon avec le nom d'origine ?

Cela m'étonnerait que le SGBD n'ai pas prévu cela... Mais j'ai beau parcourir les documentations, aucune information ne précise ce point !

[Jaouad]

Bonjour ,
Lorsque vous ajoutez une colonne à votre table Oracle l'ajoute à la fin
Cependant je ne voit pas pourquoi cela est une contrainte puisque lors de la restitution des données c'est vous qui décidez de l'ordre des colonnes


Jaouad

[aline]

Bonjour ,
Cependant je ne voit pas pourquoi cela est une contrainte puisque lors de la restitution des données c'est vous qui décidez de l'ordre des colonnes


Jaouad

Bonjour Jaouaud,
en chippotant, on trouve une raison. Il est plus rapide d'interroger la première colonne que la dernière.
Si ainsi par exemple tu veux installer une nouvelle colonne qui sera toujours requetée et la plus importante, cela peux avoir un sens de commencer par la première colonne.

[orafrance]

t'es sûr que l'ordre a de l'importance ? J'ai jamais pu le constater

[aline]

l'importance n'est pastrès grande évidement, mais pour lire la 4è colonne, oracle doit passer par les trois première...

[orafrance]

voila qui me surprend énormément... en effet, Oracle accéde à des blocs de données et pas à des colonnes, j'arrive pas à voir en quoi cela peut bien poser problème J'aimerai bien qu'on m'explique ce qui pourrait expliquer un tel phénoméne, ou alors c'est dans le parsing peut-être que ça "coince"

J'aurais plutôt tendance à croire que c'est un outil de mapping qui impose un ordre

[aline]

bien sur qu'il accède à des blocs,

Mais une fois dans le bloc, comment lit-il les données. Il doit bien "passer" les colonnes avant de trouver la bonne, mais le rien n'est pas très grand évidement.
J'ai lu une démo par l'exemple de cela, je ne me souviens plus si c'était sur le site de Tom Kytes ou de Steves Adams.
si tu veux, j'éssaierai de la retrouver

[Jaouad]

Bonjour ,
Cependant je ne voit pas pourquoi cela est une contrainte puisque lors de la restitution des données c'est vous qui décidez de l'ordre des colonnes


Jaouad

Bonjour Jaouaud,
en chippotant, on trouve une raison. Il est plus rapide d'interroger la première colonne que la dernière.
Si ainsi par exemple tu veux installer une nouvelle colonne qui sera toujours requetée et la plus importante, cela peux avoir un sens de commencer par la première colonne.

Effectivement il me semble , tout comme Aline , déja vu une démonstration la dessus, cependant voila ce que j'ai retenu de cette intervention de Tom ( si ma mémoire ne me lache pas ) :
1) Le gain de temps est infime
2) Jamais cela ne serat une base de Tuning justement du au peu de temps gagné ....

Jaouad

[Jaouad]

Je me souvient avoir fait un test sur une table de 20 Giga et n'avait pas déterminer de différence sensible

[orafrance]

Effectivement il me semble , tout comme Aline , déja vu une démonstration la dessus, cependant voila ce que j'ai retenu de cette intervention de Tom ( si ma mémoire ne me lache pas ) :
1) Le gain de temps est infime
2) Jamais cela ne serat une base de Tuning justement du au peu de temps gagné ....

Voila qui me rassure... n'empêche que je ne vois pas pourquoi il passe par les 1° colonnes... si vous arrivez à remettre la main sur la démo ce serait bien aimable

[orafrance]

Je me souvient avoir fait un test sur une table de 20 Giga et n'avait pas déterminer de différence sensible

c'est plutôt sur une table avec beaucoup de colonnes qu'il faudrait essayer

[Jaouad]

Je me souvient avoir fait un test sur une table de 20 Giga et n'avait pas déterminer de différence sensible

c'est plutôt sur une table avec beaucoup de colonnes qu'il faudrait essayer

30 colonnes


oui effectivement mais le fait d'avoir énomément de données permet d'accroitre la différence , s'il y a

Je dois dans chaque bloc aller chercher la 3 colonne , si je multiplie cela par le nombre de bloc et donc de données la différences devrait être plus visible

[orafrance]

je viens de faire un test sur une table de 100 colonnes et 1 millions de lignes j'ai pas, ne serait ce que, 1 ms d'écart

[orafrance]

au temps pour moi :

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
SQL> set timing on
SQL> set autotrace trace
SQL> select col1 from fred_d;
 
2000000 ligne(s) sélectionnée(s).
 
Ecoulé : 00 :01 :12.03
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'FRED_D'
 
 
 
 
Statistiques
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     214499  consistent gets
      86956  physical reads
          0  redo size
   13729146  bytes sent via SQL*Net to client
     933606  bytes received via SQL*Net from client
     133335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    2000000  rows processed
 
SQL>

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
SQL> set timing on
SQL> set autotrace trace
SQL> select cola1 from fred_d;
 
2000000 ligne(s) sélectionnée(s).
 
Ecoulé : 00 :01 :18.08
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'FRED_D'
 
 
 
 
Statistiques
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     214499  consistent gets
      86956  physical reads
          0  redo size
   13729147  bytes sent via SQL*Net to client
     933606  bytes received via SQL*Net from client
     133335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    2000000  rows processed
 
SQL>

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
SQL> set timing on
SQL> set autotrace trace
SQL>  select cola49 from fred_d;
 
2000000 ligne(s) sélectionnée(s).
 
Ecoulé : 00 :01 :20.01
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'FRED_D'
 
 
 
 
Statistiques
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     214499  consistent gets
      86956  physical reads
          0  redo size
   13729148  bytes sent via SQL*Net to client
     933606  bytes received via SQL*Net from client
     133335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    2000000  rows processed

cola1 est la 50° colonne et cola49 la 100° d'une table de 100 colonnes

j'aimerai bien connaitre le pourquoi du comment quand même

[plaineR]

J'ai quand même du mal à croire qu'il y ait une si grande différence en terme de perf... Presque 10% cela n'est pas infime.

Que donne le tkprof ?

[orafrance]

des traces

il donne juste un elapse plus long sur le fetch

[Jaouad]

C'est une table que tu as crée via un create as ... ?

si oui est elle analyzé ?

Jaouad

[orafrance]

non justement, j'ai rien analysé sinon ce serait pas intéressant

J'ai créé la table et inséré 1,1,1,1,1...,1 2 millions de fois

[ducho]

est-ce que tes lignes sont des "chained rows " ?

[Jaouad]

et bien la différénce doit s'expliquer ainsi

analyze la table et la différence disparaitra , non ?