Bonjour à tous !  
 
Voilà tout est dans le titre, je dois défragmenter une table sous Oracle 8.1.6 sur IBM AIX. J'imagine que la façon de faire est indépendante de  
l'OS ... ?  
 
Par ailleurs, dois-je faire une défragmentation du tablespace contenant la  
table ou puis-je le faire au niveau de la table uniquement ?  
 
Merci de me répondre, ça serait très sympa de m'aider, je débute en  
DBA ...  
 
Merci pour vos réponse.

Bonjour
 
Il faut utiliser export/import avec l'option COMPRESS=Y
 
-1- Export de la table
-2- drop de la table
-3- import de la table
 
a+
 
el liberator
 
 

y a pas plus rapide que ça? ça m'étonnerait

Je suis un peu étonné...
 
Normalement, quand les paramètres de la table ont été correctement spécifiés, Oracle doit le fait tout seul non ? Comme le "fill factor" des index... Il est censé consolider les trous au fur et à mesure des mises à jour...

vousw êtes certains qu'on peut _défragmenter_ une base de données ?

 
Je suis de ton avis, pour moi c'est le SGBD qui s'en charge tout seul comme un grand.
 
La seule "solution", c'est de copier les données dans une table temporaire, droper la table, la recréer avec la taille des données, et remettre les données à partir de la table temporaire...

c'est le terme qui me déplait

"Consolider l'espace libre" si tu préfères

pas du tout. je préfère reconstruire la table de hachage. c'est très différent de la défragmentation physique

Pour moi, reconstruire la table de hashage, c'est refaire les indexes.
 
Consolider l'espace libre (défragmenter) c'est ventiller l'espace libre réguilièrement entre les lignes, afin de pouvoir insérer des lignes n'importe où dans la table sans remettre en cause l'ordre des données physiques.

"ventiler l'espace libre régulièrement entre les lignes".  
 
ça veut rien dire.  
 

Ben si, c'est du français et non pas du langage informatique, c'est peut-être pour ça que tu comprends pas.

Ou alors tu ne sais pas comment les données sont stockées dans une base de données, mais j'en doute

Ben oui, ici c'est pas un forum de jardinage. il faut utiliser les termes adéquats pour être compris.

Justement, je préfère utiliser des mots bien français que n'importe quel pékun peut comprendre, plutôt que des termes qui ne veulent rien dire pour personne, même pour 80% des informaticiens.
 
Ventiller régulièrement quelquechose, c'est extrêment clair. Parler de reconstruier une table de hashage (super barbarisme qui ne veut rien dire) je n'en voit pas l'intérêt quand on peut utiliser des mots compris de tous

 
pas du tout. beaucoup de gens qui sont ici ont déjà construit, alimenté et géré des tables de hash à la main.
 
faut pas prendre ton cas pour une généralité
 

Je parle pas de savoir le faire ou non, je parle du terme.

mais bordel. c'est pas un barbarisme, c'est un terme technique. comme polymorphisme p. ex.
 
t'as des lacunes toi. t'es un multi à Magic ou quoi ?

optmiser

J'aimerais bien comprendre le but de la manoeuvre moi?

Le but est simple.
 
Imagine une table de travail. Régulièrement tu insère plusieur centaines de milliers de lignes faisant 1 Ko chacune. Rapidement, l'occupation sur le disque va dépasser le Go.
 
Mais vu que c'est une table de travail, et non une table de stockage, tu supprimes aussi beaucoup de lignes.
 
Très rapidement, il va y avoir d'énormes trous dans la table.
 
Si parmis les requêtes que tu vais régulièrement il y a des "full scan", il devient alors bien plus intéressant de regrouper toutes les lignes à la suite, et triées selon un index clustered, plutôt que devoir parcourir une grande surface sur le disque pour récupérer des lignes pas forcément triées.
 
Deplus, si ta table n'a pas une taille fixe dans le table space, elle risque de se retrouver coupée en deux par les données d'autres tables lorsqu'elle va grossir, impliquant une surface encore plus grande à parcourir pour retrouver toutes les données. C'est ce que j'appelle la consolidation de l'espace libre.
 
