Déplacement de la base de données SQL Server vers un nouveau disque en ligne

J'ai une base de données SQL Server de 1,4 To qui éprouve des difficultés massives avec les E / S de disque. Nous avons installé une nouvelle baie SSD sur le serveur qui résoudra tous nos problèmes, nous débattons simplement de la meilleure façon de déplacer la base de données. Idéalement, si nous pouvons le faire sans temps d'arrêt, c'est mieux. Mais lorsque le choix se situe entre deux jours de performances médiocres (par exemple lors de la copie de données) contre deux heures d'indisponibilité, ces dernières peuvent être préférables.

Jusqu'à présent, les solutions que nous avons trouvées sont:

• Copie simple. Mettez la base de données hors ligne, copiez les fichiers, modifiez les emplacements dans SQL Server et remettez-la en ligne. Des chiffres approximatifs estiment que cela prendra jusqu'à cinq heures, ce qui n'est pas vraiment acceptable, mais c'est la solution la plus simple.

• Copie au niveau du bloc. À l'aide d'un utilitaire de type rsync, nous copions les fichiers en arrière-plan pendant que la base de données est active. Lorsque nous sommes prêts à migrer, nous mettons la base de données hors ligne, effectuons une copie différentielle à travers cet utilitaire, puis pointons le serveur SQL vers les nouveaux fichiers et le mettons en ligne. Le moment ici est inconnu. Nous ne savons pas combien de temps il faudra pour effectuer une analyse différentielle de 1,4 To et la copier à travers. Notre autre préoccupation est que la copie au niveau du bloc laissera les fichiers dans un état illisible par SQL Server et nous perdrons notre temps.

• Migration SQL. Créez un nouveau fichier de données SQL de 1,4 To sur le nouveau disque et désactivez la croissance automatique sur tous les autres fichiers. Exécutez ensuite DBBC SHRINKFILE (-file_name-, EMPTYFILE) sur tous les autres fichiers de données tour à tour. Une fois toutes les données transmises, je prendrai une fenêtre planifiée à un moment donné pour déplacer le fichier MDF vers le SSD et supprimer les autres fichiers inutilisés. J'aime ça car cela minimise les temps d'arrêt. Mais je n'ai aucune idée du temps que cela prendra et si cela entraînera une dégradation des performances pendant qu'il se produit.

Nous n'avons aucun type d'environnement de charge et de performances pour tester cela. Je peux vérifier que les stratégies fonctionneront sur notre environnement de mise en scène, mais pas l'impact et non les performances.

Une méthode pour déplacer la base de données entière est avec BACKUPet RESTORE. La base de données ne sera pas disponible lors du basculement final, mais les temps d'arrêt devraient être minimes lors de la planification. Cette procédure suppose le FULLou le BULK_LOGGEDmodèle de récupération:

1) Effectuez une sauvegarde COMPLÈTE (ou utilisez votre sauvegarde existante).

2) Restaurez la dernière sauvegarde complète dans un nom de base de données différent, en spécifiant l' WITH MOVEoption de déplacer les fichiers sur le stockage SSD comme vous le souhaitez et l' NORECOVERYoption pour que les sauvegardes différentielles et de journaux suivantes puissent être restaurées.

3) Appliquer des modifications incrémentielles à la nouvelle base de données jusqu'au moment du basculement final avec les sauvegardes du journal des transactions et RESTORE...WITH NORECOVERY. Cela minimisera les temps d'arrêt pour le passage final à la nouvelle base de données.

4) Pour basculer vers la nouvelle base de données, mettez l'application hors ligne, effectuez une sauvegarde finale du journal des transactions et appliquez-vous à la nouvelle base de données WITH RECOVERY. Enfin, renommez la base de données d'origine sous un nom différent et renommez la base de données déplacée sous le nom d'origine. Supprimez l'ancienne base de données à votre convenance.

Dans le modèle de récupération SIMPLE, vous pouvez utiliser un processus similaire mais sans la sauvegarde / restauration du journal des transactions de l'étape 3. Utilisez plutôt une sauvegarde / restauration de base de données différentielle à l'étape finale. Cela peut nécessiter plus de temps d'arrêt, selon le nombre de modifications depuis la FULLsauvegarde initiale .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.