IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Administration Oracle Discussion :

[Tuning] truncate ou delete


Sujet :

Administration Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par défaut [Tuning] truncate ou delete
    Bonjour,

    La version 10G de OEM (version Web) utilise différentes métriques pour mettre en évidence les 'instructions SQL les plus consommatrices de ressources'. Sur une de mes applications (en pro*C), cet outil met en évidence comme instruction un truncate.

    Il s'agit de truncate d'une table d'une colonne dans laquelle je stocke temporairement quelques données (pas plus de 30). Le tout est dans une boucle qui peut s'exécuter plus milliers de fois.
    Sachant que la table est très petite, je me demandais si un Delete * serait pas plus rapide qu'un truncate. Comme un truncate implique un commit, ce n'est peut être pas très efficace de faire tant de transaction ...

    Comme un truncate est plus efficace qu'un delete * sur une grosse table, je me demandais si la réciproque était vraie ?

    Avant de faire des tests concrets je voudrais avoir votre avis

    Phig

  2. #2
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut Re: [Tuning] truncate ou delete
    Citation Envoyé par phig
    Comme un truncate implique un commit
    euhh... non, il n'y a pas de commit avec un truncate

    Alors d'après le gourou j'ai nommé Tom Kyte : le truncate est couteux donc pour les petits volumes c'est plus couteux que le delete même si celui-ci consomme du rollback et du redo. En plus, si il y a un lock sur la table le truncate foire immédiatement

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par défaut Re: [Tuning] truncate ou delete
    Salut Orafrance

    Citation Envoyé par orafrance
    euhh... non, il n'y a pas de commit avec un truncate
    Dans ma doc oracle je lis :
    Commit automatique : Exécution d'un ordre du LDD ou du LCD
    et plus loin je lis encore
    Truncate table est un autre ordre LDD ... vous ne pouvez pas annuler un ordre truncate
    J'ai pas compris un truc alors, car je pensais que si je faisais un truncate dans mon code ça impliquait alors un commit ...

    Sinon merci pour l'info du fameux Tom, je vais appliquer ses conseils sur le champs.

    Phig

  4. #4
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    alors là il y a une grosse boulette effectivement, le truncate détruit immédiatement les données de la table sans passer par les redos et surtout les rollbacks segments... donc c'est pas qu'il y a un commit auto mais surtout que le commit n'est pas nécessaire.

    Si quelqu'un ayant des connaissances théoriques plus sûres que les miennes ce serait gentil d'expliquer les mécaniques du truncate

  5. #5
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/general.htm#11948
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    A TRUNCATE statement does not generate any rollback information and it commits immediately
    j'ai du mal à voir comment commiter quelque chose qui n'utilise pas de rollback... je pense que c'est juste un abus de langage pour montrer que l'effet est immédiat

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par défaut
    pour appuyer mes dires, je te fais part d'une petite expérience personnelle.
    Pour tester un programme (ProC) sur la machine de production , j'avais supprimé tous les commit et mis des rollback à la place. Je testais autre chose que les instructions SQL donc c'est le moyen le plus simple que j'avais trouvé pour les désactiver. Manque de bol, plusieurs instructions avaient quand même été validées. Et c'est là que j'ai découvert que c'était les Truncate qui avait commité la transaction.
    C'et la raison pour laquelle j'ai dit qu'un truncate implique un commit. Maintenant, la réalité est peut être plus subtile que cela...

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par défaut
    vu sur metalink
    Actually TRUNCATE is a DDL, and all DDL does a commit, then the
    data dictionary update, then another commit. The point is, if the
    TRUNCATE fails, there was an implicit commit that preceded the
    attempted TRUNCATE, and commited your transaction that was open up to
    that point.

    So, if session one does an insert into table test1, and does not
    commit, then session two does an insert into table test2, and does
    not commit, then each session has an open (uncommitted) transaction.

    Now, if session two does a truncate of test1 (which has an uncommited
    transaction against it in the session one), the truncate will fail
    with an ORA-0054. However, the insert into test2, which was part of
    the open transaction of session two, is now committed, even if the
    truncate failed.

    The point is, DDL does not do a commit in the transaction it is part
    of. It does a commit, ending any current transaction in the current
    session, then it does a data dictionary update, followed by another
    commit.

  8. #8
    Membre éprouvé
    Inscrit en
    Février 2004
    Messages
    97
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 97
    Par défaut
    Orafrance a raison, c'est un abus de langage, un truncate n'est pas une transaction et on ne peut donc parler de commit.

    D'apres ce que je sais, un Truncate (sans la clause REUSE STORAGE) remet simplement la HWM (High Water Mark) de la table a minextent (d'ou le gain de performace par rapport au DELETE qui genère des redos). Ensuite, les blocs est les extents de la table sont libérés et pourront etre réutilisés par d'autres segments. Ca explique aussi pourquoi ce n'est pas une transaction comme un DELETE.
    Dans un Delete, les lignes sont effacées mais la HWM reste inchangée. Ca a pour effet que meme si la table est vide, la place physique occupée reste inchangée et les memes blocs seront utilisés pour de futurs Insert/Update.
    Une conséquence par ex est l'effet sur les FULL TABLE SCAN. Au cours d'un FTS, tous les blocs sous la HWM sont parcourus (meme s'ils sont vides de données a la suite d'un DELETE). Si la table etait avant le DELETE tres grosse, le FTS sera toujours tres long sur une table pourtant vide. Dans ce cas, c'est plus efficace de faire un TRUNCATE pour que le FTS ne parcours que le minextent.

  9. #9
    Membre éprouvé
    Inscrit en
    Février 2004
    Messages
    97
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 97
    Par défaut
    vu sur metalink
    Citation:
    Actually TRUNCATE is a DDL, and all DDL does a commit, then the
    data dictionary update, then another commit. The point is, if the
    TRUNCATE fails, there was an implicit commit that preceded the
    attempted TRUNCATE, and commited your transaction that was open up to
    that point.

    So, if session one does an insert into table test1, and does not
    commit, then session two does an insert into table test2, and does
    not commit, then each session has an open (uncommitted) transaction.

    Now, if session two does a truncate of test1 (which has an uncommited
    transaction against it in the session one), the truncate will fail
    with an ORA-0054. However, the insert into test2, which was part of
    the open transaction of session two, is now committed, even if the
    truncate failed.

    The point is, DDL does not do a commit in the transaction it is part
    of. It does a commit, ending any current transaction in the current
    session, then it does a data dictionary update, followed by another
    commit.
    Il ne faut pas confondre. La il est question des transaction ouvertes au moment ou le TRUNCATE est lancé. Comme tout DDL, avant d'executer la commande, Oracle fait un commit des transctions ouvertes. Le truncate en lui meme n'est pas commité.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 35
    Par défaut
    vi on est d'accord, ça doit être moi qui me suis mal expliqué dès le début.
    C'est pas grave ça permet de réviser ces classiques , enfin je parle pour moi ...

  11. #11
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    Citation Envoyé par phig
    The point is, DDL does not do a commit in the transaction it is part
    of. It does a commit, ending any current transaction in the current
    session, then it does a data dictionary update, followed by another
    commit.
    c'est donc bien mes dires qui sont confirmés ici

    Merci thomasjcj pour cette explication très claire

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Différence entre TRUNCATE et DELETE ?
    Par HRS dans le forum SQL
    Réponses: 18
    Dernier message: 12/08/2011, 16h07
  2. [9.2.0.6] VM Delete au lieu de truncate
    Par Débéa dans le forum Administration
    Réponses: 0
    Dernier message: 02/07/2008, 09h54
  3. Truncate vs Delete
    Par Débéa dans le forum Administration
    Réponses: 2
    Dernier message: 21/05/2007, 16h51
  4. TRUNCATE vs. DELETE
    Par Sakalam dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 27/11/2006, 18h25
  5. Réponses: 2
    Dernier message: 06/12/2004, 14h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo