Bonjour,
je suis sous oracle 10GR2 et je voulais savoir si il y avait un moyen de savoir quand il fallait rebuilder un index?
Merci d'avance
Version imprimable
Bonjour,
je suis sous oracle 10GR2 et je voulais savoir si il y avait un moyen de savoir quand il fallait rebuilder un index?
Merci d'avance
C'est une bonne question :mouarf:
La réponse serait : en faisant unEnsuite analyser la vue user_indexes (qui contient juste 1 ligne avec le dernier index que tu as analysé). Cet article en parleCode:analyze index <index_name> compute statistics;
Par contre il me semble que les avis divergent sur les critères requis pour affirmer que le rebuild est nécessaire ...
Certains disent même qu'il est très rare qu'un index nécessite un rebuild, cf cet article
Merci Scheu pour ces informations:D
J'ai lu sur le site ask Tom que les rebuild sur les indexes devaient rester exceptionnels (après avoir supprimé bcp de données d'une table par exemple).
Pour défragmenter tes indexes, tu peux préférer le coalesce.
Effectivement un index n'a besoin d'être reconstruit que lors de beaucoup de modification de la table concernée (modif de colonnes ou autres), surtout avec des ordres LDD , de ce fait en 10g / 11g le rebuild est vraiment rare..
Pour évaluer si tu a besoin de faire un rebuild ou non, tu peu utiliser la commande analyze, mais tu peut également te servir du package
DBMS.STATS_GATHER_INDEX_STATS (....)
Par contre le coalesce ne fait rien au niveau des Index, son rôle est de rassembler les segments non contigus et non alloués. Le gain en terme d'espace après avoir lancé la commande est très faible.
La plupart du temps cette commande est utilisé pour les TableSpace dans le but de rassembler les segments non alloués.
Bonne journée,
Après avoir supprimer énormément de lignes dans une table comment faire pour alléger le tablespace qui contient la table? et à ce moment il est donc nécessaire de faire un rebuild des indexes alors?
Dans ce cas bien précis, il n'y a pas trente six moyen, car en supprimant des lignes d'une table, des blocs oracle se retrouvent donc vide, et meme en 10g oracle a toujours du mal à utiliser des blocs vide non contigus sur disque.
Le coalesce du TBS peut être lancé, mais tu ne gagnera quasi rien en place.
Personnellement pour ce genre de pb je fait un move table dans un autre TBS temporaire, ce qui me permet lorsque ma table revient sur son TBS d'origine de retrouver une taille plus que convenable (normal car en 10g tu doit être en extend management local)
Sinon après, il y a la bonne veille méthode d'export / Drop table / create table / import...
Désolé j'oubliai les index lol
Si tes colonnes de cette table ont été modifiés, alors oui il faudra faire un rebuild ou meme carrément les refaire (je te le conseille)
Mais par contre si c'est uniquement le contenu de la table qui a été manipulé (ordres LMD) le rebuild index n'est pas utile. Par contre tu peu relancer des stats sur le schéma pour mettre à jour l'optimiser Oracle ;)
Le move tablespace dans un temporaire est la méthode que je préconise aussi mais il y en a t il une autre????
A ma connaissance a part le move table et export / import, il n' y a pas d'autre méthodes.
A confirmer...;)
Un MOVE dans le même tablespace marche aussi, ça évite de devoir déplacer 2 fois la table 8-)
Oui exact Scheu !
Mais il me semble qu'il faut la renommer en faisant le move... Perso je prefere utiliser un TBS à coté, c'est une méthode comme une autre ;)
En général Oracle sait réutiliser l'espace libre dans les blocs qu'ils soient contigus ou non sur disque. Pouvez-vous nous donner un contre-exemple avec la version Oracle sur 4 chiffres et la création du tablespace ?Citation:
Envoyé par Mikl-Dba
Avec la 10.2, il y a aussi ALTER TABLE ... SHRINK SPACE.Citation:
Envoyé par Mikl-Dba
Bonsoir
J'ai effectivement déjà rencontré le pb vis à vis des blocs non utilisé, en Production sur des SGBDR 9i (9.2.0.4 par exemple)
Meme en extend management local (y compris space segment management auto), la fragmentation apparait.
il faudrait que je vous retrouve mes logs sur cette BDD et vous pourrez le constater. Cela m'arrive également quelques fois sur des bases 8i / 9i... a ce jour mes seules solution de réorganiser et retrouver de l'espace libre c'est soit déplacer et reconstruire mes tables, ou bien procéder à un export / import .
Je n'ai par contre pas encore eu l'occasion de le vérifier sur 10g / 11g
Et pour la commande de shrink, je ne m'en rappelais plus merci ! ;)