Puis-je restaurer un fichier .bak SQL Server sans SQL Server?

16

J'ai des .bakfichiers volumineux provenant d'un vidage SQL Server 2005.

Puis-je les restaurer sans utiliser SQL Server, ni sur PostgreSQL, MySQL, ni sur des fichiers texte plats?

Une solution open source serait très utile.

Abe
la source
1
"Je préférerais ne pas avoir à le faire uniquement pour cette tâche." Pourquoi pas? C'est la façon de faire ce que vous essayez de faire.
swasheck
Est-ce que restaurer quelque chose d'autre a même un sens? Que voulez-vous faire avec les données résultantes?
Philᵀᴹ
1
@Phil Je voudrais déplacer les données résultantes vers une base de données PostgreSQL, ou même des fichiers texte plats.
Abe
1
@swasheck J'ai supprimé la ligne citée, car elle semble avoir nui à la question. Mais pour répondre à votre question, car je ne sais pas comment l'utiliser, et mon serveur fonctionne sous Linux. Un ordinateur portable Windows disponible n'a pas assez de place.
Abe
2
Eh bien, ce sont des informations que nous n'avions pas auparavant :). Merci pour les informations supplémentaires - j'ai un plan
swasheck

Réponses:

19

Voici ce que je propose:

  1. construire une machine virtuelle exécutant Windows, avec suffisamment d'espace disque pour contenir la sauvegarde. Copiez-y le fichier de sauvegarde. Si vous n'avez pas déjà la possibilité de créer des machines virtuelles, vous pouvez le faire avec des produits gratuits comme Oracle VirtualBox .
  2. téléchargez et installez l'édition d'évaluation de SQL Server . Assurez-vous d'inclure à la fois le moteur de base de données et les outils de gestion - terminés.
  3. si la machine virtuelle a suffisamment d'espace pour contenir la sauvegarde mais pas assez pour la restaurer également, vous pouvez effectuer une "restauration virtuelle" en utilisant la version d'essai d'un produit de Red-Gate du même nom (qui vous permet d'interagir avec le fichier de sauvegarde comme s'il avait été restauré). Sinon, restaurez la base de données normalement .

  4. Une fois la base de données disponible (via une restauration normale ou une restauration virtuelle), vous pouvez générer des scripts pour le schéma et les données de la manière suivante:

    • Ouvrez Management Studio et connectez-vous à votre instance.
    • Ouvrez l'Explorateur d'objets.
    • Cliquez avec le bouton droit sur votre base de données nouvellement restaurée, choisissez Tâches> Générer des scripts ...
    • Cliquez sur Suivant, cliquez sur Suivant
    • Sur la page "Choisir les options de script", faites défiler vers le bas et définissez "Données de script" sur True
    • Cliquez sur Suivant
    • Vérifiez tous les objets pertinents et cliquez sur Suivant
    • Cochez les tables souhaitées et cliquez sur Suivant
    • Choisissez de créer un script dans un fichier. Maintenant, vous aurez un fichier qui contient tous vos objets et données en utilisant la syntaxe d'insertion SQL Server, vous devrez jouer avec la sortie pour l'obtenir dans un format qui fonctionne pour Postgres (je ne suis pas au courant de différences de syntaxe mineures).

Alternativement, vous pouvez essayer de jouer avec l' utilitaire bcp pour extraire des données dans des fichiers CSV ou similaires, mais vous devrez le faire table par table ou utiliser des scripts intelligents (PowerShell, T-SQL, C # / SMO, etc. ) pour générer toutes les commandes bcp pour vous. Une fois dans les fichiers CSV, il devrait être trivial de charger en masse les données dans Postgres (mais vous aurez encore du travail pour générer les tables).

Comme dernière suggestion, si le fichier .bak n'est pas ginormous et que les données ne sont pas confidentielles, je suis plus que disposé à essayer de générer des fichiers pour vous dans le format dont vous avez besoin. J'ai beaucoup de machines virtuelles Windows avec de l'espace, le défi serait d'obtenir le fichier .BAK à un endroit où je peux le récupérer - surtout s'il est plus grand que la plupart des services de partage de fichiers pris en charge.

