Shrink Table trop long

Bonjour,

j'ai une table de 10Go, lorsque je fais le shrink space compact j'ai toujours pas fini au bout d'une heure , cela fait gonfler mon tablespace undo, il y a t-il une solution pour éviter cela ou je dois simplement attendre.

Merci d'avance

Bonjour,

Faisant suite à votre message essaie la méthode alter table nomtable move ou bien datapump.
Pour savoir en temps réel, lance une requête sur les vues v$session_wait, v$session et v$sql en jointure.

Question très bête mais qui le serait encore plus si je ne la posais pas : quand on fait un ALTER TABLE ... SHRINK, pourquoi le tbs UNDO gonfle?
Le UNDO, pour moi, sert à défaire des mises à jour de données (UPDATE, INSERT, DELETE, MERGE) mais dans le cas du SHRINK, on a pas juste une réorganisation physique des blocs de données?
Une fois que le ALTER TABLE... SHRINK est OK, pas de message d'erreur, on ne peut pas faire un ROLLBACK car il y a un COMMIT implicite donc comment peut-on utiliser les données dans le tbs UNDO? (en cas de SHRINK qui plante?)...

Bonjour,

Déjà, un shrink table procède en supprimant des lignes et en les réinsérant à un autre emplacement.

Ensuite, les données UNDO ne servent pas uniquement à effectuer les rollbacks. Elles servent également à satisfaire les requêtes des autres sessions qui ne doivent pas voir les modifications non commitées, et à garantir qu'un ordre SQL, aussi long soit-il, se base exclusivement sur les données qui existent au moment où il est lancé.

OK, je ne pensais pas qu'Oracle faisait un DELETE/INSERT pendant un SHRINK, je pensais que c'était géré à un niveau bas, au niveau du bloc physique, pas des données.

Je ne comprends pas cette remarque : "Ensuite, les données UNDO ne servent pas uniquement à effectuer les rollbacks. Elles servent également à satisfaire les requêtes des autres sessions qui ne doivent pas voir les modifications non commitées, et à garantir qu'un ordre SQL, aussi long soit-il, se base exclusivement sur les données qui existent au moment où il est lancé."
Si on fait des INSERT/DELETE lors du SHRINK, c'est forcément sur les données qui ont déjà été commitées (je suis dans le cas où je suis le seul à modifier cette table). Ceux qui font des SELECT vont lire les données qui sont déjà dans la table, on ne les modifie pas avec le SHRINK.