2010-02-02 9 views
3

Récemment, j'ai essayé de restructurer une ancienne base de données qui n'était pas conçue avec des groupes de fichiers (seulement PRIMARY par défaut) et, entre autres, de déplacer un groupe de tables vers un nouveau groupe de fichiers résidant sur un SAN. Je sais comment migrer les données:Migration automatisée de groupes de fichiers dans SQL Server

ALTER TABLE MyTable 
DROP CONSTRAINT PK_MyTable WITH (MOVE TO [MyDB_Data]) 

ALTER TABLE MyTable 
ADD CONSTRAINT PK_MyTable 
PRIMARY KEY CLUSTERED (MyID) 
ON [MyDB_Data] 

Mais damné si cela est le travail le plus pénible jamais j'ai dû. Et c'est sujet aux erreurs. À un moment donné, j'étais à mi-chemin (je suppose, puisqu'il n'y a pas d'indicateur de progression) en déplaçant une table de 30 Go avant de réaliser que j'avais accidentellement inclus l'une des colonnes de valeur dans le PK. Donc j'ai dû tout recommencer.

C'est encore pire quand la table a beaucoup de dépendances. Ensuite, je ne peux pas simplement laisser tomber la clé primaire; Je dois laisser tomber et recréer chaque clé étrangère qui le référence. Cela conduit à des centaines de lignes de passe-partout; multiplier par 100 tables et il devient carrément asinien. Mes poignets me font mal.

Est-ce que quelqu'un a trouvé un raccourci pour cela? Existe-t-il peut-être des outils (évalués en fonction de la notion d'utilisation unique) qui peuvent le faire? Peut-être que quelqu'un ici a dû passer par ce processus avant et a écrit son propre outil/script qu'ils ne verraient pas d'inconvénient à partager? SSMS ne le fera pas, évidemment - il ne peut générer que des scripts de migration pour les index non cluster (et ils doivent être des index, pas des contraintes UNIQUE - sur au moins quelques tables, pour le meilleur ou pour le pire, le l'index cluster n'est pas la clé primaire, c'est une contrainte différente de UNIQUE).

Ce n'est pas que la syntaxe est si compliquée que je ne peux pas écrire un code gen pour cela. Au moins pour la partie basique drop-and-recréer-la-clé primaire. Mais ajoutez le temps nécessaire pour trouver toutes les dépendances et générer des scripts drop/recréer pour toutes les clés étrangères et cela commence à se sentir comme si c'était juste au-dessus du seuil où il faut plus d'automatiser et de tester que de faire chaque table manuellement comme avec l'exemple ci-dessus. Donc, la question est: Est-ce que ce processus peut être automatisé d'une manière raisonnablement simple? Y a-t-il des alternatives à ce que j'ai écrit ci-dessus?

Merci!

Répondre

2

La façon la plus simple de le faire, l'OMI, serait d'utiliser l'un des outils de comparaison de schéma (My tool, red gate's SQL Compare, Apex SQL Diff comme quelques exemples) pour créer un script de votre schéma. Ensuite, modifiez ce script pour créer tous les objets, vides, dans les bons groupes de fichiers. Après avoir fait cela, vous pouvez ensuite utiliser les mêmes outils pour comparer votre nouvelle base de données avec les groupes de fichiers corrects, et ils vont générer les scripts pour migrer les données pour vous. Il vaut la peine de tester avec plusieurs pour trouver celui qui vous convient le mieux.

+0

Assez raisonnable. La première partie est facile car j'ai déjà un script de création de base de données, je ne savais pas que les outils de comparaison étaient capables de gérer les mouvements de groupes de fichiers. Merci. – Aaronaught