vous avez de bonnes raisons de vous inquiéter car la taille de DB dans SQL Server "suce" souvent. Paul Randal, responsable du moteur de stockage dans SQL 2005, a déclaré que ShrinkDB est très mal écrit. Il trouvera de l'espace vide en prenant les données à la toute fin et en les plaçant au tout début, et continuera ainsi jusqu'à ce qu'il ait de l'espace libre à la «fin» des fichiers DB. À ce stade, il peut ensuite libérer l'espace de SQL Server et le restituer au système d'exploitation. Vous inversez efficacement vos fichiers de base de données, vous verrez donc généralement une fragmentation massive. Vous pouvez lire ses opinions sur ce blog ou sur cette vidéo MCM Internals
Comme pour tout, vous devez d'abord les tester dans votre environnement. Une meilleure façon de procéder consiste à déplacer les données vers un autre groupe de fichiers. Vous pouvez effectuer une reconstruction d'index en ligne avec l'index cluster, puis réindexer dans le nouveau groupe de fichiers. Ensuite, vous pouvez supprimer l'ancien et libérer l'espace et ne présenter presque aucune fragmentation. Notez que cela prendra environ 120% d'espace supplémentaire pendant qu'il fonctionne. Le problème avec cela est que vous avez besoin d'un espace libre supplémentaire, ce qui semble ne pas être le cas. Il s'agit d'une fonctionnalité d'entreprise.
Si l'espace libre est à un niveau si élevé, vous devrez peut-être mordre la balle et rétrécir lentement la base de données un petit morceau à la fois pour éviter de longs processus. Notez que vos données seront fortement fragmentées et vous voudrez tout réindexer à nouveau. Notez qu'après avoir tout réindexé, vous remonterez un peu votre espace utilisé et reviendrez à l'espace libre supplémentaire. Voir les conseils de Brent ici .
En ce qui concerne la quantité d'espace libre qui vous convient, il s'agit de savoir dans quelle mesure vous pouvez vous permettre des activités de fragmentation et de croissance de fichiers. Avec IFI activé, la croissance du fichier est presque instantanée mais vous obtenez toujours une fragmentation. Une bonne règle de base est de pré-allouer autant d'espace que vous pensez en avoir besoin, ou de surveiller la croissance et de l'ajuster périodiquement si nécessaire. Cela réduit la fragmentation physique.
La croissance des fichiers journaux est également beaucoup plus importante. Des fichiers journaux supplémentaires peuvent provoquer une fragmentation VLF. Cela rend vos restaurations beaucoup plus lentes et peut affecter le point de contrôle / tronque. Voici quelques risques de performances que vous prenez avec un journal fragmenté. Faites un DBCC LOGINFO();sur chaque base de données. Essayez de garder le nombre autour de 50ish par Kim Tripp, mais si vous voyez des centaines, vous avez des problèmes de fragmentation, ce qui signifie que vos fichiers journaux ont dû augmenter pour prendre en charge les opérations. Un bon moyen de voir ce que devrait être votre fichier journal selon Paul Randal est de le laisser croître pendant une semaine et de réindexer. Cela pourrait être un bon point, peut-être que vous pouvez y ajouter un peu plus d'espace libre au cas où. Assurez-vous que vos journaux ne sont pas fragmentés avec DBCC LOGINFO (); encore et s'ils le sont, cela signifie qu'ils ont beaucoup grandi. Réduire et ré-développer le fichier journal à l'aidecette méthode .
