Restauration de la sauvegarde de la base de données SQL Server sur la version inférieure

185

Comment restaurer un fichier de sauvegarde de base de données SQL Server version supérieure sur une version inférieure SQL Server?

En utilisant SQL Server 2008 R2 (10.50.1600) , j'ai créé un fichier de sauvegarde et maintenant je veux le restaurer sur le SQL Server 2008 de mon serveur en direct (10.00.1600) .

Lorsque j'ai essayé de restaurer la sauvegarde sur SQL Server 2008, cela donne une erreur, c'est Restore Failed-à- dire parce que:

La base de données a été sauvegardée sur un serveur exécutant la version 10.50.1600. Cette version est incompatible avec ce serveur, qui exécute la version 10.00.1600.

Comment restaurer le fichier de sauvegarde sur ce serveur?

sql-server 
— Oreo
source
2
Vous ne pouvez pas faire cela - ce n'est tout simplement pas possible. SQL Server ne permet pas de * rétrograder "une base de données d'une version supérieure à une version inférieure.
— marc_s
18
Microsoft sait tout sur le serveur SQL (depuis sa création) et pourtant, déplacer des données entre 2 versions est impossible. Je ne comprends tout simplement pas pourquoi une sorte de mode de compatibilité n'est pas disponible dans l'exportation. À quel point cela peut-il être difficile?
— dvdmn
1
@dvdmn aussi dur que n'importe quel épisode de Top Gear où ils disent cela - différents types, différentes déclarations, différentes dispositions de bloc. Le déplacement des données entre les bases de données est très simple, quelles que soient les versions concernées. Le déclassement ne l' est pas .
— Panagiotis Kanavos
2
@PanagiotisKanavos Je ne suis pas d'accord, dans mysql, vous pouvez exporter db en tant que commandes sql et vous pouvez le restaurer sur n'importe quelle version de mysql (vers le bas ou vers le haut). Oui, vous pouvez également exporter sql db en tant que script, mais la restauration n'est pas facile si vous avez des fonctions / procédures stockées qui dépendent les unes des autres. Ce n'est fondamentalement pas utile / solution.
— dvdmn
3
@dvdmn exporter les scripts d'une base de données est complètement différent de la sauvegarde. Je me rends compte que certains produits n'offrent pas de fonctionnalité de sauvegarde / restauration ou pire, brouillent les deux concepts. Cela se produit souvent pour des raisons historiques: manque de sauvegarde dans le passé, certains produits appelés exportation / script par ce nom. Maintenant qu'ils le font , ils doivent continuer à résoudre les conflits de termes, en parlant de sauvegardes physiques et logiques, puis se mélanger quand ils parlent de script
— Panagiotis Kanavos

Réponses:

78

Non, il n'est pas possible de rétrograder une base de données. 10.50.1600 est la version de SQL Server 2008 R2 . Il n'y a absolument aucun moyen de restaurer ou d'attacher cette base de données à l'instance SQL Server 2008 sur laquelle vous essayez de restaurer (10.00.1600 est SQL Server 2008). Vos seules options sont:

  • mettre à niveau cette instance vers SQL Server 2008 R2 ou
  • restaurez la sauvegarde que vous avez sur une instance SQL Server 2008 R2, exportez toutes les données et importez-les dans une base de données SQL Server 2008.
— Remus Rusanu
source
Je ne peux pas mettre à niveau le serveur en direct des clients en raison des restrictions d'autorisation. et la taille de ma base de données est supérieure à 2,5 Go, je n'ai donc pas pu créer de script de données en raison d'une erreur d'exception de mémoire.
9
@Gaurav Ne scriptez pas les données - à la place, créez un script pour toute la base de données (tables, procs, déclencheurs, contraintes, etc.) sans données, créez la nouvelle base de données, puis faites un clic droit sur la base de données source, allez dans "Outils", puis "Exporter les données" pour transférer le contenu des tables vers votre base de données.
— Jim McLeod
17
Je me méfie beaucoup d'une réponse «il n'y a pas de solution possible» - cela signifie simplement que vous n'avez pas encore trouvé le chemin. Il peut y avoir plusieurs raisons pour lesquelles vous voulez faire cela, donc ce n'est pas une réponse utile.
— Jay Imerman
6
Je ne suis pas d'accord, @Jay, parfois «vous ne pouvez pas» est la réponse parfaite, bien qu'il soit plus utile d'offrir des solutions de contournement lorsqu'elles sont disponibles.
— Russell Fox
1
@Zhang si vous avez des questions, posez-les sous forme de questions, pas de commentaire.
— Remus Rusanu
83

Vous pouvez utiliser la fonctionnalité appelée Exporter une application de niveau de données qui génère un .bacpacfichier comprenant un schéma de base de données et des données.

Sur le serveur de destination, vous pouvez utiliser l' option Importer une application au niveau des données qui crée et remplit une nouvelle base de données à partir d'un .bacpacfichier pré-créé

