Contexte
Une fois, pour reproduire un bug, j'avais besoin d'une sauvegarde de la base de production.
À ma grande surprise, j'ai été confronté aux limitations suivantes :
- La sauvegarde de la base a été réalisée sur la version SQL Server 2016 et n'était pas compatible avec ma SQL Server 2014.
- Sur mon ordinateur de travail, le système d'exploitation utilisé était Windows 7, donc je ne pouvais pas mettre à jour SQL Server vers la version 2016
- Le produit pris en charge faisait partie d'un système plus vaste avec une architecture héritée fortement couplée et faisait également appel à d'autres produits et bases de données, donc son déploiement sur une autre station pouvait prendre beaucoup de temps.
Compte tenu de ce qui précède, j'en suis venu à la conclusion qu'il était temps de recourir à des solutions alternatives.
Récupération des données à partir de la sauvegarde
J'ai décidé d'utiliser une machine virtuelle avec Windows 10 (vous pouvez prendre une image d'essai pour le navigateur Edge ). La machine virtuelle avait SQL Server 2016 installé, et la base de données de l'application a été restaurée à partir de la sauvegarde ().
Configuration de l'accès à SQL Server sur la machine virtuelle
Ensuite, il fallait entreprendre certaines étapes pour permettre l'accès à SQL Server depuis l'extérieur :
- Pour le pare-feu, ajouter une règle pour autoriser les requêtes sur le port 1433.
- Il est préférable que l'accès au serveur se fasse non par l'authentification Windows, mais par SQL avec un identifiant et un mot de passe (plus facile à configurer). Cependant, dans ce cas, il ne faut pas oublier d'activer dans les propriétés de SQL Server la possibilité d'authentification SQL.
- Dans les paramètres de l'utilisateur sur SQL Server, dans l'onglet User Mapping indiquer pour la base de données restaurée le rôle utilisateur db_securityadmin.
Migration des données
La migration des données se compose en fait de deux étapes :
- Migration du schéma des données (tables, vues, procédures stockées, etc.)
- Migration des données elles-mêmes
Migration du schéma des données
Nous effectuons les opérations suivantes :
- Sélectionnez Tasks -> Generate Scripts pour la base de données à migrer.
- Sélectionnez les objets nécessaires à la migration ou laissez la valeur par défaut (dans ce cas, des scripts seront créés pour tous les objets de la base).
- Indiquez les paramètres pour enregistrer le script. Il est plus pratique de sauvegarder le script dans un fichier unique en encodage Unicode. Ainsi, en cas de problème, il ne sera pas nécessaire de répéter toutes les étapes.
Après avoir enregistré le script, il peut être exécuté sur le SQL Server source (version ancienne) pour créer la base requise.
Attention : Après l'exécution du script, il est nécessaire de vérifier la correspondance des paramètres de la base de données à partir de la sauvegarde et de la base de données créée par le script. Dans mon cas, le script manquait la configuration pour COLLATE, ce qui entraînait une erreur lors du transfert des données et des manipulations fastidieuses pour recréer la base à l'aide d'un script complété.
Migration des données
Avant de transférer les données, il est nécessaire de désactiver la vérification de toutes les contraintes sur la base :
EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'Le transfert des données se fait via l'assistant d'importation des données Tâches -> Importer des données sur SQL Server, où se trouve la base créée par le script :
- Nous indiquons les paramètres de connexion à la source (SQL Server 2016 sur une machine virtuelle). J'ai utilisé le Data Source SQL Server Native Client et l'authentification SQL mentionnée ci-dessus.
- Nous indiquons les paramètres de connexion au lieu de destination (SQL Server 2014 sur la machine hôte).
- Ensuite, nous configurons le mappage. Il est nécessaire de sélectionner tous les objets non en lecture seule (par exemple, il n'est pas nécessaire de sélectionner les vues). En options supplémentaires, il convient de choisir «Autoriser l'insertion dans les colonnes d'identité», si de telles colonnes sont utilisées.
Attention : si lors de la tentative de sélectionner plusieurs tables et de leur attribuer une propriété «Autoriser l'insertion dans les colonnes d'identité» la propriété a déjà été définie au moins pour une des tables sélectionnées, la boîte de dialogue indiquera que la propriété est déjà définie pour toutes les tables sélectionnées. Ce fait peut prêter à confusion et entraîner des erreurs de transfert. - Lançons le transfert.
- Nous rétablissons la vérification des contraintes :
EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'
Si des erreurs apparaissent, nous vérifions les paramètres, supprimons la base créée avec des erreurs, la recréons à partir du script, apportons des corrections et recommençons le transfert des données.
Conclusion
Cette tâche se rencontre assez rarement et n'apparaît que pour les raisons mentionnées ci-dessus. Le plus souvent, la solution consiste à mettre à jour SQL Server ou à se connecter à un serveur distant, si cela est compatible avec l'architecture de l'application. Cependant, personne n'est à l'abri d'un code hérité et de l'incompétence d'un développement de mauvaise qualité. J'espère que vous n'aurez pas besoin de ce guide, et s'il s'avère nécessaire, j'espère qu'il vous fera économiser beaucoup de temps et de nerfs. Merci de votre attention !
Liste des sources utilisées
Source : habr.com
