Discussion :

[zidane2012]

Salut
pour rebuilder un gros index ( 7Go) j'étais contraint d'utiliser les techniques suivantes :

1/ parallel
2/nologging

mais j'ai entendu parler d'astuces au niveau de la mémoire PGA et TEMP permettant faire l'opération plus rapidement et éviter toute erreur liée à une mémoire insuffisante lors du rebuild ? une idée ?

Sinon le rebuild est-il plus rapide qu'un drop/create ? pourquoi ?
merci par avance

[rouardg]

Bonjour,

Lorsque tu crées un index sur 1 ou plusieurs colonnes C1, C2...Cn, Oracle est obligé de balayer complétement la table pour lire les différentes valeurs de cette(s) colonne(s), et de les trier afin de pouvoir construire l'index.

Le tri s'effectue normalement en mémoire, dans la PGA. Mais si celle-ci est trop petite, alors Oracle va utiliser le tablespace temporaire, afin d'y stocker temporairement les segments de tri, d'où un ralentissement.

Il faut donc vérifier que la PGA est suffisamment grande pour éviter l'utilisation du TEMP.


Sinon dropper et recréer un index est souvent plus long que le rebuilder. En effet, la recréation de l'index nécessite de balayer toute la table (Full Scan Table), alors que le rebuild de l'index nécessite de ne relire que l'index (attention, c'est un Full Scan d'index, et non pas un Fast Full Scan d'index).

Et souvent, relire l'index est plus rapide que relire la table, car il est moins volumineux. L'inconvénient, c'est qu'il faut temporairement le double de place.

NB : le seul cas où cela ne marche pas fait suite à un MOVE de la table. En effzet, si tu déplaces ta table, tous ses index deviennent UNUSABLE (à cause des changements de ROWID des lignes). Du coup, le Rebuild d'index va lire toute la table, au lieu de lire l'index.

[Mohamed.Houri]

En effet, la recréation de l'index nécessite de balayer toute la table (Full Scan Table), alors que le rebuild de l'index nécessite de ne relire que l'index (attention, c'est un Full Scan d'index, et non pas un Fast Full Scan d'index).

Non, je ne pense pas que cela soit totalement correct. Il conviendrait de changer légèrement votre texte pour que cela soit exact.

En effet, la recréation de l'index nécessite de balayer toute la table (Full Scan Table), alors que le rebuild offline de l'index nécessite de ne relire que l'index (attention, c'est un Full Scan d'index, et non pas un Fast Full Scan d'index).

NB : le seul cas où cela ne marche pas fait suite à un MOVE de la table. En effzet, si tu déplaces ta table, tous ses index deviennent UNUSABLE (à cause des changements de ROWID des lignes). Du coup, le Rebuild d'index va lire toute la table, au lieu de lire l'index.

Le rebuild, même offline, d'un index ayant un statut UNUSABLE, se fait en se basant sur la table qui lui est associée et non sur l'index lui même.

[zidane2012]

Merci pour vos réponses.
et le cas d'un rebuild online ...comment cela se passe ?
Sinon l'astuce d'augmenter la PGA avant de reconstruire l'index ? efficace ? comment faire et quand exactement ?
merci beaucoup

[zidane2012]

bonjour ,
Je pense utiliser le paramètre caché _pga_max_size (par défault = 200 Mo).
L'objectif est de booster le rebuild d'index ...

Code :

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

alter session set "_pga_max_size"=2000000000;

votre avis ?merci
a+

[Rei Ichido]

Question subsidiaire : pourquoi faire un REBUILD de cet index ?

Est-ce qu'un COALESCE ne suffirait pas (voire, serait plus approprié) ?

[pachot]

Bonjour,

ALTER session SET "_pga_max_size"=2000000000;

Plutôt que de bidouiller l'allocation automatique de la PGA, pourquoi ne pas passer en PGA manuelle avec workarea_size_policy=manual et sort_area_size=2000000000
(à supposer que votre OS aime bien manipuler des process de 2GB...)
Cordialement,
Franck.