Version imprimable
Bonjour a Tous
J'ai une question peut etre debile mais c'est pas grave je la pose :)
Pourquoi les DELETE prennent beaucoup plus de place que lors d'insertion en masse ?:mouarf:
J'ai un cas pratiqueou les Insertions prennent a peu pres 6 Go et les DELETE 15 Go, je comprends pas pourquoi :(
l'opération delete il entraîne la mis a jour des indexes en parallèles
n'oublie pas aussi qu'il s'agit d'une opération journaliser
j'ai pas tout compris desole ...
les deux actions sont journalisés non ? :mrgreen:
Bonjour,
Vous parlez bien d'insérer puis de supprimer autant de lignes, en étant seul à travailler sur la base de données ?
@++ ;)
Salut Elkuset
C'est une BDD ou l'on veut archiver des données
on veut inserer ses donnees dans une nouvelle BDD, et ensuite le deleter de la BDD existante, on y arrive parce que les logs explosent en DELETE, alors que c'est 3 fois moins gros
en INSERT sur la nouvelle BDD, je pige pas trop en fait ...
La nouvelle BD a t-elle exactement tous les mêmes index ?
A +
hello SQLpro
non c'est une BDD neuve avec une seule table sans index
Donc, cela s'explique parfaitement.
Dans la suppression sur la table possédant des index, chaque sortie de ligne comme d'index est journalisée.
Dans l'insertion dans la table sans index, chaque insertion de ligne est journalisée, mais comme il n'y a pas d'index, il n'y a pas de nouvelles entrées dans le journal pour ces index absents !
Donc une importante différence de volume.
A +
Je ne sais pas si c'est encore la cas mais avec la version 2008R2, une table non indexée et qui est purgée régulièrement à coup de DELETE (et non de TRUNCATE...) ne libère pas l'espace qu'elle a réservée.
Ce qui faisait qu'une table de quelques milliers de lignes purgée et remplie quotidiennement se retrouvait à prendre une dizaine de Go non employé...
Si tu veut dire par "libération", diminution de la taille d'un fichier, quelque soit les opérations effectuées, il n'y a aucune opération autre que le SHRINK qui permet de diminuer la taille des fichiers...
La purge d'un radiateur, ne diminue pas son volume !
A +
Non je parle bien de l'espace réservé par la table en question, qui devrait normalement resté constante avec les manipulations décrites et avec des maintenances d'index traditionnelles.Citation:
Envoyé par SQLpro
C'est sûr que le corollaire à l'occupation croissante de la table est l’augmentation du fichier de données, c'est d'ailleurs ça qui m'avait fait découvrir ce cas.
La solution pour arrêter cette croissance a été de modifier le DELETE par un TRUNCATE, de faire un SHRINK du datafile et la bd est resté constamment à sa taille de 10 Mo au lieu de ces 10 Go inutilement rempli de vide.
Bizarre, jamais constaté ça...
A +