Si vous souhaitez simplement transférer le schéma de base de données, vous pouvez utiliser Extract Data-Tier Application pour créer un fichier et Deploy Data-Tier Application pour déployer le schéma de base de données créé.

J'ai essayé ce processus sur différentes versions de SQL Server de SQL 2014 à SQL 2012 et de SQL 2014 à SQL 2008R2 et j'ai bien fonctionné.

— veljasije
source
8
C'est une réponse qui mérite plus d'attention. Cela fonctionne réellement dans la plupart des cas. Si vous avez des utilisateurs SQL qui sont orphelins, les opérations d'exportation échoueront. Vous pouvez toujours supprimer / ajouter ces bits manuellement pour transcender les versions SQL.
— Doctor Blue
3
Je viens d'essayer ceci, pour créer une base de données créée sur MSSQLEX2014 (V12) sur mon MSSQLEX2012 (V11). J'obtiens juste une erreur «Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider n'est pas valide» sans aucun moyen de le changer.
— Craig
5
L'importation de SQL Server 2014 à 2012 à l'aide d'un .bakpac fonctionne, mais nécessite la version correcte de SSMS. Par exemple, j'utilise SSMS 2016 CTP3 et cela a fonctionné parfaitement. Cela n'a PAS fonctionné pour moi en utilisant SSMS 2012. Je n'ai pas testé SSMS 2014.
— Greg Gum
1
Quelqu'un sait-il si l'on peut écrire cette procédure dans T-SQL? UPDATE (me répondant après un peu de recherche sur Google): vous pouvez automatiser cela via la sqlpackage.exeligne de commande. Google pour en savoir plus.
— Alex
1
C'est la seule solution qui a fonctionné pour moi pour rétrograder SQL2017 assez volumineux / compliqué vers SQL2016. Performance également très bonne.
— Keith Blows
35

Ne fonctionnera pas nécessairement

Marchera

  • Génération de scripts - Tâches -> Générer des scripts . Assurez-vous de définir la version cible de SQL Server souhaitée sur la page Définir les options de script -> Avancé . Vous pouvez également y choisir de copier le schéma, les données ou les deux. Notez que dans le script généré, vous devrez peut-être changer le dossier DATA pour les fichiers mdf / ldf si vous passez de non-express à express ou vice versa.

  • Services de publication de base de données Microsoft SQL Server - fournis avec SQL Server 2005 et au-dessus, je pense. Téléchargez la dernière version d' ici . Prérequis: sqlncli.msi/ sqlncli_x64.msi/ sqlncli_ia64.msi, SQLServer2005_XMO.msi/ SQLServer2005_XMO_x64.msi/ SQLServer2005_XMO_ia64.msi(télécharger ici ).

— Ohad Schneider
source
7
La génération de scripts n'est pas fiable pour les bases de données importantes, évitez si possible.
— Chris
Les deux liens en bas sont 404.
— Sнаđошƒаӽ
29

Voici mes 2 cents sur différentes options pour compléter ceci:

Outils tiers : Le moyen le plus simple de faire le travail est probablement de créer une base de données vide sur la version inférieure, puis d'utiliser des outils tiers pour lire la sauvegarde et synchroniser la nouvelle base de données nouvellement créée avec la sauvegarde.

La porte rouge est l'une des plus populaires mais il en existe beaucoup d'autres comme ApexSQL Diff , ApexSQL Data Diff , Adept SQL , Idera …. Ce sont tous des outils premium, mais vous pouvez faire le travail en mode d'essai;)

Génération de scripts : comme d'autres l'ont déjà mentionné, vous pouvez toujours script la structure et les données en utilisant SSMS, mais vous devez prendre en considération l'ordre d'exécution. Par défaut, les scripts d'objets ne sont pas classés correctement et vous devrez vous occuper des dépendances. Cela peut être un problème si la base de données est volumineuse et contient beaucoup d'objets.

Assistant d'importation et d'exportation : ce n'est pas une solution idéale car elle ne restaurera pas tous les objets mais uniquement les tables de données, mais vous pouvez l'envisager pour des correctifs rapides et sales lorsque cela est nécessaire.

— Ken Williams
source
1
Red Gate Sql Clone ne prend pas en charge le clonage entre différentes versions du serveur SQL, signalant exactement la même erreur que celle que j'obtiens en essayant de le faire manuellement.
— DarkDeny
29

Vous ne pouvez pas restaurer la base de données (ou attacher) créée dans la version supérieure vers la version inférieure. Le seul moyen est de créer un script pour tous les objets et d'utiliser le script pour générer la base de données.

entrez la description de l'image ici

sélectionnez "Schéma et données" - si vous souhaitez prendre les deux éléments dans le fichier de script de sauvegarde,
sélectionnez Schéma uniquement - si seul le schéma est nécessaire.

entrez la description de l'image ici

Oui, vous avez maintenant terminé avec le script de création avec le schéma et les données de la base de données.

— Smit Patel
source
16

Une autre façon de faire est d'utiliser la fonction "Copier la base de données":

