quelle est la différence entre TRUNCATE et DELETE sans WHERE
lequel doit-on privilégier pour seulement enlever toutes les lignes d'une table
afin de pouvoir par sql*loader la recharger intégralement
quelle est la différence entre TRUNCATE et DELETE sans WHERE
lequel doit-on privilégier pour seulement enlever toutes les lignes d'une table
afin de pouvoir par sql*loader la recharger intégralement
Un truncate est plus rapide.
Il y a un commit implicite.
Il ne faut pas que la table soit référencée par une FK
Attention, Le fait que le commit soit implicite fait qu'un truncate est irrémédiable !
Delete, c'est du DML, cela efface les lignes.
Truncate, c'est du DDL, cela inscrit dans le dictionnaire du sgbd que la table est vide.
Le temps de traitement d'un delete dépend du volume dans la table (nombre de lignes, volume disque à scanner, index à réaménager etc...).
Truncate n'accede qu'au dictionnaire pour simplement dire que le table (et les index !) sont vides.
Delete et truncate ne demandent pas les même privileges.
Comme tout DDL, en effet, il y a un commit implicite.
et DELETE ne touche pas à la HWM. Donc un DELETE de toutes les tables d'un tablespace ne suffit pas à réduire la taille des datafiles
Je peux en rajouter une ?
TRUNCATE ne déclenche pas les triggers !
(ouais, je suis content de moi, et alors ? )
Salut,
Je n'ai toujours pas compris, c'est vrai que j'ai la tête dur. Est ce que tu essayes de me dire qu'une DDL ne déclenche pas de trigger?
Non un DDL peut faire exécuter un trigger (exemple un ajout de colonne avec un defaut).
J'en ajoute une autre (également déjà sous-entendu) :
Les colonnes de type "auto-incrément" (IDENTITY par exemple) sont réinitialisées.
un truncate viole la sacro sainte read write consistency
en effet, un truncate pendant un long select ou refresh de mv a un effet imprévisible
Le DELETE est l'une des opérations les plus coûteuses dans Oracle.
En effet, lors d'un DELETE Oracle doit effectuer les opérations suivantes:
- Rechercher les lignes à updater (équivalent à l'instruction SELECT)
- Supprimer les lignes
- Les entrées d’index qui référencent les lignes à supprimer doivent être supprimées de l’index
- Exécuter le code des triggers BEFORE ou AFTER DELETE.
- Vérifier s'il existe des lignes dans une autre table enfant qui référencent des lignes à supprimer dans la table parent (d'ailleurs si la table enfant est volumineuse et qu'il n'existe pas d'index pour la Foreign key cette partie du DELETE peut être cause de lenteur).
- S'il existe des lignes enfants et que la FK est définie en mode "ON DELETE CASCADE" alors ces lignes doivent aussi être supprimées (triggers déclenchés+MAJ des index etc.)
- Génération d'UNDO + REDO
De plus comme l'a dit OraFrance le HWM n'est pas redescendu. Ainsi, même si vous avez supprimé 90% de votre table les prochains Full Table Scan liront tous les blocks comme si la table n'avait jamais été purgée.
Le truncate lui a un coût très faible mais comme l'a dit Laurent c'est une opération irreversible.
Le truncate a 2 modes d'utilisation
- Drop Storage => va restituer les blocks alloués au segment truncaté
- Reuse Storage => Les lignes n'existent plus, le HWM est redescendu mais les blocks restent alloués au segment.
et aussi dans 11.2.0.2
DROP ALL STORAGE
qui restitue tous les extents (y compris le segment initial)
> une opération irréversible
et imprévisible! on ne sait pas vraiment l'effet que ça a sur les requêtes en cours
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager