SQL Server – Cloner une base de données
Alors vous avez besoin de répliquer une base de données SQL Server, par exemple pour faire des tests, ou bien pour garder une situation figée à un instant « T » pour des consultations ?
Globalement, 2 façons de faire: Dans « SQL Server Management Studio », passer par l’interface graphique en cliquant là où il faut, ou bien taper des lignes de commande.
L’utilisation des lignes de commande est pratique pour des cas particuliers, par exemple si on veut que le clone soit sur un autre disque que la base source. C’est cette méthode que nous allons voir.
ATTENTION : Les indications données ici sont fournies à titre indicatif et n’engagent pas la responsabilité d’ACTIVPART. Il vous appartient de vérifier que vous avez bien des sauvegardes de votre base de données avant de commencer, et de comprendre les manipulations que vous allez faire, et de les adapter à votre contexte.
Les étapes seront les suivantes:
- Localiser les fichiers de la base de données
- Arrêter le service SQL Server,
- Copier les fichiers .mdf et .ndf (données) et .ldf (logs) sur le disque destination,
- Relancer le service SQL Server,
- Déclarer la nouvelle base de données constituée de ces 2 fichiers,
1. Localiser les fichiers de la base de données
A l’aide de Microsoft SQL Server Management Studio. Ici on peut voir que la base de données nommée « SSIFR » est composée de 3 fichiers : 2 fichiers de données .mdf et .ndf, et un fichier de log .ldf. Remarque: les fichiers .ndf sont des fichiers d’extension des données ne sont en général présents que si la base de données dépasse une certaine taille.
2. Arrêter le service SQL Server
Ouvrir une boite de commande en tant qu’administrateur, et taper
net stop mssqlserver
A la fin le système doit vous répondre « service was stopped successfully.‘ ou l’équivalent dans votre langue.
3. Copier les fichiers .mdf (données) et .ldf (logs) sur le disque destination
Les bases de données SQL Server sont composées de 2 fichiers : Un fichier « *.mdf » contenant les données, et un fichier « *.ldf » contenant les logs de transactions.
Exemple : Nous avons une base de données nommée « SalesForce » constituées des 2 fichiers SalesForce.mdf et SalesForce.ldf :
Il se trouve que sur ce serveur notre fichier .mdf : sur le disque D: (1)
Et notre fichier .ldf : est sur le disque E: (2)
Et nous voulons créer notre clone sur le disque G: (3) sur lequel nous avons la place suffisante.
Nous allons donc copier ces 2 fichiers .mdf et .ldf sur G:
Conseil : Donner un nom distinct de ceux d’origine aux deux fichiers du clone, pour éviter toute confusion. Exemple : j’ajoute « clone » dans le nom :
4. Relancer le service SQL Server
Une fois la copie des 2 fichiers terminée : Toujours depuis une boite de commande ouverte en tant qu’Administrateur, tapez « net start mssqlserver » pour redémarrer le service « SQL Server » :
Le système doit vous répondre « service was started successfully« .
5. Déclarer la nouvelle base de données constituée de ces 2 fichiers
Nous allons nommer la nouvelle base de données « SalesForce_CLONE ». La requête SQL à lancer dans notre cas sera :
USE master;
GO
CREATE DATABASE SalesForce_CLONE
ON (FILENAME = 'G:\SalesForce_clone.mdf'),
(FILENAME = 'G:\SalesForce_clone_log.ldf')
FOR ATTACH;
GO
Pour exécuter cette requête, dans « SQL Server Management Studio », passer par « New Query » (1) , tapez la requête (2),
et executez la requête (3) . Un message « Command(s) completed Successfully » confirme le bon déroulement. On peut ensuite utiliser « Refresh » pour actualiser la liste des bases de données opérationnelles:
La nouvelle base de données est accessible :
L’opération de clonage est terminée.
Si vous avez déplacé vos bases clonées sur un autre serveur SQL, vous pouvez tomber sur un message d’erreur de permission. Exemple avec DBeaver :
« SQL Error [916] [S0001]: The server principal « mon_user » is not able to access the database « MA_BASE » under the current security context.«
C’est parce que l’utilisateur « mon_user » du premier serveur n’a probablement pas le même ID interne que ce même utilisateur « mon_user » sur le nouveau serveur.
Pour résoudre ce problème, sur le nouveau serveur, lancez cette requête afin de synchroniser le nom de votre utilisateur avec son compte sur le nouveau serveur :
use MA_BASE EXEC sp_change_users_login @Action='update_one', @UserNamePattern='mon_user',@LoginName='mon_user';
Réferences
Pensez aux autres, laissez vos commentaires et conseil ci-dessous.