Autre exemple. Toujours une table de travail, mais tu sais que régulièrement, en suivant ton index clustered tu vas inérer des lignes entre les lignes existantes. A ce moment, au bout d'un certain temps, il n'y aura plus la place physique d'insérrer une ligne entre deux autres. Et a cause de ton index culstered, a chaque insertion de ce type, le moteur du SGBD va devoir décaler de gros volumes de données pour pouvoir respecter l'ordre suivant ton index.
A ce moment, il est très intéressant, par batch par exemple, de droper la table, et la recréer toutes les nuits, en veillant à insérer des espaces entre chaque ligne (ce que j'appelle la ventillation de l'espace libre).
 
Les deux systèmes peuvent tout à fait se faire par batch, en paramètrant dynamiquement les informations de stockage lors de la re-création de la table. Ils permettront de gagner énormément au niveau des performances, puisque tu feras ce traîtement une fois par jours, pendant une heure creuse, plutôt qu'obliger ton SGBD à la faire automatiquement à chaque modification des données, ou perdre en performances en n'utilisant pas d'index clustered.
 
Ceci dit, j'ai jamais eu l'occasion d'avoir réellement besoin de ce type d'optimisation.

Pour PostgreSQL, il y a la commande vaccuum qui nettoie la base  en supprimant physiquement les entrées... supprimées. et vaccum analyze qui fait des analyses statistiaues d'usage des tables, p-ê pour les optimiser en fonction des fameuses questions de ventilation évoquées ci-dessus.
 
Pour Oracle, je ne sais pas, mais c'est peut-être fait automatiquement.

Normalement, c'est automatique, mais dans une table qui a beaucoup de mouvements, ça peut ne pas suffir.
 
Dans tout les cas, généralement, si on arrive aux limites d'un SGBD comme Oracle, c'est que quelque part on a un problème de conception quelque part, ou qu'on n'a pas compris à quoi servait un SGBD.

C'est bien là le problème.
 
En fait, c'est pas la défragmentation que je ne comprenais pas mais pourquoi le mec qu'a posté en avait besoin?
 
En a-t-il vraiment besoin?

Dans certains cas je pense que oui, mais a ce moment, c'est parcequ'il se sert de sa base de données comme espace de travail (imagine que tu ait des tableaux de plusieurs millions de lignes, ou un graphe de plusieurs millions de nodes) tu ne peux pas travailler avec en mémoire. Du coup tu baloudre tout dans une base de données et tu fais tes calculs dessus.
 
Cependant, si c'est des données de travail, je comprends pas spécialement l'utilité de les "défragmenter" puisqu'elles sont volatiles, et donc aucun moyen de sheduler l'optimisation de leur représentation.

ALTER TABLESPACE table_de_la_table COALESCE;
 
Cette commande fusionnent les espaces, cad defragmente tout les segments du tablespace.
 
Mais pour plus d'infos, je vous conseille la doc DBA1 de mon site: il y a des infos plus détaillés dessus.  
 
http://www.labo-oracle.com/cours/dba1

La réponse est incomplète.
 
L'équivalent au Vacuum de postgres est effectivement réalisé automatiquement sous Oracle, ainsi que son pendant Vacuum analyze (le tout devrait être automatisé également dans la prochaine version de postgres). Par contre, l'équivalent d'un vaccum full freeze, lui, doit également se faire manuellement, selon la commande donnée par yeyeyo. Dans ce cas, on force l'analyzer a récupérer l'espace obsolèteentre les tuples au lieu de simplement le marque comme récupérable.

+1
Personnellement, j'ai toujours procédé ainsi, même si c'est lent. C'est de loin le moyen le plus efficace, malgré son coté "Remède de grand mère". De nombreux SYSDB Oracle font de même.

le pire, c'est que c'est effectivement MagicBuzz

Je doute qu'il ait dit ça innocement, il suffit de regarder mon profil une seconde, ou même ma signature pour savoir qui je suis.
 
Sinon, je ne répondrai pas à ses propos, on n'a définitivement pas la même notion quant à la maîtrise d'un outils ou d'une technique, le débat n'a pas lieu d'être... Personnellement, je préfère savoir faire un truc, sans avoir la moindre idée de son nom, plutôt qu'utiliser à tord et à travers des noms dont ne je maîtrise pas le sens.