je me trouve confronté à un problème de taille de rollback segment.
Je fais passer un script SQL où j'enchaine les delete sur de grosses tables, mais systématiquement mon rollback segment se retrouve plein pendant l'exécution et la fait planter.
J'ai bien essayé d'insérer un commit après chaque delete mais cela ne vide pas le rollback segment.
Merci si quelqu'un sait comment faire (de préfèrence une commande Oracle).
Publicité
Posté le 26-01-2005 à 16:37:17
Beegee
Posté le 27-01-2005 à 09:38:45
"J'ai bien essayé d'insérer un commit après chaque delete mais cela ne vide pas le rollback segment."
Il me semble que ça doit le vider, mais par contre il est probable que l'un de tes DELETE est trop gros ...
Essaye de le découper en plus petits DELETE en rajoutant des conditions (where ID between ... and ... par exemple).
thecoin
Chasseur de chasseur de canard
Posté le 27-01-2005 à 10:51:52
Il n'existe pas de commande pour faire un fluh du rollback segment. Normalement un commit doit le vider. Soit modifies tes requêtes comme le suggère Beegee ou augmente la taille du rolllback segment.
Beegee
Posté le 27-01-2005 à 11:03:00
En général il vaut mieux avoir une procédure qui fait des commit régulièrement pour éviter que dans le futur, le problème se re-pose parce qu'il y aura plus de données
Si la taille des données devrait être en gros constante, alors augmenter la taille du rollback_segment ou couper le DELETE en un nombre fini de DELETE devrait faire l'affaire.
lapin21
Posté le 02-02-2005 à 18:20:46
Ok merci. Finalement j'ai augmenté la taille des rollback segment, j'avais pas pensé à découper les delete avec les id, en ayant un certain nombre dans mon script....
Message édité par lapin21 le 02-02-2005 à 18:21:48
pains-aux-raisins
Fatal error
Posté le 02-02-2005 à 18:22:01
sinon tu peux faire un truncate (en pensant au préalable à sauvegarder les données à ne pas effacer)
Arjuna
Aircraft Ident.: F-MBSD
Posté le 03-02-2005 à 10:00:02
D'ailleurs, si les delete font bêtement un vidage des tables, il vaut mieu faire un truncate, car c'est infiniement plus rapide (car non rollbackable, et surtout, ça met pas les index à jour au fur et à mesure)