Discussion :

[farenheiit]

Bonjour,

Qu'est ce qui pourrait expliquer qu'un insert select dure très longtemps alors que le select s'execute très rapidement. Il n' y'a pas de trigger sur la table mais il y'a 3 indexes B-TREE.
Le select s'execute en 1 minute et retourne 500 000 lignes (test effectué avec create table as select) mais l'insert+select dure 40 minutes.

Est-ce que le fait que les indexes soient fragmentées (plus de 50% de feuilles vides pour 2 des 3 indexes) peut jouer?
peut-il y'avoir d'autres causes?

il s'agit d'une Base 10G R2

[pachot]

Bonjour,

Un create table as select, donc sans indexes, peut être très rapide, surtout sur une base en noarchivelog mode (ou sur une table en nologging) car c'est un accès direct sans passer par le buffer cache, sans génération d'undo et sans génération de redo.
La mise à jour des 3 indexes, une dizaine de blocks à aller voir pour chaque enregistrement, les modifiers en buffer cache, généréer du redo, de l'undo et du redo pour le undo...
Donc un facteur 40 ne me parait pas hallucinant.

Le fait qu'il y ait de la place vide dans les feuilles est plutot pas mal. L'insert a besoin de place vide et s'il n'y en avait pas il devrait faire des splits de blocs, beaucoup plus coûteux.

En fonction du volume de donnée qu'il y a avant dans la tables, il peut être interressant de mettre les index unusable plus de les rebuilder à la fin.

Cordialement,
Franck.

[farenheiit]

pas compris l'histoire des dizaines de block à aller voir par enregistrement.
Il me semblait que dans un index les feuilles vides n'étaient pas comblées et restaient toujours vides???

[pachot]

La dizaine de blocs, c'est parce qu'il y a 3 indexes, qu'il faut descendre 1 ou 2 branches, et mettre à jour 1 feuille.

Il me semblait que dans un index les feuilles vides n'étaient pas comblées et restaient toujours vides???

Oh non ! Imagine que ce soit le cas ... les indexes grossiraient à vue d'oeuil

Non, la place libérée dans une feuille peut être réutilisée dès que la transaction qui l'a libéré est commitée. Bien sur, pas par n'importe quel insert. Une feuille correspond à un tranche de valeur pour les colonnes indexées. Donc on ne peut y mettre que des enregistrements qui sont dans la même tranche.
Par contre, lorsque la feuille est totalement vide, là elle peut être réutilisée n'importe où.

Un peu de place libre partout, c'est le meilleur moyen de pouvoir insérer des données rapidement. C'est pareil à la bibliothèque. Chaque étagère de chaque rayon a un peu de place vide. Donc facile d'ajouter un livre quelque part.

Imagine que l'on compacte tout sur quelques étagères complètement pleines: au premier nouveau livre, il faudra tout réaménager ! Celui qui aura fait la réorganisation sera content de lui (gain de place) mais ceux qui vont bosser après lui vont galérer. C'est souvent ce qu'il se passe lorsqu'on réorganise les indexes un peu trop régulièrement...

Cordialement,
Franck.

[farenheiit]

Ba dans ce cas à quoi sert le rebuild alors?
T'as pas une preuve de ce que tu avances par hasard?

[farenheiit]

Je répond à ta place: en fait le rebuild sert surtout pour les scan des indexes car en reconstruisant on a un arbre plus compact donc moins de blocks à parcourir. c'est ça?

[pachot]

Ba dans ce cas à quoi sert le rebuild alors?

Il y a de rares cas où celà peut être utile si l'on purge des données et que l'on sait qu'on ne va jamais inserer de nouveux enregistrements dans les mêmes valeurs.

Par exemple, index sur date.
Si on purge 100% des données antérieures au 1er janvier, là les feuilles correspondantes seront complètement vies et pourront être réutilisées par n'importe que nouvel insert.
Mais si l'on purge 90% des données antérieures au 1er janvier là les feuilles correspondantes auront 10% d'espace libre, réutilisables seulement par des dates antérieures au 1er janvier. Alors si l'on est surs de ne pas inserer à nouveu des dates comme celles là, il peut être interressant d'amélioere celà. Mais un COALESCE est suffisant (et se fait online facilement) pas nécessairement besoin de faire un rebuild.

Cordialement,
Franck.