Delete et failed to extend segment

Bonjour,

Je souhaite supprimer les données d'une table, en filtrant sur la date < 60 jours. J'ai 3300 dates différentes dans la table donc bcp de données et a chaque fois que j'execute le code suivant :

Code:

---

delete from table where table.date < sysdate - 60

---

j'ai l'erreur Failed to extend Rollback segment.

Comment faire pour que mon delete passe ?
Comment découper mon delete ?

Merci de votre aide,

tu peux commiter toutes les 500 lignes par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

LOOP DELETE FROM table WHERE table.date < sysdate - 60 AND ROWNUM <= 500;   EXIT WHEN SQL%ROWCOUNT=0;   COMMIT; END LOOP; COMMIT; END; /

---

ou encore mieux.

Le probleme vient du fait que tu ecris tes deletes dans les rollback segments et tu dois en ecrire trop.

donc tu cree une table avec les données que tu ne veux pas deleter, puis tu truncate ta table, puis tu importe.

Cela donne:

Code:

---

1 2 3 4 5 6 7 8 9 10

create table ma_table_temp as select * FROM table WHERE table.date >= sysdate - 60 and ROWNUM > 500;     truncate table   insert into table select * from ma_table_temp

---

et tu as gagné du temps.
Et tu n'as pas empeché les autres de travaillé si ta table est enorme

Citation:

---

Envoyé par aline

ou encore mieux.

Le probleme vient du fait que tu ecris tes deletes dans les rollback segments et tu dois en ecrire trop.

donc tu cree une table avec les données que tu ne veux pas deleter, puis tu truncate ta table, puis tu importe.

Cela donne:

Code:

---

1 2 3 4 5 6 7 8 9 10

create table ma_table_temp as select * FROM table WHERE table.date >= sysdate - 60 and ROWNUM > 500;     truncate table   insert into table select * from ma_table_temp

---

et tu as gagné du temps.
Et tu n'as pas empeché les autres de travaillé si ta table est enorme

---

Malheureusement, ça a de bonnes chances d'être un remède pire que le mal, selon la proportion de données à conserver, puisque l'insertion fait aussi appel aux segments d'annulation.

A la rigueur, il faudrait en complément utiliser le mode NOLOGGING, mais personnellement je ne suis pas très friand de son utilisation, car elle remet en cause la sécurité que constituent les fichiers de reprise (redo log files pour ceux qui ne parlent pas français).

Alors il n'y a pas à tergiverser, il faut avoir au moins un segment d'annulation assez gros pour supporter la transaction la plus volumineuse.

Merci de vos aides.

Je vais opter pour la solution N°1 avec le loop, mais m'assurez vous qu'en utilisant le rownum toutes les lignes seront supprimées sans exceptions ?

La seconde solution pourrait me poser aussi des pb de segment.

Et effectivement, seul un segment assez gros ne me poserait pas de pb, cela étant dit, je me trouve dans un environnement de dev qui ne me le permet pas ...

Citation:

---

Envoyé par Pomalaix

Malheureusement, ça a de bonnes chances d'être un remède pire que le mal, selon la proportion de données à conserver, puisque l'insertion fait aussi appel aux segments d'annulation.
.

---

Bon evidement, la proportion de données à conserver entre en jeu et c'est un facteur primordial.
Mais par contre, je ne suis pas entierement d'accord avec toi quand tu compare les insertions et les suppressions au niveaux des écritures dans les redos. Les suppressions sont le cas ou il y a le plus d'écriture et les insertions le moins.

Mais bon, vous faites evidement ce que vous voulez, les conseilleurs ne sont pas les payeurs! :fem:

Citation:

---

Envoyé par elitost

Je vais opter pour la solution N°1 avec le loop, mais m'assurez vous qu'en utilisant le rownum toutes les lignes seront supprimées sans exceptions ?

---

Oui puisque j'arrête les delete (je sors de la boucle) que si il n'y a plus rien à supprimer ;)

Citation:

---

Envoyé par Pomalaix

Malheureusement, ça a de bonnes chances d'être un remède pire que le mal, selon la proportion de données à conserver, puisque l'insertion fait aussi appel aux segments d'annulation.

---

De quelle insertion parles-tu Pomalaix ?
Effectivement, l'insertion par un INSERT classique fait appel aux segments d'annulation, par contre l'utilisation du CTAS (Create Table As Select) qui créée la table et insère les données en une seule passe ne fait pas appel à ces segments.

Citation:

---

Envoyé par Pomalaix

A la rigueur, il faudrait en complément utiliser le mode NOLOGGING, mais personnellement je ne suis pas très friand de son utilisation, car elle remet en cause la sécurité que constituent les fichiers de reprise (redo log files pour ceux qui ne parlent pas français).

---

Tout à fait d'accord avec toi. A moins qu'ELITOST soit sur une base de développement (ou autre) qui ne soit pas en mode ARCHIVELOG.

Citation:

---

Envoyé par Aline

create table ma_table_temp as
select * FROM table
WHERE table.date >= sysdate - 60
and ROWNUM > 500;

truncate table table ;

insert into table select * from ma_table_temp ;

---

A la place, on peut faire aussi :

Code:

---

1 2 3 4 5 6 7

create table ma_table_temp as select * FROM table WHERE table.date >= sysdate - 60 and ROWNUM > 500;   drop table table ;   rename ma_table_temp to table ;

---

Par contre, il faut penser à reconstruire les triggers, les index, les contraintes si il y en a.

Bref, la solution d'Orafrance est de loin la plus simple. :lol:

Citation:

---

A moins qu'ELITOST soit sur une base de développement (ou autre) qui ne soit pas en mode ARCHIVELOG.

---

Aucune idée.

La solution 1 me convient bien , à ceci près sur un problème de date < année 2000 , question que j'ai posé dans un autre post de ce forum.

Je tag résolu pr ma part.

oui, la solution d'orafrance est la plus simple à ecrire, je n'en disconvient pas.
Mais pas la plus rapide ni la plus impactante si il faut faire beaucoup de delete

Le truncate est effectivement une bonne solution si peu de lignes sont concervées et SURTOUT si il n'y a pas de FK sur la table parce que dans ce cas, ça complique énormément la donne :?