Optimiser delete sur table

Version imprimable

16/06/2009, 10h10
fulub

Optimiser delete sur table

Bonjour,

J'ai une procédure d'alimentation d'une base à vocation infocentre. Le traitement fait un 3 millions de delete (ligne à ligne) sur une table et cela dure pendant 85mn. Un commit est fait toutes les 1000 lignes.

Sur une autre table, le delete de 600 000 lignes ne dure que 9mn.

Je voudrais réduire le temps de ce traitement sachant que je n'ai pas la possibilité de modifier la procédure car elle est fournie par un éditeur.

Quelles actions sur la table et/ou sur la base puis je mener afin d'améliorer les performances? Avez vous d'autres idées à me proposer?

Pour information, les statistiques sont calculées 1 fois par semaine en mode compute sur l'ensemble des tables de la base.
Version Oracle : 10.1.0.5
OS : Windows 2003 Entreprise Edition

D'avance merci de votre aide

Philippe
16/06/2009, 10h23
orafrance

Tu peux éventuellement partitionner la table en fonction de la suppression. Par exemple si tu supprimes tous les enregistrements de plus de 30 jours, tu fais une partition par mois. Tu peux aussi vérifier si tu n'as pas trop d'indexes sur ta table.
16/06/2009, 10h53
fulub

Merci de ta réponse.

Je n'ai pas d'index sur la table. Pour le partionnement, il ne fait pas l'objet d'une licence complémentaire ?

Philippe
16/06/2009, 11h11
orafrance

8O pas d'index = FULL TABLE SCAN, cherche pas plus loin, il te faut au moins un index sur la(es) colonne(s) permettant de filtrer les lignes à supprimer :?
16/06/2009, 11h28
Laurent_du_78

La suppression ligne à ligne est malheureusement à proscrire. Oracle et les SGBD ne sont pas fait pour faire du traitement itératif.
Il faut effectivement un index dans ce cas.
16/06/2009, 13h56
fulub

Citation:

Envoyé par Laurent_du_78

La suppression ligne à ligne est malheureusement à proscrire. Oracle et les SGBD ne sont pas fait pour faire du traitement itératif.
Il faut effectivement un index dans ce cas.

Je suis d'accord sur le fait que cela est à proscrire. Mais, comme je l'expliquais au début, je n'ai pas la maîtrise de cette alimentation. Par contre, je dois trouver une solution pour que cela soit plus rapide
16/06/2009, 14h00
Z3phur

Citation:

Envoyé par orafrance

8O pas d'index = FULL TABLE SCAN, cherche pas plus loin, il te faut au moins un index sur la(es) colonne(s) permettant de filtrer les lignes à supprimer :?

La solution est là.
16/06/2009, 14h25
NGasparotto

Citation:

Envoyé par Z3phur

La solution est là.

Peut-etre, peut-etre pas.
Quel pourcentage represente le nombre de ligne supprimees par rapport aux nombre total de lignes ? Apres tout, si on supprime 100% (un infocentre ne regenere-t'il pas une grande partie voire la totalite de ses lignes ?), Oracle risque de faire un full table scan.

Fulub,
Meme si tu n'as pas la main sur le code, est-il possible de faire un extract de la boucle et de le poster ici ? Est-ce vraiment uniquement le DELETE quie met 85 min ?
Et pour les partitions, oui, il s'agit d'une option payante supplementaire a la version Entreprise Edition.

Nicolas.
16/06/2009, 16h03
fulub

Citation:

Envoyé par NGasparotto

Peut-etre, peut-etre pas.
Quel pourcentage represente le nombre de ligne supprimees par rapport aux nombre total de lignes ? Apres tout, si on supprime 100% (un infocentre ne regenere-t'il pas une grande partie voire la totalite de ses lignes ?), Oracle risque de faire un full table scan.

Le nombre de lignes supprimées représente 40% du nombre total de lignes de la table.

Citation:

Meme si tu n'as pas la main sur le code, est-il possible de faire un extract de la boucle et de le poster ici ? Est-ce vraiment uniquement le DELETE quie met 85 min ?
Et pour les partitions, oui, il s'agit d'une option payante supplementaire a la version Entreprise Edition.

En fait, c'est un programme binaire qui constitue une fichier .sql ce dernier étant exécuté. Ce fichier sql contient bien 3 millions de lignes delete from ....
Les 85mn correspondent bien à l'exécution de ce .sql

Merci
Philippe
16/06/2009, 16h06
NGasparotto

Citation:

Envoyé par fulub

...fichier .sql ce dernier étant exécuté. Ce fichier sql contient bien 3 millions de lignes delete from ...

Impressionant ! Quel est ce prog que je n'acheterais pas ? :mouarf:
Dans ce cas, un index est, bien entendu, comme Z3phur et orafrace l'ont dit, plus que recommande.

Nicolas.
16/06/2009, 16h29
fulub

Citation:

Envoyé par NGasparotto

Impressionant ! Quel est ce prog que je n'acheterais pas ? :mouarf:

Certes. Sans commentaire.
16/06/2009, 16h34
NGasparotto

Citation:

Envoyé par fulub

Certes. Sans commentaire.

Desole, c'est sorti du coeur. Plus serieusement, il n'est vraiment pas envisageable de creer un incident chez cet editeur pour qu'il change cet algo ?
Creer un fichier de 3 millions de lignes est tout simplement incroyable.
Sans parler du temps de chargement et de lecture de ce meme fichier...
Moi je trouve que 85 min est plutot honnete dans ce cas.

Nicolas.
16/06/2009, 16h45
fulub

Citation:

Envoyé par NGasparotto

Desole, c'est sorti du coeur. Plus serieusement, il n'est vraiment pas envisageable de creer un incident chez cet editeur pour qu'il change cet algo ?
Creer un fichier de 3 millions de lignes est tout simplement incroyable.
Sans parler du temps de chargement et de lecture de ce meme fichier...
Moi je trouve que 85 min est plutot honnete dans ce cas.

Nicolas.

Pas de souci. Je crois avoir eu la même réaction quand j'ai découvert comment cela fonctionnait. Quant à faire bouger l'éditeur, cela ne va pas être facile, et même cher.

Je fais un test d'index et je vous tiens au courant
16/06/2009, 22h05
pachot

Bonjour,

Un premier problème est le fait de lancer 3 millions de delete différents au lieu de parser un delete et de l'exécuter 3 millions de fois.
Tu peux déjà mettre:

Code:

alter session set cursor_sharing = force;

au début pour éviter ce reparsing à chaque fois.

Un peu mieux serait:
- récupérer la clause where des deletes
- charger les valeurs dans une table temporaire (sqlload)
- faire delete where ... in (select ... from cette table )

Sinon le top pour supprimer 40% des enregistrements, avec cette table temporaire chargée à partir du fichier:
- créer une table avec seulement ce que tu veux garder (create table ... as select ...)
- supprimer l'ancienne table
- renommer la nouvelle table

Citation:

Moi je trouve que 85 min est plutot honnete dans ce cas.

C'est le moins qu'on puisse dire ! C'est même plus proche de la science fiction !
Parce que tu as une table de 7500000 enregistrements (vu que 3000000 representent 40%) et sans index tu ferais 3000000 de full table scan dessus (un full scan pour chaque delete)
Soit j'ai mal lu un chiffre, soit c'est impossible avant une bonne dizaine d'année ;)
Est-tu bien sur qu'il n'y a pas d'index ?

Cordialement,
Franck.