Dois-je migrer des données en utilisant détacher / copier / attacher ou par sauvegarde-restauration-relecture?

Je suis sur le point de migrer des fichiers de base de données vers un nouveau SAN (à partir d'un ancien SAN) et j'ai quelques options pour l'implémenter. (1) Il a été suggéré que j'examine le niveau d'effort de restauration d'une sauvegarde complète dans une nouvelle base de données sur le serveur. Cependant, (2) mon plan initial était de copier les fichiers de l'ancien SAN vers le nouveau SAN en détachant puis en rattachant la base de données.

Mon instinct me dit que je préfère détacher, copier et attacher car cela semble plus sûr, mais c'est peut-être ma naïveté. Je ne veux pas rater une transaction ou "casser quelque chose" dans le processus de changement de nom des bases de données.

Je suppose que ma question est de savoir si je suis justifié ou non dans mon scepticisme à l'égard de l'option BACKUP-RESTORE-Replay et quels sont les autres avantages ou risques de cette option?

Personnellement, j'éviterais les mécanismes de détachement / attachement. Surtout dans SQL Server 2000, je ne suis tout simplement pas convaincu que vous réactiverez toujours le serveur et que vous pourrez joindre ces fichiers. J'ai entendu beaucoup d'histoires où cela ne s'est pas passé proprement - simplement parce que vous avez un plan B ne rend pas automatiquement le plan A sensé.

Avec la sauvegarde / restauration, vous ne risquez pas d'avoir à passer au Plan B. Si la sauvegarde échoue, votre base de données est toujours en place. Si la restauration échoue, votre ancienne base de données est toujours active. Dans les deux cas, vous pouvez restaurer le fonctionnement de la base de données d'origine et revoir le plan ultérieurement. En plus de la sécurité supplémentaire ici sur l'arrêt de SQL Server et / ou le détachement, cela signifie également que vous pouvez tester le hoo-has hors de la méthodologie de sauvegarde / restauration (en supposant que vous disposez actuellement de l'espace pour effectuer les sauvegardes et d'une autre instance pour tester le restaurer). Vous ne pouvez pas vraiment tester l'approche de détachement sans détacher les bases de données ou arrêter SQL Server, et c'est difficile à faire en dehors d'une fenêtre de maintenance appropriée. Et enfin, avec les autres approches, vous ne pouvez même pas commencer à copier les fichiers avant d'avoir détaché ou arrêté SQL Server.

Un autre avantage par rapport à la méthode Pull-the-drive-out-under-SQL-Server: avec la sauvegarde / restauration, vous pouvez déplacer divers fichiers vers des lettres de lecteur différentes de ce qu'ils étaient auparavant. Par exemple, lorsque nous avons migré vers un nouveau SAN, nous avons pu avoir plus de volumes, nous avons donc pu déplacer tempdb vers T: \ (qui n'existait pas auparavant), certaines données et fichiers journaux vers de nouvelles lettres de lecteur, etc. pour mieux utiliser toute la nouvelle capacité d'E / S que nous avions. Si vous arrêtez simplement SQL Server, puis échangez les disques, vous devez avoir les mêmes lettres de lecteur et le même nombre de volumes.

J'ai utilisé pour déplacer des bases de données presque constamment, en raison de la reconfiguration du SAN et des migrations.

En supposant que vous déplacez un serveur entier à la fois, j'irais avec quelque chose comme votre chemin # 2. (Si vous déplacez une base de données à la fois et que vous finissez par effectuer toutes les bases de données sur un serveur, ce serait plus problématique car vous devrez changer les chemins d'accès aux fichiers.)

Notez que "single_user" ne signifie pas nécessairement VOUS. Vous pouvez accéder à DBCC CHECKDB une base de données et ne pas pouvoir y accéder car quelqu'un s'y trouve déjà. Préparez un script que vous pouvez exécuter pour démarrer "tout le monde sauf vous" à partir d'une base de données et conservez-le à un endroit pratique. Notez que SQL 2000 n'a pas les mêmes fonctionnalités «garder tout le monde à l'écart» que les versions plus modernes.

Une vieille astuce consiste à suspendre le service SQL Server. Cela empêchera de nouvelles connexions, mais toute personne déjà connectée peut continuer comme d'habitude. Donc: connectez-vous via une fenêtre SSMS pour pouvoir travailler, puis suspendez le service, puis supprimez les connexions indésirables, faites votre chose via la fenêtre de commande SSMS (pas l'interface graphique, il établit et rompt de nombreuses connexions), puis annulez la pause le service. Avertissement: je ne sais pas comment cela se déroulerait sur un cluster. Il pourrait vouloir basculer.

Il est pratique d'avoir un moyen de garder tous les utilisateurs d'applications hors d'un serveur jusqu'à ce que vous ayez terminé votre travail. Sinon, les connexions peuvent commencer à apparaître lorsque vous essayez de faire des choses, ce qui peut entraîner un conflit de ressources et / ou une lenteur. J'ai utilisé les méthodes suivantes dans le passé, en fonction de la situation exacte: Désactivation du ou des serveurs d'application Utilisation de ALTER DATABASE .. SET RESTRICTED_USER (Si les comptes d'application sont membres des rôles db_owner, sysadmin ou dbcreator, c'est un problème. ) Dire aux utilisateurs que le système sera hors ligne à un moment précis, comme un dimanche matin. (Cela ne fonctionnera pas dans un environnement "pour de vrai" 24x7.) Débrancher la carte réseau qui fait face aux serveurs d'application ou aux utilisateurs. (Dans ce cas, je pourrais entrer via une autre carte réseau connectée à un réseau réservé aux administrateurs ou via l'OIT.)

