ProHoster > Blog > administration > Transfert des données de sauvegarde d'une nouvelle version de MS SQL Server vers une version plus ancienne

Transfert des données de sauvegarde d'une nouvelle version de MS SQL Server vers une version plus ancienne

Préhistoire

Une fois, pour reproduire un bogue, j'avais besoin d'une sauvegarde de la base de données de production.

À ma grande surprise, j'ai rencontré les limitations suivantes :

  1. La sauvegarde de la base de données a été faite sur la version SQL Server 2016 et n'était pas compatible avec mon SQL Server 2014.
  2. Sur mon ordinateur de travail, le système d'exploitation utilisé était Windows 7donc je n'ai pas pu mettre à jour SQL Server jusqu'à la version 2016
  3. Le produit pris en charge faisait partie d'un système plus vaste avec une architecture héritée étroitement couplée et parlait également à d'autres produits et bases, de sorte que son déploiement sur une autre station pouvait prendre beaucoup de temps.

Compte tenu de ce qui précède, je suis arrivé à la conclusion que le moment est venu pour les béquilles de solutions non standard.

Restauration de données à partir d'une sauvegarde

J'ai choisi d'utiliser une machine virtuelle Oracle VM VirtualBox avec Windows 10 (vous pouvez prendre une image de test pour le navigateur Edge par conséquent,). SQL Server 2016 a été installé sur la machine virtuelle et la base de données d'application a été restaurée à partir de la sauvegarde (instruction).

Configuration de l'accès à SQL Server sur une machine virtuelle

Ensuite, il a fallu effectuer quelques étapes pour pouvoir accéder à SQL Server de l'extérieur :

  1. Pour le pare-feu, ajoutez une règle pour ignorer les demandes de port 1433.
  2. Il est souhaitable que l'accès au serveur ne passe pas par l'authentification windows, mais par SQL à l'aide d'un login et d'un mot de passe (c'est plus facile de paramétrer l'accès). Cependant, dans ce cas, vous devez vous rappeler d'activer l'authentification SQL dans les propriétés de SQL Server.
  3. Dans les paramètres utilisateur sur SQL Server sur l'onglet Mappage de l'utilisateur spécifier le rôle d'utilisateur pour la base de données restaurée db_securityadmin.

Transfert de données

En fait, le transfert de données lui-même se compose de deux étapes :

  1. Transfert de schéma de données (tables, vues, procédures stockées, etc.)
  2. Transférer les données elles-mêmes

Transfert de schéma de données

Nous réalisons les opérations suivantes :

  1. sélectionner Tâches -> Générer des scripts pour une base portable.
  2. Sélectionnez les objets que vous devez transférer ou laissez la valeur par défaut (dans ce cas, des scripts seront créés pour tous les objets de la base de données).
  3. Spécifiez les paramètres d'enregistrement du script. Il est plus pratique d'enregistrer le script dans un seul fichier Unicode. Ensuite, en cas d'échec, vous n'avez pas besoin de répéter à nouveau toutes les étapes.

Une fois le script enregistré, il peut être exécuté sur le serveur SQL d'origine (ancienne version) pour créer la base requise.

Attention: Après avoir exécuté le script, vous devez vérifier la correspondance entre les paramètres de la base de données de la sauvegarde et la base de données créée par le script. Dans mon cas, il n'y avait pas de paramètre pour COLLATE dans le script, ce qui a entraîné un échec lors du transfert de données et de la danse avec un tambourin pour recréer la base de données à l'aide du script complété.

Transfert de données

Avant de transférer des données, vous devez désactiver la vérification de toutes les restrictions sur la base de données :

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Le transfert de données est effectué à l'aide de l'assistant d'importation de données Tâches -> Importer des données sur SQL Server, où se trouve la base de données créée par le script :

  1. Spécifiez les paramètres de connexion à la source (SQL Server 2016 sur une machine virtuelle). J'ai utilisé la source de données Client natif SQL Server et l'authentification SQL susmentionnée.
  2. Spécifiez les paramètres de connexion pour la destination (SQL Server 2014 sur la machine hôte).
  3. Ensuite, configurez le mappage. Tous doivent être sélectionnés pas en lecture seule objets (par exemple, les vues n'ont pas besoin d'être sélectionnées). Comme options supplémentaires, sélectionnez "Autoriser l'insertion dans les colonnes d'identité"si tel est utilisé.
    Attention: si, lorsque vous essayez de sélectionner plusieurs tables et de définir leur propriété "Autoriser l'insertion dans les colonnes d'identité" la propriété a déjà été définie pour au moins une des tables sélectionnées, la boîte de dialogue indiquera que la propriété a déjà été définie pour toutes les tables sélectionnées. Ce fait peut prêter à confusion et entraîner des erreurs de migration.
  4. Nous commençons le transfert.
  5. Restauration de la vérification des contraintes : 
    EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

Si des erreurs se produisent, nous vérifions les paramètres, supprimons la base de données créée avec des erreurs, la recréons à partir du script, apportons des corrections et répétons le transfert de données.

Conclusion

Cette tâche est assez rare et se produit uniquement en raison des limitations ci-dessus. La solution la plus courante consiste à mettre à niveau SQL Server ou à se connecter à un serveur distant si l'architecture de l'application le permet. Cependant, personne n'est à l'abri du code hérité et des mains tordues d'un développement de mauvaise qualité. J'espère que vous n'aurez pas besoin de cette instruction, mais si vous en avez encore besoin, cela vous fera gagner beaucoup de temps et de nerfs. Merci pour votre attention!

Liste des sources utilisées

Source: habr.com