pg_restore scheinbar erfolgreich, aber DB leer

Hallo zusammen,

ich habe einen DUMP erhalten, den ich in meine lokale Postgres-DB einspielen möchte.
Ich habe die Version 8.4.17 unter Windows 7 (32.Bit).

Versuche ich das File über die Schnittstelle von PG_Admin einzuspielen, so werden alle Tabellen angelegt und auch größtenteils mit Daten gefüllt, aber bei einem BLOB-Objekt bricht der Import mit Fehlermeldung ab.
Auf Rückfrage beim Dienstleister habe ich erfahren, dass dieser den DUMP immer per pg_restore einspielt.

Das habe ich dann auch versucht und hier läuft auch (wesentlich länger als im pg_admin) einiges an Anweisungen und Daten über die Commandozeilen-Konsole und anschließend erhalte ich auch die Meldung, dass der DUMP erfolgreich eingespielt sei, aber in der DB selbst ist nichts zu finden. Habe das auch mit genau dem pg_restore Optionen probiert, die der Dienstleister erfolgreich einsetzt, aber es bleibt bei dem Verhalten.

Hat hier jemand eine Idee?
Die Anweisung lautet:
pg_restore --create -d postgres --username=postgres

Danke für euere Hilfe.

Mike :confused:

Kommt drauf an, wie der Dump erstellt ist. Enthält dieser keine Anweisungen zum Erstellen einer DB, so wird alles in der postgres-db landen, Du scheinst aber eine dedizierte DB zu wollen.
Schau also in postgres nach, ob da Deine Daten verbuddelt sind. Falls ja: erstelle die Ziel-DB und geb diese nach dem -d an.

Was genau meinst du mit in postgres nachsehen, ob die Daten dort verbuddelt sind?
Wenn ich in die Datenbank “postgres” schaue, sehe ich nur das Schema public und dieses enthölt 0 Tabellen.
Auch die Kataloge information_schema und pg_catalog enthalten keine der scheinbar erstellten Tabellen.

Die Kommandozeilenausgabe endet nach einigen ALTER TABLE … ADD CONSTRAINT Anweisungen mit folgendem Output:

--
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--

REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;


--
-- PostgreSQL database dump complete
--

Bin echt ein wenig ratlos.

Dann ist wohl Plan B eingetreten: der Dump enthält eine CREATE DATABASE - Anweisung, und diese wird erstellt und die Daten landen DORT.

Es ist aber keine 2. Datenbank angelegt worden.
Ich sehe im pgAdmin (auch nach Refresh) nur 1 Datenbank (postgres), mit 1 Schema (public) und keiner Tabelle.

Vielleicht hat dein Benutzer nicht die Rechte zum anzeigen… Was steht im Dump? Steht da ein “CREATE DATABASE”?

Nein, sehe ich nicht.

Wenn ich das Dump-File mittels

pg_restore -l <dumpfile>

aufrufe sehe ich eigentlich nur Ausgaben wie:

; Archive created at Sun May 05 22:30:13 2013
;     dbname: sp-applikation
;     TOC Entries: 510
;     Compression: -1
;     Dump Version: 1.11-0
;     Format: CUSTOM
;     Integer: 4 bytes
;     Offset: 8 bytes
;     Dumped from database version: 8.4.1
;     Dumped by pg_dump version: 8.4.1
;
;
; Selected TOC Entries:
;
6; 2615 2200 SCHEMA - public postgres
2584; 0 0 COMMENT - SCHEMA public postgres
2585; 0 0 ACL - public postgres
508; 2612 16386 PROCEDURAL LANGUAGE - plpgsql postgres
1695; 1259 5427809 TABLE public errorviewnullablefloat proactive
1696; 1259 5427812 SEQUENCE public hibernate_sequence proactive
2586; 0 0 SEQUENCE SET public hibernate_sequence proactive
1697; 1259 5427814 TABLE public jbpm_action proactive
1698; 1259 5427820 TABLE public jbpm_bytearray proactive
1699; 1259 5427823 TABLE public jbpm_byteblock proactive
1700; 1259 5427829 TABLE public jbpm_comment proactive
1701; 1259 5427835 TABLE public jbpm_decisionconditions proactive
1702; 1259 5427841 TABLE public jbpm_delegation proactive
1703; 1259 5427847 TABLE public jbpm_event proactive
1704; 1259 5427850 TABLE public jbpm_exceptionhandler proactive
1705; 1259 5427856 TABLE public jbpm_job proactive
1706; 1259 5427862 TABLE public jbpm_log proactive
1707; 1259 5427868 TABLE public jbpm_moduledefinition proactive
1708; 1259 5427874 TABLE public jbpm_moduleinstance proactive
1709; 1259 5427877 TABLE public jbpm_node proactive
1710; 1259 5427883 TABLE public jbpm_pooledactor proactive
1711; 1259 5427886 TABLE public jbpm_processdefinition proactive
1712; 1259 5427892 TABLE public jbpm_processinstance proactive
1713; 1259 5427895 TABLE public jbpm_runtimeaction proactive
1714; 1259 5427898 TABLE public jbpm_swimlane proactive

oder weiter unten

2573; 0 5428148 TABLE DATA public sp_vehicleseries proactive
2574; 0 5428154 TABLE DATA public sp_vehicleseries_description proactive
2575; 0 5428157 TABLE DATA public sp_vehicleseries_group proactive
2576; 0 5428160 TABLE DATA public sp_vehiclesoftwareversion proactive
2577; 0 5428166 TABLE DATA public sp_warning proactive
2578; 0 5428169 TABLE DATA public sp_warning_kdinfo proactive
2579; 0 0 BLOBS - BLOBS
2580; 0 0 BLOB COMMENTS - BLOB COMMENTS
2060; 2606 5428173 CONSTRAINT public errorviewnullablefloat_pkey proactive
2067; 2606 5428175 CONSTRAINT public jbpm_action_pkey proactive
2069; 2606 5428177 CONSTRAINT public jbpm_bytearray_pkey proactive
2071; 2606 5428179 CONSTRAINT public jbpm_byteblock_pkey proactive

Direkt im DUMP-File sehe ich allerdings auch mit dem HEX-Editor ein Create Database sp-applikation.
Wie kann ich denn den Inhalt des Dumps im Klartext nur anzeigen lassen?

Sollte einfach via pg_restore ohne Angabe einer DB alles nach stdout schreiben, dort einfangen.

Ok, danke.
Ich sehe dann lauter Create Table Statements, aber ein Create Database ist nicht dabei. Dieses sehe ich aber im File per HEX-Editor.
Angeblich soll man dieses File aber auch auf einer normalen Standardinstallation von Postgres einspielen können.