Rétrocompatibilité de SQL Server 2012 pour les sauvegardes avec 2008

J'ai un certain nombre de clients avec SQL Server 2008 et c'est aussi ce que j'ai ici sur mon serveur. J'utilise des fichiers de sauvegarde pour envoyer des bases de données entre les clients et à mon bureau.

J'ai lu que lorsque vous créez une sauvegarde à partir de SQL Server 2012, il n'y a aucun moyen de la restaurer sur une instance 2008. J'ai supposé que le niveau de compatibilité réglerait ce problème, mais ce n'est pas le cas. Par conséquent, je ne sais pas comment mettre à niveau. À part mettre à niveau tous mes clients en une seule fois, ce qui est impossible, je ne vois aucun moyen propre de le faire.

J'ai besoin d'envoyer une base de données à un client ainsi que de recevoir une base de données d'un client. Ceci est ma première mise à niveau de version sur SQL Server, donc je suis nouveau sur ce problème. Des idées sur la façon de procéder?

Il y a deux choses impliquées ici: le numéro de version du fichier et le niveau de compatibilité. Lorsque vous attachez une base de données à une version principale plus récente (comme de 2008 à 2008R2 ou 2008R2 à 2012), la version de la base de données est modifiée de façon permanente et vous ne pouvez plus attacher cette base de données à une version plus ancienne.

Le niveau de compatibilité est utilisé pour analyser T-SQL obsolète qui fonctionnait dans les anciennes versions de SQL Server. Cela ne change pas la façon dont les données sont stockées sur le disque.

Pour donner la base de données à quelqu'un sur une ancienne version de SQL Server, vous devrez exporter les données et l'importer dans une autre base de données. Des outils tels que la comparaison de données de Red Gate sont utiles pour cela.

Le paramètre de niveau de compatibilité est utilisé par SQL Server pour déterminer comment certaines nouvelles fonctionnalités doivent être gérées. De cette façon, une base de données pourrait être migrée vers une version plus récente de SQL sans avoir de problèmes avec l'application. Le niveau de compatibilité peut être modifié d'avant en arrière.

Malheureusement, les fichiers de sauvegarde ne sont pas rétrocompatibles. Une méthode consisterait à utiliser l'importation / exportation pour déplacer vos données de votre base de données actuelle vers votre ancienne instance de version.

Pour les migrations SQL, utilisez l'assistant de migration de base de données SQL gratuit et open source.

J'avais une base de données de 5 Go avec environ 10 millions d'enregistrements et j'ai essayé la route via Generate Script et je l'ai exécutée avec sqlcmd.exe. Tout d'abord, le script généré ne fonctionnait pas toujours correctement. Deuxièmement, sqlcmd.exe peut également échouer sur des fichiers volumineux, se plaignant de la mémoire disponible. osql.exe fonctionne, mais prend juste des âges (et a les mêmes arguments de ligne de commande).

Ensuite, je suis tombé sur un merveilleux outil pour migrer SQL Server vers des bases de données SQL Azure. Cela fonctionne également pour SQL Server vers SQL Server, par exemple si vous souhaitez migrer une base de données SQL 2012 vers 2008 R2. Il utilise bcp.exe, qui utilise une copie en bloc. Il existe une interface graphique et une version en ligne de commande (Batch) disponibles et c'est open source. Voir http://sqlazuremw.codeplex.com/ . Dans mon cas, l'opération a duré 16 minutes.

Dans un écran avancé, vous pouvez sélectionner que votre cible est SQL Server, et non SQL Azure.

J'ai trouvé que BCP était plus efficace que certains des outils pour obtenir des données dans une version antérieure de SQL Server et pour extraire des données de RDS. (Merci @ivan_posdeev.)

Je génère d'abord le schéma en cliquant avec le bouton droit sur la base de données dans SQL Server Management Studio, Tâches, Générer des scripts. Cochez tous les objets, dans les objets avancés, assurez-vous que tout ce dont vous avez besoin sera scripté (statistiques, index, etc.), décochez "UTILISER la base de données" si votre base de données de destination a un nom différent, définissez la compatibilité avec la version de votre base de données de destination et générez un fichier qui crée votre schéma. Créer une base de données sur votre destination et exécuter ce fichier sur ( à l' aide osql, sqlcmdou l'interface graphique).

Pour déplacer les données, exécutez la requête suivante deux fois sur la base de données source , commentant d'abord la deuxième colonne pour générer le fichier de commandes pour extraire les données, puis commentant la première colonne pour générer le fichier de commandes d'importation à exécuter sur votre destination. (Vous devez ajouter vos serveurs source et de destination, les noms d'instance, les répertoires de fichiers de sortie et d'entrée, les noms d'utilisateur et les mots de passe. Pour utiliser la sécurité intégrée, remplacez simplement les options -Uet -Ppar -T.)

Cela prend en charge Unicode, si vous n'en avez pas besoin, changez le -Ncommutateur dans les deux instructions en -n.

SELECT 
   'bcp SOURCEDATABASE.' + s.Name + '.' + t.NAME  + ' out d:\dbdump\' + s.Name + '.' + t.NAME  + '.dat -N -S SOURCESERVER\INSTANCE -UUSER -PPASSWORD'
--    'bcp DESTINATIONDATASE.' + s.Name + '.' + t.NAME  + ' in d:\dbdump\' + s.Name + '.' + t.NAME  + '.dat -N -S DESTINATIONSERVER\INSTANCE -UUSER -PPASSWORD -E -h TABLOCK -b 1000 -e d:\dbdump\' + s.Name + '.' + t.NAME  + '.ERRORS.dat'
FROM 
    sys.tables t
INNER JOIN      
    sys.indexes i ON t.OBJECT_ID = i.object_id
LEFT OUTER JOIN 
    sys.schemas s ON t.schema_id = s.schema_id
ORDER BY 
    s.Name, t.NAME

Après avoir exécuté les fichiers de vérification nommés schema.tablename.ERRORS.dat - inclura toutes les lignes qui ont échoué, vides si aucune ne l'a fait.

Référence MSDN pour BCP ici , promenade plus conviviale à travers les options BCP ici .

J'ai trouvé cela largement supérieur à la génération de scripts et à tous les outils que j'ai essayés. Il fonctionne également sur les bases de données RDS (qui ne permettent pas les sauvegardes). Les fichiers de données générés représentent 30% de la taille des scripts SQL, leur exécution prend une fraction du temps et est beaucoup plus fiable. (Les scripts générés par SQL Server pour les données de script se sont toujours déclenchés, parfois de manière prévisible parfois non, le SQL généré n'était pas compatible avec 2008R2 (par exemple, utilisé nvarchar(0), souvent ne s'est pas terminé sans raison perceptible, etc. BCP réplique également toutes les violations de contraintes , comme l'intégrité référentielle.).