Nous avons une instance SQL Server utilisée pour l'archivage des e-mails (gracieuseté d'un package d'archivage tiers). De temps en temps, le logiciel est transféré dans une nouvelle base de données vide. Nous l'avons fait tous les trimestres dans le passé, mais nous envisageons de le faire tous les mois maintenant. La quantité de données archivées est d'environ 15 à 20 Go par mois et la majeure partie des données ne réside que dans une poignée de tableaux (généralement 2 à 4).
Une fois que nous sommes passés à une nouvelle base de données, l'ancienne devient utilisée en lecture seule. Ce que je voudrais faire, c'est l'optimiser en un joli fichier de données serré, avec toutes les tables / index contigus et ayant un facteur de remplissage très élevé, et pas beaucoup d'espace vide à la fin du fichier de données. De plus, nous utilisons Standard Edition sur ce serveur, avec toutes les limitations que cela implique (sinon j'utiliserais déjà la compression de données).
Quelques possibilités auxquelles je peux penser:
- RECONSTRUIRE / RÉORGANISER les index, DBCC SHRINKFILE (D'accord, ce n'est pas une option raisonnable, car DBCC SHRINKFILE fragmentera l'urine de tout ce qu'il touche, mais je l'inclus pour être complet.)
- Créez une nouvelle base de données avec désactivation des statistiques automatiques. Script et recréez toutes les tables de la base de données source. Utilisez bcp pour exporter / importer les données dans la nouvelle base de données, dans l'ordre des clés de cluster. Script et recrée tous les index. Recalculez toutes les statistiques avec une analyse complète.
- Créez une nouvelle base de données avec désactivation des statistiques automatiques. Script et recréez toutes les tables de la base de données source. Utilisez SSIS ou T-SQL pour transférer des données vers la nouvelle base de données. Script et recrée tous les index. Recalculez toutes les statistiques avec une analyse complète.
La dernière étape dans chaque cas serait de mettre la base de données en mode lecture seule.
Quelles sont les autres bonnes / meilleures options pour ce faire? Ma préoccupation est de déplacer les données de manière à préserver un facteur de remplissage élevé et de manière logiquement contiguë.
Éditer:
Je dois mentionner qu'environ 75% des données semblent être stockées dans des colonnes d'image (LOB).
PRIMARY?Réponses:
Pour éliminer la fragmentation physique des fichiers, vous pouvez aussi déplacer l'index cluster avec drop existant vers un nouveau groupe de fichiers. Comme ils vont être RO, faites-les tous 100% à 100% car aucun espace n'est nécessaire pour les insertions, les divisions de page causées par les mises à jour.
Cela vous permettrait également d'effectuer une restauration fragmentaire et de mettre la base de données en ligne très rapidement si vous décidiez de passer à Enterprise. Enterprise permet également des index columnstore en plus de réduire massivement le temps de requête pour ces données en lecture seule, qui est un congé massif.
Vous pouvez utiliser l'option de rétrécissement une fois avant de passer en lecture seule sans aucun problème sérieux de fragmentation pour supprimer l'espace à la fin du fichier comme vous le souhaitez.
Sur une note latérale, il suffit de vérifier que vous utilisez les derniers types de données pour votre LOBS. c'est-à-dire nvarchar (max) ou varchar (max) au lieu de ntext ou text, varbinary (max) au lieu d'image?
la source
J'ai rencontré un problème similaire avec un outil tiers qui utilisait également un type de données d'image pour stocker des données non structurées, et je l'ai résolu en convertissant la colonne pour utiliser filestream . Vous devrez faire des tests pour vous assurer que l'application fonctionne toujours comme prévu, mais cela vous donnera la possibilité d'écrire votre propre processus d'archivage qui déplace vos données vers une base de données d'archive de manière efficace.
la source