Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQL Oracle Discussion :

Delete de masse (suite)


Sujet :

SQL Oracle

  1. #21
    Expert éminent sénior
    Citation Envoyé par boutss Voir le message
    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à).

  2. #22
    Expert éminent sénior
    le but inital était de pouvoir faire des commits intermédiaires si je ne m'abuse

  3. #23
    Expert éminent sénior
    Citation Envoyé par orafrance Voir le message
    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.

  4. #24
    Membre habitué
    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.

  5. #25
    Expert éminent sénior
    la question reste donc entière : pourquoi insérer avant de supprimer ?

  6. #26
    Expert éminent sénior
    faudrait une trace en plus, il y a surement des contentions sur les rollback

  7. #27
    Membre habitué
    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.

  8. #28
    Expert éminent sénior
    Citation Envoyé par boutss Voir le message
    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.

  9. #29
    Membre habitué
    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.

  10. #30
    Membre averti
    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.

  11. #31
    Expert éminent sénior
    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 ?

  12. #32
    Membre habitué
    Petit supplément
    http://www.aide-oracle.net/2009/04/injection-et-traitements-de-masse.html

    Ps : En me relisant, je me trouve un peu énervé dans les messages, je m'en excuse...

  13. #33
    Expert éminent sénior
    Un autre exemple que sur l’internet on trouve de tout et n’importe quoi.

  14. #34
    Membre habitué
    Pourquoi, c'est une solution dont tu n'adhères pas ?
    J'ai lu en diagonale.

  15. #35
    Expert éminent sénior
    Bah faudrait au moins un bulk collect parce que la suppression ligne à ligne c'est pas super en plus le rowid n'est pas une valeur sûre.