Détacher un grand nombre de bases de données et les rattacher peut demander beaucoup de travail. Si vous faites cela, assurez-vous que votre script "attaché" est écrit à l'avance.

J'ai eu beaucoup de succès à arrêter SQL Server, à tout copier, à changer les lettres de lecteur et à démarrer SQL Server. Pas de détacher / attacher. Tant que SQL Server est désactivé et que vous copiez (et ne déplacez PAS) les fichiers, vous ne pouvez pas avoir trop de problèmes, même si vous déplacez les bases de données système. Étant donné que les chemins d'accès sont les mêmes, SQL Server ne réalisera pas que quelque chose a changé pendant que le service était désactivé. Assurez-vous simplement que les lettres de lecteur pointent vers les bons volumes, sinon les choses iront mal pour vous.

Mon problème le plus fréquent n'était pas d'obtenir correctement les listes de contrôle d'accès dans les répertoires de fichiers. Les versions plus modernes de SQL Server sont mieux à définir uniquement les autorisations dont le compte de service a besoin tandis que les anciennes versions semblent moins difficiles. Si vous oubliez de définir les listes de contrôle d'accès et que le compte de service n'est pas un administrateur local (ce que je ne recommanderais pas), une ou plusieurs bases de données risquent de ne pas s'ouvrir au démarrage de l'instance. Ne paniquez pas, changez simplement les ACL et attachez la base de données.

J'utilise généralement ROBOCOPY pour faire ce genre de travail. Il existe un commutateur de ligne de commande pour conserver les ACL.

Utiliser un calcul / vérification CRC n'est pas une mauvaise idée, mais je ne l'ai jamais fait. Lorsque les bases de données reviennent, j'exécute CHECKDB () sur chacune d'elles. Je vais généralement préparer un script pour cela à l'avance, plutôt que de compter sur le démarrage manuel d'un travail de maintenance. De cette façon, je peux vérifier quelques bases de données plus petites avant de vérifier une grande base de données qui pourrait prendre plusieurs minutes ou heures pour s'exécuter. Je doute qu'une vérification CRC (ou un outil de comparaison de données Redgate) trouverait quelque chose que CHECKDB () manquerait, et si c'était le cas, SQL Server ne serait pas en mesure de le réparer.

Après avoir copié les fichiers, mais avant de redémarrer l'instance, je vais modifier légèrement le chemin de fichier des anciens dossiers en renommant l'un des dossiers. Il s'agit d'une vérification supplémentaire par rapport au problème "Oups, le serveur pointe toujours vers les anciens fichiers".

Ne soyez pas pressé de supprimer les anciens fichiers et de récupérer de l'espace sur l'ancien stockage et assurez-vous que vos sauvegardes complètes ont réussi. Testez la restauration de quelques-unes de ces sauvegardes ailleurs. Une fois que vous avez de bonnes exécutions checkdb () et de bonnes sauvegardes complètes, vous pouvez alors penser à supprimer cet ancien stockage et à arrêter le Lefthand.

Les pires problèmes que j'ai rencontrés avec ces migrations se sont produits après avoir pensé que j'avais fini. Ce serait l'administrateur du SAN me disant que quelque chose s'était passé et que mes systèmes de fichiers étaient brouillés. (Repartié, reformaté, copié à nouveau.)

Un autre problème amusant est que le SAN est lent sans raison apparente. Si vous pensez qu'il faudra 10 heures pour copier vos données et que vous êtes copié à 30% à l'heure numéro 9, vous avez un problème. Regardez les temps de transfert (robocopy affiche le% copié et donne des estimations de temps, ou vous pouvez utiliser Perfmon) et ayez un plan de secours si quelque chose se passe bizarrement.

De plus, je ne sais pas si vos volumes seront partitionnés pour vous, mais vous voudrez peut-être être sûr qu'ils utilisent un décalage de 1 Mo. Sur Windows Server 2008 et mieux, cela ne devrait pas poser de problème. Sur les anciens OS, c'est le cas. Il y a une tonne de choses googlables à ce sujet, et vos gars du stockage devraient le savoir, mais je demanderais.

Tout d'abord, j'examinerais la possibilité d'utiliser simplement la fonction de la matrice de stockage pour gérer le déplacement des données. Si ceux-ci ne sont pas disponibles parce que le fournisseur ne les prend pas en charge, vous ne les avez pas achetés ou l'administrateur du SAN ne sait pas comment les faire ...

Ensuite, j'utiliserais simplement les étapes suivantes.

1. Présentez le nouveau stockage au serveur SQL.
2. Arrêtez les services SQL
3. COPIEZ toutes les données de l'ancien disque vers le nouveau disque (n'oubliez pas d'inclure les autorisations si vous utilisez robocopy)
4. Supprimez les lettres de lecteur des anciens lecteurs.
5. Modifier les lettres de lecteur sur les nouveaux lecteurs pour correspondre aux anciennes lettres de lecteur
6. Démarrez les services SQL

C'est ça.

Aucun détachement / attachement n'est nécessaire car, pour autant que SQL Server sache, rien n'a changé. Et si quelque chose se passe horriblement mal, vous avez l'ancienne copie des bases de données sur l'ancien LUN sur l'ancienne baie de stockage. Le retour en arrière consiste simplement à changer les lettres de lecteur.