Aaron Bertrand
la source
+1 J'allais suggérer la méthode bcp une fois arrivé à un ordinateur. Certains pièges sont des délimiteurs de table, IDENTITY (séquence, en pg), nvarchar, pour n'en nommer que quelques-uns. Sinon, c'est ce que j'aurais suggéré (sans Red-Gate) dans ma section d'édition.
swasheck
Il y a 8 fichiers .bak de 20 Go et ce serait bien si vous pouviez aider, mais veuillez consulter les questions connexes sur gis.se, gis.stackexchange.com/q/28281/3218 et gis.stackexchange.com/q/28257 / 3218 sur la base de données des sols de l'USDA (SSURGO). Il est actuellement très difficile d'utiliser l'accès à ces données de manière automatisée pour la modélisation par simulation. Ce serait un grand avantage pour la science d'avoir ces données dans une structure plus utilisable. Vous pouvez le télécharger depuis mon serveur. Les données ne sont pas confidentielles, tout le monde peut les obtenir pour 50 $ / CD ou 100 $ / DVD ou peut-être moins de leur agent d'extension.
Abe
Il semble que vous ayez des réponses sur la façon d'obtenir les données sur GIS.SE. Je suis allé voir ces sites mais je ne vois pas où ils spécifient que le fichier est une sauvegarde SQL Server. Comment / d'où avez-vous obtenu ces fichiers?
swasheck
7

Malheureusement, il n'y a aucun moyen d'accéder au contenu d'un fichier .bak sans avoir une connaissance approfondie de l'intérieur du fichier lui-même. Je peux penser à une personne ici qui pourrait avoir accès à ces informations, mais je ne peux pas dire si cette personne vous dirait comment procéder.

Vous devrez donc installer une instance SQL Server. Vous devrez également vous assurer que cette instance peut parler à votre serveur Postgres (frigging avec le pg_hba.conf) Une fois là-bas, vous avez quelques bons chemins pour migrer les données.

Le premier chemin serait d'installer le pilote ODBC de Postgres Windows et de configurer une connexion au serveur pg. Vous pouvez ensuite utiliser SSIS pour créer un script de migration de données. Si vous allez suivre cette voie, je vous suggère d'installer SSIS lors de l'installation du serveur de base de données.

L'autre option implique également la connexion du pilote ODBC, mais vous pouvez créer un serveur lié dans SQL Server et exécuter des insertions sur l'instance pg via SQL Server. J'ai déjà répondu à cette question ici, donc cela ne devrait pas être difficile à trouver.

ÉDITER

Pour intégrer le commentaire d'Aaron, une fois SQL Server opérationnel, vous pouvez également exporter les données vers des fichiers plats de différentes manières. Si vous choisissez ce chemin, faites-le moi savoir et je posterai quelques façons de le faire

MODIFIER (2):

Le processus de serveur lié n'est peut-être pas la meilleure approche, sauf si vous souhaitez créer les structures à l'avance. C'est ma méthode préférée, mais j'ai généralement déjà la structure en place des deux côtés.

Cela laisse la réponse d'Aaron Bertrand comme la meilleure réponse. Veuillez noter qu'en plus des types de données ( IDENTITYvs SEQUENCE, postgres ne sait rien NVARCHARdepuis que vous avez défini l'encodage sur la base de données elle-même). Postgres n'en sait rien CREATE CLUSTERED INDEX( CLUSTERpeut fonctionner pour vous). Enfin, comme je vois dans les commentaires que vous allez utiliser des données spatiales, postgresql ne connaît rien à la CREATE SPATIAL INDEXsyntaxe. Vous devrez installer postgis et utiliser le INDEXTYPEmot - clé pour créer des index spatiaux. Enfin, assurez-vous de gérer les schémas de manière appropriée.

Longue histoire courte:

  1. Générer des scripts et des données en utilisant la méthode d'Aaron Bertrand (je m'en tiendrai probablement au niveau de la table)
  2. Prenez note de l'index DDL (s'il est toujours valide), mais ne l'incluez pas
  3. Créer des index sur postgres une fois la structure et les données en place
swasheck
la source
3
Je ne pense pas que vous ayez besoin de configurer SQL Server pour parler à Postgres. Je suis sûr qu'une fois SQL Server installé, vous pouvez extraire les données dans une variété de formats que Postgres comprendra.
Aaron Bertrand
Mes excuses. Je voulais dire que vous auriez besoin de configurer Postgres pour accepter les connexions externes (SQL Server dans ce cas)
swasheck
Ne vous excusez pas. :-) Je clarifiais juste que vous n'avez pas besoin que SQL Server parle directement à Postgres ou vice versa ..
Aaron Bertrand