Discussion :

[cristophe0071983]

Bonjour à tous,

Plusieurs articles et plusieurs recommandations faites par nos experts sur la commande shrinkfile Qu'est une commande obsolète ,mauvaise pratique et qu'il faut l’utiliser que dans le cas extrême (saturation physique disque)
Cette commande peuvent être faite soit sur le fichier data soit sur le log.

Ma question est la suivante : Est-ce que cette commande a le même effet négatif soit sur le fichier data comme sur le fichier log ?
Aussi, si cette commande entraîne la fragmentation des index si on le fait sur le fichier data quel est leur impact sur le fichier Log ?

Merci pour vos éclaircissements

[SQLpro]

bonjour a tous
Plusieurs article et plusieurs recommandations faite par nos experts sur la commande shrinkfile Qu'est une commande obsolète ,mauvaise pratique et qu'il faut l’utiliser que dans le cas extrême (saturation physique disque)
cette commande peuvent étre faite soit sur le fichier data soit sur le log
Ma question est le suivant : Est ce que cette commande a la même effet négative soit sur le fichier data comme sur le fichier log
aussi si cette commande entraîne la fragmentation des index si on le fait sur le fichier data quel est leur impact sur le fichier Log
merci pour vos éclaircissement

Les fichiers d'une base de données sont par nature toujours en croissances, même si vous procédés à des purges régulières :

1) pour les fichiers de données parce que l'on rajoute toujours de l'information à la base

1.1) même en cas de purge régulière (par exemple purger les données des années passées) par ce que l'on rajoute régulièrement de nouvelles rubriques informatives (par exemple l'apparition d'un nouveau produit avec des caractéristiques particulières, par exemple de nouvelles taxe, des demandes complémentaire de stockages d'informations diverses...)
1.2) parce que par nature, et pour survivre, une entreprise à besoin de croissance. l'activité d'une année passée est donc en général moindre que l'année suivante, rarement le contraire...

2) pour les fichiers de journalisation des transactions du fait de l'accroissement de la volumétrie à traiter dans la même unité de temps :

2.1) soit par l'ajout de nouvelles colonnes à certaines tables ou de nouvelles tables
2.2) soit par l'augmentation du nombre d'utilisateurs effectuant plus de demandes (non journalisées) mais aussi plus de mises à jour (journalisées)

Dès lors, vouloir réduire des fichiers qui par nature ne vont que croitre est comme si vous supprimiez les sièges de votre voiture à chaque fois que quelqu'un en descend !
La commande SHRINK (FILE ou DATABASE) n'est pas du tout obsolète. Elle ne fait pas que réduire les fichiers, mais permet aussi d'en déplacer les données. Elle est très utile dans la cas du DBA qui veut optimiser son stockage, mais il faut l'employer avec parcimonie.
Elle a le même effet sur tous les fichiers (données et transactions), mais sur les fichiers du journal de transaction son effet est beaucoup plus dévastateur car ce dernier est écrit de manière synchrone.
Cette commande n'entraine pas de fragmentation des index. Elle entraine une fragmentation physique des fichiers ce qui est pire car oblige la tête de lecture des disques de se promener afin d'effectuer les différents accès à un même objet (table ou index), et d'ailleurs cette fragmentation physique des fichiers est très difficile à mesurer. La fragmentation "interne" des objets (table ou index) est une fragmentation logique bien moins préoccupante que la fragmentation des fichiers.

Si vous désirez d'autres explication, notre livre sur SQL Server comporte un chapitre de plus de 100 pages consacrées au stockage des données et donc à ces problématiques qui sont extrêmement dommageables pour les performances...

A +