Discussion :

[donny]

Bonjour,

J'ai une table dans laquelle je souhaite supprimer env 45000 lignes.
Comment dois je proceder ?
Je sais que faire un delete est tres couteux mais pourquoi ?
parcequ'oracle est obliger de garder une sauvegarde des lignes pour pouvoir faire un rollback.
supposons que je fasse un delete, mis a part que cela prenne des heures,
je risque quoi ?de saturer un tablespace et que ma base soit hs ?


comment pourrai je faire?
sachant que je souhaite supprimer des données qui sont arrivé
entre le 10/07/2009 à 08:00:00 et le 11/07/2009 à 11:00:00?


Merci a tous pour vos réponses.

[NGasparotto]

A partir du moment ou toutes les lignes ne doivent pas etre supprimees, TRUNCATE n'est pas une option.

Combien en pourcent representent les lignes supprimees ?

Nicolas.

[donny]

cela represente environ 1% de la table

[NGasparotto]

cela represente environ 1% de la table

Alors le DELETE est probablement l'option la plus raisonnable.

Nicolas.

[donny]

ok
et il va prendre combien de temps ?

[Waldar]

Ma boule de cristal me dit neuf minutes.
Les autres ?

[donny]

je pense pas que sa prendra 9 minutes
je pense plus que sa prendra plus d'une heure voir plus.
j'ai du mal a saisir en quoi c'est plus optimal

[13thFloor]

9 minutes dis-tu Waldar, moi je dirais...voyons ... 45 000 lignes x un bloc de 8K + l'undo_retention / high water mark de la table, j'y ajoute log_buffer + redo_log/128... allez, à vue de nez... 1/100 du temps d'un delete complet de la table.

@donny : sans vider complètement la table, tu n'as pas d'autres option que le delete.
Si tu veux l'accélérer :
- tu met la table et ses index en mode nologging => bien moins de redo générés
- tu drop les index de la table (hors clé primaire)

Et tu fais l'inverse après le commit;

Ce qui va être long c'est : génération d'undo, de redo, check des foreign key et déclenchement des triggers.

[NGasparotto]

9 minutes pour supprimer 45000 lignes... hmmm... pas gegene ta becanne... moi je dirais... heu... j'en sais rien !

Plus serieusement, personne ne peut repondre a ce genre de question.
Beaucoup trop de parametres a prendre en compte comme la version d'Oracle, l'OS, le(s) CPU(s), les indexes, les disques et types d'arrays....

Mais bon, ceci dit 45000 lignes c'est rien du tout en terme de rollback segment (quoique ca depends pas du nombre de lignes mais de la taille, on va supposer que ca reste raisonnable). Enfin si ce n'est que 1%, ca veut dire que ta table fait 4,5 millions de lignes, ce qui, encore une fois, n'est pas grands chose (meme si, encore une fois, le nombre de lignes ne fait pas tout). Donc si le DELETE est bien ecrit, que t'as un index bien place, que tu n'est pas sur un vieux pentium II 350Mhz, supprimer 45000 lignes sur les 4,5 millions devrait se faire dans un temps "raisonnable", s'il ne l'est pas, alors t'as du boulot pour voir pourquoi.

Nicolas.

[NGasparotto]

@donny : sans vider complètement la table, tu n'as pas d'autres option que le delete.
Si tu veux l'accélérer :
- tu met la table et ses index en mode nologging => bien moins de redo générés
- tu drop les index de la table (hors clé primaire)...

Ca fait quand meme beaucoup de choses pour un delete, tout compte fait pour un petit delete (45000/4,5 millions), c'est rien. Tu risque de passer bien plus de temps a recreer les index apres la suppression de ce 1% de lignes qu'a les supprimer direct.
Enfin, nologging peut avoir d'autre consequences... par ex. si standby database, mais bon.

1/100 du temps d'un delete complet de la table.

Pas si sur ;-)

Nicolas.

[NGasparotto]

...j'ai du mal a saisir en quoi c'est plus optimal

Plus optimal que quoi ?

Nicolas.

[donny]

je connais pas trop tout ce qui est administration Oracle,les performances,j'apprends ...

ce qui me tracasse, c'est que si je fais un delete de ses lignes en faisant
delete from matable where madate between datedeb et datefin,
j'ai peur que la log soit trop grosse et que je me retrouve avec une erreur oracle qui me dise que le redo ou l archive log est saturé....

[NGasparotto]

Pour ce qui est de l'UNDO tablespace, si ca arrive, alors c'est pas grave, tes modif ne seront pas pris en compte, demande au DBA de l'agrandir et re-executes ton DELETE.
Pour ce qui est des archives log (en mode archive), Oracle attendra gentillement que l'espace disque du filesystem contenant les fichiers archives soit libere.

Donc pas vraiment de soucis de ces cotes-la.

Nicolas.

[13thFloor]

Enfin, nologging peut avoir d'autre consequences... par ex. si standby database, mais bon.

Oui mais je pars de l'hypothèse qu'il est avec un base "ordinaire" (pas de rac, de dg, de réplication...) sinon il l'aurait précisé.

C'est beaucoup de choses, certes, mais il craint que son delete se passe mal.
Il y aura beaucoup à faire ensuite s'il met en nologing+drop index.
Et pour 45 000 lignes, ça n'en vaudra surement pas la peine.

[pachot]

Bonjour,

Juste une correction sur:

@donny : sans vider complètement la table, tu n'as pas d'autres option que le delete.
Si tu veux l'accélérer :
- tu met la table et ses index en mode nologging => bien moins de redo générés

nologging n'a pas d'incidence sur un delete. Le logging ne peut être évité que sur les opérations en direct-path (qui écrivent directement dans les datafiles, donc pas de perte en cas de crash serveur) et ce n'est pas le case du delete.

Cordialement,
Franck.