Meilleur moyen pour copier une base de données (SQL Server 2008)

Question

Question stupide - quel est le meilleur moyen pour copier les instances dans un environnement où je veux actualiser un serveur de développement, avec des instances à partir d'un serveur de production?

J'ai fait une sauvegarde-restauration, mais j'ai entendu détachez la copie joindre et un gars m'a même dit qu'il serait juste de copier les fichiers de données entre les systèmes de fichiers....

Ce sont les trois (ou deux, la dernière semble à peu suspect) méthodes reconnues?

Ma compréhension est que la deuxième méthode est plus rapide mais nécessite des temps d'arrêt sur la source en raison de la détacher de l'aspect.

Aussi, dans cette situation (qui veulent une copie exacte de la production sur un serveur de dev) quelle est la pratique acceptée pour le transfert de connexions,etc.? Dois-je sauvegarder et restaurer les bases de données utilisateur + master + la base de données msdb?

Answer 1

Manière la plus simple est en fait un script.

L'exécuter sur la production:

USE MASTER;

BACKUP DATABASE [MyDatabaseName]
TO DISK = 'C:\temp\MyDatabaseName1.bak' -- some writeable folder. I put date and notes in the file name too
WITH COPY_ONLY

Cette une commande crée une copie de sauvegarde complète de la base de données sur un seul fichier (sans interférer avec la production de la disponibilité ou de la planification de sauvegarde, etc).

Pour restaurer, il suffit d'exécuter sur votre dev ou test de SQL Server:

USE MASTER;

RESTORE DATABASE [MyDatabaseName]
FROM DISK = 'C:\temp\MyDatabaseName1.bak'
WITH
MOVE 'MyDatabaseName'   TO 'C:\SqlServer2008\MyDatabaseName.mdf', -- or wherever these live for you
MOVE 'MyDatabaseName_log'   TO 'C:\SqlServer2008\MyDatabaseName_log.ldf',
REPLACE,
RECOVERY

Ensuite enregistrer ces scripts sur la production, de test et de développement. En un seul clic de commodité.

Edit:
si vous obtenez une erreur lors de la restauration que de la logique des noms ne correspondent pas, vous pouvez les obtenir comme ceci:

RESTORE FILELISTONLY
FROM disk = 'C:\temp\MyDatabaseName1.bak'

Si vous utilisez des connexions SQL Server (pas d'authentification windows), vous pouvez exécuter cette après la restauration à chaque fois (sur le dev/machine de test):

use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';

Answer 2

Le moyen le plus rapide pour copier une base de données est à détacher-copie-méthode d'attachement, mais la production, les utilisateurs n'auront pas accès à la base tandis que la prod db est détachée. Vous pouvez faire quelque chose comme ceci si votre base de données de production est par exemple un système de Point de Vente que personne ne l'utilise pendant la nuit.

Si vous ne pouvez pas détacher la base de données de production, vous devez utiliser le programme de sauvegarde et de restauration.

Vous devrez créer les connexions s'ils ne sont pas dans la nouvelle instance. Je ne vous recommande pas de copier les bases de données système.

Vous pouvez utiliser SQL Server Management Studio pour créer les scripts qui créent les connexions dont vous avez besoin. Cliquez-droit sur la connexion, vous devez créer et de sélectionner le Script de Connexion / Créer.

Ce sera répertorie les utilisateurs orphelins:

EXEC sp_change_users_login 'Report'

Si vous disposez déjà d'un identifiant et d'un mot de passe pour cet utilisateur, le fixer en faisant:

EXEC sp_change_users_login 'Auto_Fix', 'user'

Si vous souhaitez créer un nouvel identifiant de connexion et mot de passe pour cet utilisateur, le fixer en faisant:

EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'

Answer 3

Mise à JOUR:
Mes conseils ci-dessous vous indique comment le script de la base de données à l'aide de SQL Server Management Studio, mais les paramètres par défaut dans SSMS manquer toutes sortes de pièces essentielles d'une base de données (comme les index et les déclencheurs!) pour une raison quelconque. Donc, j'ai créé mon propre programme pour bien écrire un script de base de données, y compris juste au sujet de chaque type de DB objet que vous avez ajoutés. Je recommande l'utilisation de ce lieu. Il est appelé SQL Server Scripter et il peut être trouvé ici:
https://bitbucket.org/jez9999/sqlserverscripter

---

Je suis surpris que personne ne l'a mentionné, parce que c'est vraiment utile: vous pouvez vider une base de données (son schéma et données) à un script, à l'aide de SQL Server Management Studio.

Cliquez-droit sur la base de données, choisissez "Tâches | Générer des Scripts...", puis sélectionnez le script de base de données spécifique des objets. Sélectionnez ceux que vous souhaitez copier sur le nouveau DB (probablement, vous voulez sélectionner au moins les Tableaux et Schémas). Ensuite, pour le "Définir les Options de Script" de l'écran, cliquez sur "Avancé", faites défiler jusqu'à "Types de données de script" et sélectionnez "Schéma et les données". Cliquez sur OK, et la finition de générer le script. Vous verrez que cela a généré un long script pour vous qui crée la base de données de tables et insère les données dans leur! Vous pouvez ensuite créer une nouvelle base de données, et de changer l' USE [DbName] déclaration à la partie supérieure du script pour refléter le nom de la nouvelle base de données que vous souhaitez copier à l'ancienne. Exécuter le script et l'ancienne base de données du schéma et les données seront copiées vers le nouveau!

Cela vous permet de tout faire à partir de SQL Server Management studio, et il n'y a pas besoin de toucher au système de fichiers.

Answer 4

Il est difficile de détacher la base de données de production ou d'autres cours d'exécution de la dB et de traiter avec que les temps d'arrêt, j'ai donc presque toujours utiliser une Sauvegarde / restauration de la méthode.

Si vous aussi, vous souhaitez assurez-vous de garder votre connexion de synchronisation consultez l' article base de connaissances microsoft à l'aide de la procédure stockée sp_help_revlogin pour ce faire.

Answer 5

Le détachement/copier/attacher la méthode va prendre vers le bas de la base de données. Ce n'est pas quelque chose que vous voulez dans la production.

La sauvegarde/restauration ne fonctionne que si vous disposez des autorisations d'écriture sur le serveur de production. Je travaille avec Amazon RDS et je n'ai pas.

L'importation/exportation méthode ne fonctionne pas vraiment à cause de clés étrangères - à moins que vous ne les tables une par une dans l'ordre de leur référence à l'un l'autre. Vous pouvez faire un import/export pour une nouvelle base de données. Qui va copier tous les tables et les données, mais pas les clés étrangères.

Cela sonne comme une opération courante qu'on doit faire, avec la base de données. Pourquoi n'est-ce pas SQL Server de la manipulation de ce bien? Chaque fois que j'avais à faire c'était frustrant.

Cela étant dit, la seule indolore solution que j'ai rencontré a été Sql Azure Outil de Migration qui est maintenu par la communauté. Il fonctionne avec SQL Server.