J'ai un fichier de vidage avec une extension .SQL
(en fait, il s'agit d'un fichier SQL en texte brut). Je veux le restaurer dans mes bases de données créées. J'utilise pgAdmin III , et lorsque j'utilise son "Assistant de restauration", le bouton "Restaurer" n'est pas mis en surbrillance. Au lieu de cela, il attend une extension de fichier .backup
.
J'ai essayé d'utiliser les commandes Shell pour restaurer le dump, mais cela ne fonctionnait toujours pas.
Je suis un débutant à cela. Si quelqu'un pouvait m'aider, je serais obligé.
J'ai utilisé la commande suivante pour le volet Shell SQL de PostGres tout en restant assis à la newTestDB.
newTestDB-# \i E:\db-rbl-restore-20120511_Dump-20120514.sql
Il a toujours donné la même erreur ("Permission Denied").
Après avoir élevé les permissions, cela ne fait que me montrer les tables par défaut de PostgreSQL:
List of tablespaces
Name | Owner | Location
-----------+----------+----------
pg_default | postgres |
pg_global | postgres |
(2 rows)
Je ne sais pas quoi faire pour importer/restaurer la base de données à partir d'un fichier SQL.
Vous n'avez pas mentionné la manière dont votre sauvegarde a été effectuée. La réponse générique est donc: Habituellement, à l'aide de l'outil psql
.
En fonction de ce que pg_dump
a été chargé de vider, le fichier SQL peut comporter différents jeux de commandes SQL . Par exemple, si vous demandez à pg_dump
de vider une base de données à l'aide de --clean
et --schema-only
, vous ne pouvez pas vous attendre à pouvoir base de données de ce vidage car il n'y aura pas de commande SQL pour COPYing (ou INSERTing si --inserts
est utilisé) les données réelles dans les tables. Un vidage comme celui-ci ne contiendra que des commandes SQL DDL et pourra recréer le schéma mais pas les données réelles.
Un vidage SQL typique est restauré avec psql
:
psql (connection options here) database < yourbackup.sql
ou bien d'une session psql
,
psql (connection options here) database
database=# \i /path/to/yourbackup.sql
Dans le cas de sauvegardes effectuées avec pg_dump -Fc
("format personnalisé"), qui n'est pas un fichier SQL simple mais un fichier compressé, vous devez utiliser l'outil pg_restore
.
Si vous travaillez sur un système de type Unix, essayez ceci:
man psql
man pg_dump
man pg_restore
sinon, jetez un œil à la documentation html . Bonne chance!
Le problème avec votre tentative de la ligne de commande psql
est la direction des barres obliques:
newTestDB-# /i E:\db-rbl-restore-20120511_Dump-20120514.sql # incorrect
newTestDB-# \i E:/db-rbl-restore-20120511_Dump-20120514.sql # correct
Pour être clair, les commandes psql
commencent par une barre oblique inverse, vous devriez donc avoir mis \i
à la place. Le résultat de votre faute de frappe est que psql
a tout ignoré jusqu'à la recherche du premier \
, suivi par db
et que \db
se trouve être la commande psql
pour lister les espaces table , d'où le résultat final Liste des espaces de table . Ce n'était pas une liste de "tables par défaut de PostgreSQL" comme vous l'avez dit.
De plus, il semble que psql
s'attend à ce que l'argument filepath
délimite les répertoires à l'aide de la barre oblique sans tenir compte du système d'exploitation (donc, cela serait contre-intuitif sous Windows).
Il est à noter que votre tentative "d'élévation des autorisations" n'a aucun lien avec le résultat de la commande que vous avez tenté d'exécuter. En outre, vous n'avez pas précisé la cause de l'erreur supposée "Permission Denied".
Enfin, l’extension du fichier de vidage n’a pas d’importance, vous n’avez même pas besoin d’une extension. En effet, pgAdmin
suggère une extension .backup
lors de la sélection d'un nom de fichier de sauvegarde, mais vous pouvez le créer comme vous le souhaitez, encore une fois, y compris ne pas avoir d'extension du tout. Le problème est que pgAdmin
semble n'autoriser que des sauvegardes de type "Restauration" de "Personnalisé ou tar" ou "Répertoire" (du moins c'est le cas dans la version MAC OS X de l'application), utilisez donc simplement la commande psql
\i
montré ci-dessus.
En utilisant pg_restore command vous pouvez restaurer la base de données postgres
Premier type de terminal ouvert
Sudo su postgres
Créer une nouvelle base de données
createdb [nom de la base de données] -O [propriétaire]
createdb test_db [-O openerp]
pg_restore -d [Nom de la base de données] [chemin du fichier de vidage]
pg_restore -d test_db /home/sagar/Download/sample_dbump
Attendez la fin de la restauration de la base de données.
N'oubliez pas que le fichier de vidage doit avoir les droits de lecture, d'écriture et d'exécution, vous pouvez donc appliquer la commande chmod
1.Ouvrez le terminal.
2.backup votre base de données avec la commande suivante
votre postgres bin - /opt/PostgreSQL/9.1/bin/
votre serveur de base de données source - 192.168.1.111
l'emplacement et le nom de votre fichier de sauvegarde - /home/dinesh/db/mydb.backup
votre nom de base de données source - mydatabase
/opt/PostgreSQL/9.1/bin/pg_dump --Host '192.168.1.111' --port 5432 --username "postgres" --no-password --format custom --blobs --file "/ home/dinesh/db /mydb.backup "" mydatabase "
3.restorez le fichier mydb.backup dans la destination.
votre serveur de destination - localhost
votre nom de base de données de destination - mydatabase
create database pour restaurer la sauvegarde.
/opt/PostgreSQL/9.1/bin/psql -h 'localhost' -p 5432 -U postgres -c "CREATE DATABASE mydatabase"
restaurer la sauvegarde.
/opt/PostgreSQL/9.1/bin/pg_restore --Host 'localhost' --port 5432 --username "postgres" --domname "mydatabase" --no-password - nettoyage "/ home/dinesh/db/mydb. sauvegarde "
En combinant les conseils de MartinP et de user664833, j'ai également pu le faire fonctionner. La mise en garde consiste à entrer psql à partir de l’interface graphique pgAdmin en choisissant Plugins ... La console PSQL définit les informations d’identité et le niveau d’autorisation pour la session psql. Vous devez donc disposer d’autorisations Admin ou CRUD sur la table et peut-être sachez à ce sujet). La commande alors dans la console psql prendrait la forme suivante:
postgres=# \i driveletter:/folder_path/backupfilename.backup
où postgres = # est l'invite psql, ne faisant pas partie de la commande.
Le fichier .backup comprendra les commandes utilisées pour créer la table. Vous pouvez donc également obtenir des commandes telles que "ALTER TABLE ..." dans le fichier, qui sont exécutées mais signalées comme des erreurs. Je suppose que vous pouvez toujours supprimer ces commandes avant d'exécuter la restauration, mais vous feriez mieux de les conserver, car elles ne provoqueront probablement pas l'échec de la restauration des données. Mais assurez-vous toujours que les données que vous souhaitez restaurer ont bien été récupérées. (Désolé si cela semble être un conseil condescendant pour qui que ce soit, mais c'est un oubli qui peut arriver à n'importe qui, peu importe le temps qu'ils passent dans ce domaine - un moment de distraction de la part d'un collègue, un appel téléphonique, etc., et il est facile de Je l'ai déjà fait moi-même en utilisant d'autres bases de données au début de ma carrière et je me suis demandé "Pourquoi ne vois-je aucune donnée de cette requête?" Réponse: les données n'ont jamais été restaurées et j'ai juste perdu 2 heures à essayer pour traquer les bugs possibles qui n'existaient pas.)
Je trouve que psql.exe est assez difficile en ce qui concerne la direction de la barre oblique, au moins sous Windows (ce qui est présenté ci-dessus).
Voici un exemple. Dans une fenêtre de commande:
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres
psql (9.2.4)
Type "help" for help.
postgres=# \i c:\temp\try1.sql
c:: Permission denied
postgres=# \i c:/temp/try1.sql
CREATE TABLE
postgres=#
Vous pouvez voir qu'il échoue lorsque j'utilise des barres obliques "normales" dans un appel \i
. Cependant, les styles de barre oblique deux fonctionnent si vous les transmettez en tant que paramètres d'entrée à psql.exe
, par exemple:
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:\TEMP\try1.sql
CREATE TABLE
C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:/TEMP/try1.sql
CREATE TABLE
C:\Program Files\PostgreSQL\9.2\bin>
Vous devrez peut-être définir des autorisations au niveau de la base de données permettant à votre propriétaire de schéma de restaurer le vidage.