Discussion :

[fulub]

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

[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.

[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

[orafrance]

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

[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.

[fulub]

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

[Z3phur]

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à.

[NGasparotto]

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.

[fulub]

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.

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

[NGasparotto]

...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 ?
Dans ce cas, un index est, bien entendu, comme Z3phur et orafrace l'ont dit, plus que recommande.

Nicolas.

[fulub]

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

Certes. Sans commentaire.

[NGasparotto]

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.

[fulub]

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

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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.