Delete de masse (suite)

**mnitu** · 24/06/2008, 14h27

Envoyé par boutss

Mais si j'utilise une table temporaire c'est que j'ai un traitement intermédiaire.

En 99% des cases la table temporaire est la pour plomber les performances (ce que ton exemple démontre déjà).

**orafrance** · 24/06/2008, 15h51

le but inital était de pouvoir faire des commits intermédiaires si je ne m'abuse

**mnitu** · 24/06/2008, 16h15

Envoyé par orafrance

le but inital était de pouvoir faire des commits intermédiaires si je ne m'abuse

Le but initial est

J'ai un problème de performance concernant la suppression de masse.

Vu que en fait au lieu de supprimer le 3 millions enregistrements le traitement copie les 3 millions et ensuite les supprime ça ne m’étonne pas qu’il a des problèmes de performance.

**boutss** · 24/06/2008, 16h29

Merci mnitu de t'occuper de mon problème mais tu t'égares.
Ton analyse me semble bien hâtive.

Ce n'est pas l'insertion mon souci mais bien la suppression, le temps est chronométré après l'insertion et non avant ?!

Et le but est bien d'optimiser la suppression avec ou sans commit intermédiaire.

**orafrance** · 24/06/2008, 16h35

la question reste donc entière : pourquoi insérer avant de supprimer ?

**orafrance** · 24/06/2008, 16h36

faudrait une trace en plus, il y a surement des contentions sur les rollback

**boutss** · 24/06/2008, 16h41

Et bien l'insertion me permet d'extraire des données par concept (un concept pouvant être mappé sur plusieurs tables, table de lien).
En gros je fais une sélection et je travaille dessus.

C'est un batch d'extraction : Je créé des fichiers CSV et ensuite je supprime les données.

Pour tout dire bien sûr que je me séparerais d'une étape supplémentaire si je n'en avais pas besoin.

Mais bon, je pense que l'on peut résumer mon problème à un delete simple de 3 millions d'enregistrements sans jointure, si vous préférez.

PS : Mais tu as raison, normalement on utilise les tables temporaires pour travailler par lot.

**mnitu** · 24/06/2008, 17h34

Envoyé par boutss

Merci mnitu de t'occuper de mon problème mais tu t'égares.
Ton analyse me semble bien hâtive.
...

Je ne pense pas. Essaie de t’affranchir de la table temporaire et on reparlera.
Juste pour tester, si tu supprimes les données comme je le suggère c’est pareil ?
Sinon je ne vois pas en quoi tu as besoin d’une table temporaire pour l’instant.

**boutss** · 24/06/2008, 17h43

Je n'aurai pas du mettre la table temporaire ça embrouille les esprits.

En fait j'ai le problème lorsque je fais comme tu as dit :

Code :

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

delete from table1 where etatobjet=1

et que la suppression supprime X millions de données et cela est du en grosse partie aux rollbacks segments qui sont créés.

Le delete de masse quoi !

Une solution qu'il faut que je teste c'est la recopie des données à conserver pour faire un truncate par la suite. 2 fois insert peut couter moins qu'un seul delete de même taille voire plus petite.

Merci en tout cas.

**jmguiche** · 24/06/2008, 20h19

Si tu copie les données vers une autres, elles seront toujours dans la table initiale et le probleme sera le même !
Les solution avec des delete en PL ne convient pas ?
Tu dois donc trouver une solution sans delete et jouer du truncate.

Piste 1 : Si ton traitement doit traiter tout les types puis les deleter, traite tout les types sans delete et fais un truncate à la fin.

Piste 2 :Si tu dois laisser la table initiale disponibles pour d'autres insert, je ne vois pas d'autres solution que de bloquer les insert un court instant :

tu lock la table initiale,
Tu la rename, (initial_old)
tu crées une table initiale vide (les traitements d'insert peuvent reprendre)
tu traites ta table initiale_old (sans delete)
tu la drope

Il faut que les traitement d'insert sachent traiter les attentes de verroux et l'absence (courte) de la table initiale ou sachent s'arreter quand tu fais la manip ci dessus.

Piste 2, Variante : Il est aussi possible de faire ça en jouant avec des synonymes.
le principe et de jongler avec 2 tables initiales (initiale1 et initiale2)
Quand tu lance ton traitement, si le synonym "initial" pointe sur initial1 tu fais :
Create or replace synonym initial for initial2

Piste 3 : si tu as l'option partition, fais une partition par type et utilise truncate.

Piste 4 : crée une table par type et modifie tes programmes d'insert....

Piste 4, variante : si tu ne peux pas modifier les programmes d'insert, crée quand même une table par type et garde ta table initiale.
Un trigger on insert dans la table initial fait un insert dans les autres tables en fonction du type.
Tu traite les tables type et les "truncate".
Tu truncate de temps en temps ta tables initiale.
C'est "un peu" capilotracté, il y a une petite perte de perfe au insert de la table initiale, mais cela doit marcher.

La première solution est la plus performante et la moins chere à mettre en oeuvre.
Sinon, la solution la plus performante est celle des partitions, mais c'est la plus chere (il faut l'option). Celle avec le synonym ne marche que si tu peux traiter tout les types et faire truncate à la fin, celle avec le trigger m'amuse beaucoup (il m'en fait peu), mais il y a la dégradation de perfs aux inserts.

Si tu dois laisser des inserts se faire pendant le traitement, je ne vois que les synonymes.

**mnitu** · 24/06/2008, 20h54

Je ne sait pas quelles esprits sont embrouillé

Quand tu dit

...
Ce n'est pas l'insertion mon souci mais bien la suppression, le temps est chronométré après l'insertion et non avant ?!
...

a tu conscience que cet insert utilise lui aussi les segments de rollback pour copier exactement les mêmes données que le delete ? Réfléchie un peu et tu verra que insert into table temporaire vaut le delete de la table.
Mais comme tu sait déjà (je me demande comment à part la suggestion d'orafrance) que c'est un problème de segments de rollback cela veut dire que t'a résolu ce problème, n'est pas vrai ?