Comment copier un schéma et certaines données de SQL Server vers une autre instance?

Question

Mon produit utilise une base de données SQL Server - chaque client possède sa propre instance déployée sur son propre intranet. Le db a environ 200 tables. La plupart d'entre elles sont des tables de configuration qui ont seulement quelques lignes, mais il y a quelques tables de données de transaction qui peuvent avoir plusieurs millions de lignes. Souvent, j'ai besoin de résoudre le problème de configuration d'un client, j'ai donc besoin d'une copie de base de données pour travailler localement avec mon système de développement ... Cependant, il peut être très important en raison des données de transaction. moi une sauvegarde pour travailler avec. J'ai besoin d'un moyen de sauvegarder/copier/exporter tout sauf pour les grandes tables.

Idéalement, les grandes tables appartiennent vraiment à un catalogue de base de données distinct, de sorte qu'un client peut sauvegarder ses «données» séparément de leur «configuration». Cependant, je n'ai pas le pouvoir de faire ce genre de changement, donc je cherche un bon moyen d'exporter ou de copier uniquement les parties de configuration sans avoir à copier le tout.

Actuellement, j'ai une application .NET rapide et sale qui utilise un adaptateur SQL et DataSet pour sélectionner aveuglément * de tous les tableaux sauf ceux que je veux omettre, vider dans un fichier XML (c'est l'exportation de mon pauvre-homme fonctionnalité). Et j'ai une application compagnon que je peux utiliser localement pour charger le XML dans un DataSet et ensuite utiliser SQLBulkCopy pour le charger dans ma base de données dev. J'ai dû faire quelques trucs pour désactiver les contraintes et ainsi de suite, mais je l'ai fait fonctionner. Cela me donne les données, mais pas le schéma ... idéalement, je voudrais un moyen d'obtenir le schéma avec lui. C'est une approche de force brute, et je crois qu'il doit y avoir un moyen plus simple. Des suggestions pour une meilleure approche?

La solution doit être automatisée étant donné que j'ai affaire à des utilisateurs finaux qui ont généralement très peu de support informatique.

(SQL 2005 et plus)

Answer 1

Je l'ai résolu comme suit. J'ai créé une application Winform personnalisée pour exporter leurs données:

1. utilisation SMO (classe de transfert) à l'écriture l'ensemble du schéma dans un fichier sql
boucle
2. dans toutes les tables spécifiées (en fait j'énuméré juste la grande croissance ceux à ignorer, et traiter tout le reste) en utilisant: select * from
3. capture les enregistrements en objets DataTable et les jeter à .xml
4. Zip tout le dossier à envoyer de nouveau à moi

Et j'ai app ea winform personnalisé J'utilise localement sur mon système dev importer les données:

1. Créer une base de données vide
2. Exécutez le fichier sql pour construire le schéma
3. Désactiver toutes les contraintes sur toutes les tables (à l'aide sp_foreachtable)
boucle
4. dans tous les fichiers .xml et l'importation en vrac les utiliser objet SqlBulkCopy
5. réactiver toutes les contraintes (utilisant sp_foreachtable)

Cette approche fonctionne bien pour ma base de données, mais je ne le conseillerais pas nécessairement pour certaines conceptions de base de données. Dans mon cas, il y a beaucoup de "petites" tables de configuration, et seulement quelques "grandes" tables avec des relations minimales entre elles, donc je peux facilement ignorer les grandes. S'il y avait des relations plus complexes, ce ne serait probablement pas une bonne solution ...

Cela semble fonctionner jusqu'à maintenant. J'espérais trouver un bon moyen de le faire sans écrire de code personnalisé, mais je l'ai fait fonctionner avec seulement quelques heures de dev. Je l'ai presque fait fonctionner avec sqlpubwiz, mais l'option pour écrire des données est tout ou rien ... vous ne pouvez pas ignorer des tables spécifiques ... c'était un deal-breaker pour mon application. L'objet de transfert dans SMO est une classe très utile - il suffit de quelques lignes de code pour scripter un schéma de base de données complet incluant toutes les dépendances dans l'ordre de création correct pour recréer la base de données à partir de zéro!

http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.transfer.aspx

Answer 2

Pouvez-vous générer les scripts de SSMS directement?

1. Faites un clic droit de la base de données
2. Sélectionnez Tâches -> Générer des scripts
3. (Cliquez sur Suivant si vous obtenez l'écran d'intro)
4. Sélectionnez « Sélectionner les objets base de données spécifique »
5. Choisissez les objets pour générer scripts pour (tables, procédures stockées, etc ...)
6. Cliquez sur Suivant, puis spécifiez le nom de fichier de sortie
7. Cliquez sur Terminer pour générer le script

Cela va générer les schémas seulement. Si vous voulez aussi faire des scripts de génération de données, cliquez sur le bouton Avancé à l'étape 6 et faites défiler jusqu'à "Types de données à scripter" et remplacez "Schéma uniquement" par "Données uniquement" ou "Schéma et données"

Dans votre situation, vous pouvez faire "Schéma et données" pour toutes vos petites tables de configuration, puis "Schéma uniquement" pour les grandes tables où vous ne voulez pas exporter les données.

Je sais que ce n'est pas totalement automatisé, mais c'est assez proche. Si vous voulez l'automatiser encore plus, consultez ce fil de discussion. Je ne sais pas si cela fonctionne sur SQL 2005:

How can I automate the "generate scripts" task in SQL Server Management Studio 2008?

Answer 3

Ici, à Red Gate, nous avons un outil appelé SQL Packager qui a une ligne de commande qui peut être automatisé pour effectuer cette tâche.Cela utilise les moteurs SQL Compare et SQL Data Compare sous le capot. Je serais intéressé de recevoir vos commentaires pour savoir si cela répond à votre cas d'utilisation.

http://www.red-gate.com/products/sql-development/sql-packager/

Answer 4

Juste commentaires couple depuis que nous avons eu le même problème dans le passé.

L'option Générer des scripts dans SSMS est idéale pour les petites bases de données dans lesquelles vous pouvez réorganiser manuellement les scripts individuels et éviter les problèmes de dépendance. Je ne sais pas pourquoi tant de gens suggèrent d'utiliser cette fonctionnalité qui a des problèmes de dépendance.

Pour les bases de données plus volumineuses, seule une solution viable est quelque chose comme vous avez créé vous-même ou utilisez des outils tiers.

Nous avons fini par utiliser ce third party tool.SQL Packager a travaillé un peu mieux au moment nous avons évalué, mais nous avons réussi à obtenir l'autre outil essentiellement gratuitement ...

Quoi qu'il en soit, espérons que cette aide, même si elle est une réponse tardive/commentaire ...