Version imprimable
Bonjour,
J'ai un index de 16Go que je souhaite reconstruire.
Ma table temp fait 13Go et je ne peux pas l'agrandir, faute de place.
Comment est géré la reconstruction des index?
il reconstruit je suppose dans le temp?
est ce qu'il y a une formule pour calculer l'espace nécessaire à un rebuild d'un index?
Je n'ai pas trop envie de passer par un delete et un create...
Merci d'avance
M
Un index est reconstruit par défaut en utilisant le même tablespace permanent et non un tablespace temporaire: il vous faut donc avoir au moins 16 Go de disponible dans le tablespace permanent (exemple en anglais ici).
Pourquoi voulez-vous reconstruire l'index ? Il y a un coût non négligeable (pensez aussi à l'undo et au redo) ? Quel est le bénéfice attendu ? Il y a parfois d'autres possibilités.
PS: merci de préciser votre version d'Oracle.
et merci de préciser la version de la base :roll:
Bonjour,
désolé pour l'oubli de version, je suis en 9i
Je veux reconstruire l'index car il a un blevel supérieur à 3 et devrait normalement tourner à 13-14Go plus que 16Go
Etant donné que j'ai une plage horaire de 3h pour le reconstruire, je pense passer à l'action
D'apres les articles que j'ai lu sur ce forum, un delete/create est plus long comme opération.
Quels sont les autres options possible?
M
Pour les opérations de tri lors du rebuild de l'index , Oracle utilise bien le tablespace TEMP ????Citation:
Envoyé par pifor
l'idéal serait d'avoir quel disque en RAID1 le temps de l'opération pour y mettre le TEMP
...pas possible pour le raid 1, toutes mes partitions sont bien occupées...
en fait, il me reste tres peu de place de libre.
ça risque d'etre compliqué alors :? A moins que tu aies des indexes pas trop gros
C'est possible (même si les données sont déjà triées dans l'index). Ce qui est sûr c'est que si le tablespace permanent n'a pas assez d'espace pour construire le segment du nouvel index, alors l'index ne peut pas être reconstruit.Citation:
Envoyé par jf4db
Est-ce que vous être sûr que l'index va passer à un blevel de 2 ? Si c'est le cas quel est le gain esperé en performance ? En général, la plupart des experts recommendent ne pas reconstuire des index ... sauf si on est sûr que l'on va gagner quelque chose. Le document Index Internals Rebuilding the Truth de Richard Foote est une référence sur le sujet.Citation:
Envoyé par moi26
Il y a aussi ALTER INDEX ... COALESCE.Citation:
Envoyé par moi26
qui ne sert qu'à fusionner les extents libres contigüe ce qui me semble insuffisant dans son cas :?Citation:
Envoyé par pifor
mon rebuild tourne.
A priori il reconstruit mon index dans le TEMP, sous toad, je vois sa progression.
Ce que j'espere avec cette opération, c'est récupérer 1 à 2 Go d'espace libre.
Et si par le plus grand des hasards sont blevel passe de 4 à 3...je serais content de ma journée... :yaisse2:
Non ! il fait le tri dans le TEMP mais le segment est bien dans le tablespace.Citation:
Envoyé par moi26
...désolé pour l'erreur, effectivement c'est ce que j'ai lu sur le net, d'abord dans le SORT_AREA_SIZE puis le temp pour le tri
mon rebuild vient de planter:
pour un rebuild sur un index de 16Go, le tri prends plus de 17Go dans mon temp.
J'ai redimensionné mon temp à 17.3Go, j'espere que cela va passer.
M
mais le en autoextend ce sera plus simple :)
En fait, je n'ai pas voulu mettre les autoextend pour gerer manuellement leur évolution:
je suis passé avec 18600Mo sur le TEMP et j'ai fini avec 300Mo de libre sur 2 partitions. Je ne voulais pas que ce soit le même datafile qui prennent tous les extends.
Résultat de l'opération:
je suis toujours en blevel 4 mais j'ai surtout gagné 1Go sur mon index:
elle est descendu à 15Go
Encore merci pour vos aides
M
tout ça pour 1 malheureux giga... :mouarf:
...la place est chère sur notre serveur! :D
comment tu vois ça sous TOAD? ça m'interesseCitation:
Envoyé par moi26
Question bête : tu ne pourrais pas dropper l'index puis le recréer dans une période creuse de ta base (genre la nuit ou le week-end) ? Ca t'éviterait bien des soucis ...