Réorganisation d'une table/base

Bonjour,

J'ai la création d'un index qui prends de plus en plus de temps.
Au début 20 minutes, aujourd'hui 2 à 3h.

Je pense qu'en effectuant une réorganisation de la table, je suis susceptible de retrouver mon temps initial.

Cette table est fragmenté à 15%, cependant lorsque je recherche sur le net on parle souvent des réorgs de base dans le but de gagner de l'espace.
Je pense qu'on gagne aussi beaucoup en performance, car pour moi la réorg permet surtout de remettre les tables d'une façon contiguë (pour un certain temps du moins). Le gain de place se fait plus par "effet de bord".

Quelqu'un peut il me confirmer ou m'infirmer ce que j'avance ?

J'ai du mal à comprendre un détail :

Lorsque je dit que ma table est fragmenté, je me base sur une requête de développez.net qui permet de savoir si un table est fragmenté et consomme plus d'espace que nécéssaire. Or pour moi une table est fragmenté lorsqu'elle est séparé physiquement sur le disque.

L'ilustration d'une table fragmenté de développez.net est celle ci :
Pièce jointe 155687

Il est expliqué dans le cours associé que déplacer les tables permet de gagner de l'espace. Nous sommes d'accords, mais les tables ne sont pas seulement "tassé" elles sont également recréer de façon contiguë ce qui permet selon moi de gagner en performance.

Est ce que je fait fausse route ? Sinon y a t il une requête qui permet de mettre ce problème en évidence afin que je puisse détecter ce problème plus facilement ?

Merci pour votre aide :)

Bonjour,

Le terme de 'fragmentation' peut s'appliquer à beaucoup de choses.
Ici la traduction des posts de Jonathan Lewis sur ce sujet:
http://blog.developpez.com/pachot/jl_fragmentation_1/
http://blog.developpez.com/pachot/jl_fragmentation_2/
http://blog.developpez.com/pachot/jl_fragmentation_3/
http://blog.developpez.com/pachot/jl_fragmentation_4/

Mais dans la pluspart des cas, on défragmente pour un gain de place, pas pour des performances. Est-ce que tu sors plus rapidement d'un parking où l'on a évité au maximum d'avoir des espaces vides, ou au contraire d'un parking où les couloirs sont larges?

Cordialement,
Franck.

Merci Pachot :D

Réponse très précise comme d'habitudes, je cherchais justement ce genre d'article.

Comme Oracle lis indépendamment chaque extend, qu'il soit contiguë ou non. Normalement ça ne dois pas avoir d'impact. C'est donc surtout un gain de place, qu'un gain de performance.

Citation:

---

Envoyé par skyarnangel

Comme Oracle lis indépendamment chaque extend, qu'il soit contiguë ou non. Normalement ça ne dois pas avoir d'impact. C'est donc surtout un gain de place, qu'un gain de performance.

---

Exactement.

Il n'y a que lors de l'accès par index où on va avoir de moins bonnes perfs si on doit aller voir des lignes de la table dispersées un peu partout, par rapport à une table bien compacte. Parce qu'on devra lire plus de blocs et parce qu'il y a moins de chanve de les trouver en cache. Mais par contre une table trop compacte va rendre les update moins performants s'ils n'ont pas la place pour grossir.

Cordialement,
Franck.

Bonjour ,
Je me permets de rajouter que la défragmentation améliore les opérations de full scan car moins de blocs à lire :)
Donc défragmentation et perfs c'est liées...

Citation:

---

Envoyé par devkais

Bonjour ,
Je me permets de rajouter que la défragmentation améliore les opérations de full scan car moins de blocs à lire :)
Donc défragmentation et perfs c'est liées...

---

Oui, exact. Mais cela ne se produit que exceptionellement, lors d'une grosse purge par exemple.

dans le cas de création d'un index il y a bien un full scan donc une reorganisation de la table va probablement améliorer les performances

Citation:

---

Envoyé par a.presles

dans le cas de création d'un index il y a bien un full scan donc une reorganisation de la table va probablement améliorer les performances

---

Exact, mais la création d'un index n'est pas une opération courante. On ne va pas réorganiser la table pour pouvoir crééer un index plus rapidement, car la reorg sera plus longue.
Ou alors c'est une recréation et pas besoin de full table scan (rebuild peut lire lindex courant pour le recréer).

D'où une question fondamentale à skyarnangel:

Citation:

---

Envoyé par skyarnangel

la création d'un index qui prends de plus en plus de temps.

---

Quel est le besoin de recréer frequemment cet index?