Réorganiser et réduire n'est jamais recommandé.
Si vous pouvez utiliser les applications que la base de données sert en mode hors connexion, vous pouvez accélérer le processus et réduire la fragmentation des index en supprimant tous les index et les contraintes de clé primaire / étrangère avant la réduction (cela signifiera qu'il y a moins de données à déplacer, car seul le les pages de données seront mélangées et non les pages d'index maintenant inexistantes, ce qui accélérera le processus) puis recréera tous les index et les clés.
Recréer les index après la réduction signifie qu'ils ne doivent pas être fragmentés de manière significative. Si vous les supprimez pendant la réduction, leur reconstruction ne laissera pas beaucoup de petits "trous" dans l'allocation de page dans les fichiers susceptibles d'inviter la fragmentation ultérieurement.
Une autre option si vous pouvez déconnecter les applications consiste à migrer toutes les données vers une nouvelle base de données de la même structure. Si votre processus de construction est solide, vous devriez être capable de construire rapidement cette base de données vierge. Sinon, créez-en une à partir de la base de données actuelle (restaurez une sauvegarde de la base de données actuelle, tronquez / supprimez tout le contenu des tables et effectuez une réduction complète).
Vous voudrez peut-être quand même supprimer tous les index de la destination et les recréer par la suite, car cela peut s'avérer beaucoup plus efficace lorsque vous modifiez une grande partie des données indexées (100% dans ce cas). Pour accélérer le processus de copie, placez le (s) fichier (s) de données de la base de données de destination sur différents lecteurs physiques à la source (sauf si vous utilisez des disques SSD, auquel cas vous ne devez pas vous soucier de réduire les mouvements de la tête), vous pouvez les déplacer. à l'emplacement source lorsque vous avez terminé.
De même, si vous créez la destination en tant que nouvelle (plutôt que de masquer une copie de la source), créez-la avec une taille initiale qui contiendra toutes les données actuelles plus quelques mois de croissance, ce qui accélérera la copie des données à nouveau. il ne sera pas allouer un nouvel espace de temps en temps tout au long du processus.
Cela peut être préférable à l’utilisation de shrink, car la migration des données vers une nouvelle base de données reproduit l’action souhaitée de l’opération de réduction, mais potentiellement avec beaucoup moins de fragmentation (conséquence involontaire d’une réorganisation entre deux fonctions). Un raccourci prend simplement des blocs proches de la fin du fichier et les met dans le premier espace plus près du début, ne faisant aucun effort pour conserver ensemble les données associées.
Je pense que le résultat sera également plus efficace du point de vue de l'espace, car il est probable que les pages moins utilisées par la suite. Une réduction ne fait que déplacer les pages partiellement utilisées. Le déplacement des données a plus de chances de générer des pages entières, en particulier si vous insérez dans la destination dans l'ordre de la clé / index en cluster de la table (où une table en a une) et créez d'autres index. après que toutes les données aient migré.
Bien sûr, si vous ne pouvez pas du tout mettre les applications hors ligne, vous ne pouvez qu'effectuer une réduction de volume, donc si vous avez vraiment besoin de récupérer de l'espace, utilisez-le. En fonction de vos données, des modèles d'accès, de la taille de l'ensemble de travail commun, de la quantité de RAM dont dispose le serveur, etc., la fragmentation interne supplémentaire risque de ne pas être très significative.
Pour l’opération de copie, SSIS ou T-SQL de base fonctionnerait tout aussi bien (l’option SSIS pourrait être moins efficace, mais potentiellement plus facile à gérer ultérieurement). Si vous créez les relations FK à la fin avec les index, vous pouvez effectuer un simple "pour chaque table, copier" dans les deux cas. Bien sûr, pour un cas isolé, une rétraction + une réorganisation est probablement acceptable aussi, mais j'aime juste effrayer les gens pour qu'ils ne considèrent jamais les rétrécissements réguliers! (J'ai connu des gens les programmer tous les jours).