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
Version imprimable
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 ? :P)
La réponse de jmquiche le sous entendait déjà...:mrgreen:Citation:
Envoyé par pacmann
J'aimerai bien savoir quel point de la reponse de jmquiche le sous entend. MerciCitation:
Envoyé par vicenzo
Citation:
Envoyé par rvfranck
Citation:
Envoyé par jmquiche
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?8O
Non un DDL peut faire exécuter un trigger (exemple un ajout de colonne avec un defaut).
Ok, oublions ça. J'ai relu les messages calmement et j'ai essayé de comprendre.
C'est ce message qui m'a embrouiller l'esprit
C'est différent de dire que "TRUNCATE" ne déclenche pas un trigger "DELETE".Citation:
Envoyé par pacmann
J'en ajoute une autre (également déjà sous-entendu) :
Les colonnes de type "auto-incrément" (IDENTITY par exemple) sont réinitialisées.
Oui la difference c'est que TRUNCATE ne déclenche aucun type de Trigger y compris les trigger de Type DELETECitation:
Envoyé par rvfranck
Sauf que sous Oracle, qui est l'objet de ce forum, les colonnes de type auto incrément n'existent pas... Dommage d'avoir réveillé un sujet qui dormait depuis 3 ans pour être à côté de la plaque !Citation:
Envoyé par Vyns1520
Perdu ! Un déclencheur de type DDL peut parfaitement se déclencher suite à un TRUNCATE.Citation:
Envoyé par kdmbella
un truncate viole la sacro sainte read write consistency :kill:
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