Recherchez par clic droit la base de données source> "Tâches"> "Copier la base de données".

Vous pouvez copier la base de données dans une version inférieure de SQL Server Instance. Cela a fonctionné pour moi à partir d'un SQL Server 2008 R2 (SP1) - 10.50.2789.0 à Microsoft SQL Server 2008 (SP2) - 10.0.3798.0

— Joy Walker
source
3
Notez que cela ne fonctionnera pas si la cible est SQL Server Express «Le serveur de destination ne peut pas être une instance Express SQL Server 2005 ou version ultérieure». social.msdn.microsoft.com/Forums/en-US/sqlgetstarted/thread/…
— Ohad Schneider
2
Il n'est pas non plus possible de copier une base de données de SQL Server 2012 vers SQL Server 2008 de cette manière.
— Twinkles
1
Copier la base de données est une opération Détacher / Attacher
— Panagiotis Kanavos
1
Merci pour cet indice! Cela m'a beaucoup aidé. J'ai copié les données de SQL 2008 R2 vers SQL 2008.
— dns_nx
8

Vous pouvez essayer ceci.

  1. Créez une base de données sur SQL Server 2008.
  2. À l'aide de la fonction Importer des données, importez des données à partir de SQL Server R2 (ou de toute version supérieure).
  3. utilisez "RedGate SQLCompare" pour synchroniser le script.
— Ishtiyaq Khan
source
6

Allez dans Tâche-> Générer des scripts ...

Dans Avancé dans "Types de données pour le script", sélectionnez "Schema and data"et essayez d'exécuter ce script dans votre version inférieure.

— mathewsun
source
5
C'est une très bonne solution mais fonctionne très mal avec des bases de données plus volumineuses.
— veljasije
5

Ce n'est pas joli, mais c'est comme ça que je l'ai fait si cette option est installée sur votre installation SQL 2008 R2.

1) Faites un clic droit sur la base de données dans SQL Server 2008 R2 "Tâches" .. "Générer des scripts" dans l'assistant, sélectionnez toute la base de données et les objets dans la première étape. À l'étape "Définir les options de script", vous devriez voir un bouton "Avancé", sélectionnez-le et assurez-vous de sélectionner "Script pour la version du serveur" = SQL Server 2008 "et non la version R2. Il s'agit d'une étape cruciale, car" importer des données " en lui-même, n'apporte pas toutes les clés primaires, les constantes et tout autre objet comme les procédures stockées. "

2) Exécutez le script SQL généré sur la nouvelle instance d'installation ou de base de données SQL Express ou SQL Server 2008 à l'aide de la fenêtre de requête ou ouvrez le script .sql enregistré et exécutez et vous devriez voir la nouvelle base de données.

3) Maintenant, faites un clic droit sur la nouvelle base de données et sélectionnez "Tâches" .. "Importer des données .." choisissez la source comme base de données R2 et la destination comme nouvelle base de données. "Copier les données d'une ou plusieurs tables ou vues", cochez la case du haut pour sélectionner toutes les tables, puis à l'étape suivante, exécutez le package et vous devriez avoir tout sur une version plus ancienne. Cela devrait également fonctionner pour revenir à une version 2005. J'espère que cela aide quelqu'un.

— motogeek
source
salut @motogeek, j'ai le même problème, mais j'ai le R2 sur le serveur de production et 2008 sur le local, dans ce cas, je ne peux pas utiliser les données d'importation et d'exportation. quelle serait la solution idéale pour cela?
— Abbas
2

vous pouvez utiliser BCP pour les petites tables.

Commande BCP OUT: -

BCP "SELECT *  FROM [Dinesh].[dbo].[Invoices]" QUERYOUT C:\av\Invoices1.txt -S MC0XENTC -T -c -r c:\error.csv

Commande BCP IN: - Créer une structure de table pour Invoicescopy1. 

BCP [Dinesh].[dbo].[Invoicescopy1] IN C:\av\Invoices.txt -S MC0XENTC -T -c
— Arnav
source
0

J'apprécie qu'il s'agit d'un ancien article, mais il peut être utile que les gens sachent que l'assistant de migration Azure (disponible sur Codeplex - impossible de créer un lien vers est comme Codeplex au moment où je tape ceci) le fera facilement.

— tony.wiredin
source
Cet outil a été remplacé par l'assistant de migration de données SQL Server. Voir: stackoverflow.com/questions/46517060/…
— ahwm
0

Vous devrez utiliser les assistants d'importation / exportation dans SSMS pour tout migrer

Il n'y a pas de "rétrogradation" possible en utilisant la sauvegarde / restauration ou détacher / attacher. Par conséquent, ce que vous devez faire est:

  1. Sauvegardez la base de données à partir du serveur exécutant la nouvelle version de SSMS / SQL.
  2. Importez les données du fichier .bak généré, en développant le menu "Tâches" (après avoir cliqué avec le bouton droit sur la base de données cible) et en sélectionnant l'option "Importer les données".
— tonderaimuchada
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.