Question idiote: quel est le meilleur moyen de copier des instances dans un environnement dans lequel je souhaite actualiser un serveur de développement avec des instances d'un serveur de production?
J'ai effectué une sauvegarde-restauration, mais j'ai entendu detach-copy-attach et un gars m'a même dit qu'il ne ferait que copier les fichiers de données entre les systèmes de fichiers ....
Est-ce que ce sont les trois (ou deux, le dernier semble un peu suspect) des méthodes acceptées?
D'après ce que je comprends, la deuxième méthode est plus rapide mais nécessite un temps d'arrêt de la source en raison de l'aspect détaché.
De plus, dans cette situation (vouloir une copie exacte de la production sur un serveur de développement), quelle est la pratique acceptée pour le transfert de logins, etc.? Devrais-je simplement sauvegarder et restaurer les bases de données utilisateur + master + msdb?
Le moyen le plus rapide de copier une base de données consiste à détacher-copier-joindre, mais les utilisateurs en production n'auront pas accès à la base de données tant que la base de données prod sera 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 n'utilise pendant la nuit.
Si vous ne pouvez pas détacher la base de données de production, vous devez utiliser la sauvegarde et la restauration.
Vous devrez créer les connexions si elles ne sont pas dans la nouvelle instance. Je ne vous recommande pas de copier les bases de données du système.
Vous pouvez utiliser SQL Server Management Studio pour créer les scripts qui créent les connexions dont vous avez besoin. Cliquez avec le bouton droit de la souris sur le nom de connexion que vous souhaitez créer et sélectionnez Script Login As/Create.
Cela va lister les utilisateurs orphelins:
EXEC sp_change_users_login 'Report'
Si vous avez déjà un identifiant et un mot de passe pour cet utilisateur, corrigez-le en procédant comme suit:
EXEC sp_change_users_login 'Auto_Fix', 'user'
Si vous voulez créer un nouvel identifiant et mot de passe pour cet utilisateur, corrigez-le en procédant comme suit:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
Le moyen le plus simple est en réalité un script.
Exécuter ceci en production:
USE MASTER;
BACKUP DATABASE [MyDatabase]
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder.
WITH COPY_ONLY
Cette commande permet de créer une copie de sauvegarde complète de la base de données sur un seul fichier, sans interférer avec la disponibilité de la production ni la planification de la sauvegarde, etc.
Pour restaurer, exécutez ceci sur votre dev ou testez SQL Server:
USE MASTER;
RESTORE DATABASE [MyDatabase]
FROM DISK = 'C:\temp\MyDatabase1.bak'
WITH
MOVE 'MyDatabase' TO 'C:\Sql\MyDatabase.mdf', -- or wherever these live on target
MOVE 'MyDatabase_log' TO 'C:\Sql\MyDatabase_log.ldf',
REPLACE, RECOVERY
Enregistrez ensuite ces scripts sur chaque serveur. Commodité en un clic.
Modifier:
si vous obtenez une erreur lors de la restauration que les noms logiques 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 l'authentification Windows), vous pouvez l'exécuter après chaque restauration (sur la machine dev/test):
use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';
METTRE À JOUR:
Mon conseil ci-dessous vous explique comment scripter une base de données à l'aide de SQL Server Management Studio, mais les paramètres par défaut de SSMS omettent toutes sortes de parties cruciales d'une base de données (comme les index et les déclencheurs!) Pour une raison quelconque. J'ai donc créé mon propre programme pour bien programmer une base de données, y compris à peu près tous les types d'objet de base de données que vous avez éventuellement ajoutés. Je recommande d'utiliser ceci à la place. Il s’appelle SQL Server Scripter et peut être trouvé ici:
https://bitbucket.org/jez9999/sqlserverscripter
Je suis surpris que personne ne l'ait mentionné car c'est vraiment utile: vous pouvez transférer une base de données (son schéma et données) dans un script à l'aide de SQL Server Management Studio.
Cliquez avec le bouton droit sur la base de données, choisissez "Tâches | Générer des scripts ...", puis sélectionnez pour le script des objets de base de données spécifiques. Sélectionnez ceux que vous souhaitez copier dans la nouvelle base de données (vous souhaiterez probablement sélectionner au moins les tables et les schémas). Ensuite, pour l'écran "Définir les options de script", cliquez sur "Avancé", faites défiler jusqu'à "Types de données à écrire" et sélectionnez "Schéma et données". Cliquez sur OK et terminez la génération du script. Vous verrez que cela a généré pour vous un long script qui crée les tables de la base de données et insère les données dans celles-ci! Vous pouvez ensuite créer une nouvelle base de données et modifier l'instruction USE [DbName]
en haut du script afin de refléter le nom de la nouvelle base de données vers laquelle vous souhaitez copier l'ancienne. Exécutez le script et le schéma de l'ancienne base de données et les données seront copiés dans le nouveau!
Cela vous permet de tout faire depuis SQL Server Management Studio, sans qu'il soit nécessaire de toucher au système de fichiers.
Voici ce que je fais pour copier une base de données d’env production vers mon env local:
Il est difficile de détacher votre dB de production ou d'autres dB en cours d'exécution et de faire face à ces temps d'arrêt. C'est pourquoi j'utilise presque toujours une méthode de sauvegarde/restauration.
Si vous voulez également vous assurer de garder vos identifiants synchronisés, consultez le article MS KB on en utilisant le processus stocké sp_help_revlogin pour ce faire.
La méthode detach/copy/attach enlèvera la base de données. Ce n'est pas quelque chose que vous voudriez en production.
La sauvegarde/restauration ne fonctionnera que si vous disposez d'autorisations en écriture sur le serveur de production. Je travaille avec Amazon RDS et je ne le fais pas.
La méthode d'importation/exportation ne fonctionne pas vraiment à cause des clés étrangères - à moins que vous ne fassiez les tables une par une dans l'ordre où elles se référent. Vous pouvez effectuer une importation/exportation vers une nouvelle base de données. Cela va copier toutes les tables et les données, mais pas les clés étrangères.
Cela ressemble à une opération courante, il faut faire avec la base de données. Pourquoi SQL Server ne gère-t-il pas cela correctement? Chaque fois que je devais faire cela, c'était frustrant.
Cela dit, la seule solution indolore que j’ai rencontrée est Sql Azure Migration Tool , qui est maintenue par la communauté. Cela fonctionne aussi avec SQL Server.
Je lance un SP pour supprimer les tables, puis un package DTS pour importer les tables de production les plus récentes sur ma boîte de développement . le lendemain matin. Ce n'est pas élégant Mais cela fonctionne pour moi.
Si vous souhaitez prendre une copie d'une base de données dynamique, appliquez la méthode de sauvegarde/restauration.
[En SQLS2000, pas sûr de 2008:] N'oubliez pas que si vous utilisez des comptes SQL Server dans cette base de données, par opposition aux comptes Windows, si la base de données maître est différente ou désynchronisée sur le serveur de développement, les comptes d'utilisateur ne traduira pas lorsque vous effectuez la restauration. J'ai entendu parler d'un SP pour les remapper, mais je ne me souviens plus lequel.
J'ai utilisé EMS SQL Backup et la tâche d’expédition de la base de données peut être facilement planifiée. Vous devez spécifier le dossier réseau partagé. La copie est également effectuée via sauvegarde/copie/restauration, mais peut être configurée rapidement .. Il semble qu’il n’ya aucune possibilité de gérer les connexions dans le programme et vous devrez le faire manuellement.