Backup/Restore mit BLOBs

Guten Abend,

ich habe große Probleme, ein mit pg_dump erzeugtes Backup zu=20
rekonstruieren, so dass auch die BLOBs enthalten sind. Die Tabelle wird=20
problemlos rekonstruiert, auch in den "BLOB"-Spalten steht noch der=20
OID-Verweis (das Restore wird mit Exitcode 0 fehlerfrei beendet). Sobald=20
ich jedoch die Daten extrahieren will, erscheint die Meldung, dass das=20
"large object with ... does not exist".
Ich habe schon viele Tipps aus Google und PostgreSQL-Archiven=20
ausprobiert (auch den pg_dump habe ich mit den verschiedenen=20
Kombinationen von Parametern ausprobiert), allerdings ohne Erfolg. Kann=20
es an der Datenbankgröße liegen? Ich habe auch versucht, erst nur das=
=20
Schema zu rekonstruieren und anschließend die Daten. Die Tabelle hat=20
3.2Mio Datensätze, die BLOBs sind nur wenige KB groß (das=20
PostgreSQL-Datenverzeichnis ist 6,9 GB groß, der Dump liegt bei 2,1GB).=
=20
Im Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large=20
objects" auslagern würde.
Ich verwende PostgreSQL 8.1 auf Windows.
Kennt jemand eine zuverlässige Methode, wie man Tabellen mit BLOBs=20
dumpen und wieder einlesen kann?

Vielen Dank im Voraus für jeden Hinweis,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: Backup/Restore mit BLOBs

am 11.06.2006, um 23:31:14 +0200 mailte Ulrich Cech folgendes:
> Guten Abend,
>=20
> ich habe große Probleme, ein mit pg_dump erzeugtes Backup zu=20
> rekonstruieren, so dass auch die BLOBs enthalten sind. Die Tabelle wird=
=20

Vorweg: ich hab mit BLOB's in der DB keine Erfahrungen.


> Parametern ausprobiert), allerdings ohne Erfolg. Kann es an der=20
> Datenbankgröße liegen?=20

eher nicht.


> rekonstruieren und anschließend die Daten. Die Tabelle hat 3.2Mio=20
> Datensätze, die BLOBs sind nur wenige KB groß (das=20
> PostgreSQL-Datenverzeichnis ist 6,9 GB groß, der Dump liegt bei 2,1GB=
). Im=20

Das würde mich massiv stutzig machen. Entweder hast Du sehr viel Platz
mit toten Tupels belegt oder durch viele Indexe etc., aber ich vermute
mal eher:



> Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large=20
> objects" auslagern würde.

Zum Schluß? Im Dump sollte als letzte Zeilen stehen:

--
-- PostgreSQL database dump complete
--

Prüfe, ob das bei Dir der Fall ist. Ansonsten ist der Dump
unvollständig. Ich vermute mal wild, daß PG Deine BLOBS in einer
TOAST-Table auslagert und diese nicht mit gesichert ist. Warum auch
immer, vielleicht eine 2 GByte-Beschränkung des Filesystems?



> Ich verwende PostgreSQL 8.1 auf Windows.

*Seufz*. Aber ich soll ja kein Windoze-Bashing mehr machen...


Andreas
--=20
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
===3D Schollglas Unternehmensgruppe ===

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Backup/Restore mit BLOBs

Hi

Ich hab eine DB mit BLOBS mit

pg_dump -b -C -Ft -f dbname.tar

in ein Archiv geschrieben und mit

pg_restore -v -C -d template1 dbname.tar

auf einem anderen Rechner wieder rekonstruiert. Ohne Problem.
Allerdings war das eine PG 7.x und ein Linux-Rechner, unter win habe
ich es noch nie probiert. Die Blobs kamen als .dat-Dateien mit.

Gruesse
Conni
--
http://pgsql.info | http://postgresql.de | http://pgfakt.de
Telefon: 07127 80 961

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Backup/Restore mit BLOBs

Hallo Cornelia,

ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB=20
immer die folgende Fehlermeldung:
pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen: N=
o=20
such file or directory

Ich habe langsam das Gefühl, dass ein Dump unter Windows bei größer=
en=20
Datenbanken nicht korrekt funktioniert, denn ich konnte eine kleine=20
Datenbank mit zwei BLOBs zumindest im Custom-Format problemlos dumpen=20
und rekonstruieren.

Trotzdem vielen Dank,
Ulrich

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Backup/Restore mit BLOBs

am 16.06.2006, um 8:26:26 +0200 mailte Ulrich Cech folgendes:
> Hallo Cornelia,
>=20
> ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB im=
mer=20
> die folgende Fehlermeldung:
> pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen:=
No=20
> such file or directory

Wilder Schuß ins blaue: keine Umgebungsvariable TEMP oder TMP, kein
Verzeichnis C:\temp oder sowas in der Richtung.

>=20
> Ich habe langsam das Gefühl, dass ein Dump unter Windows bei größ=
eren=20
> Datenbanken nicht korrekt funktioniert, denn ich konnte eine kleine=20

Ich hab schon seit 10 Jahren das Gefühl, daß Windows zum arbeiten vö=
llig
ungeeignet ist...



Andreas
--=20
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
===3D Schollglas Unternehmensgruppe ===

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Backup/Restore mit BLOBs

Hallo Andreas,


>>Parametern ausprobiert), allerdings ohne Erfolg. Kann es an der=20
>>Datenbankgröße liegen?=20
>> =20
>>
>
>eher nicht.
> =20
>
Merkwürdigerweise hat ein Dump und Restore mit einer kleinen Test-DB=20
inkl. BLOBs problemlos funktioniert...


>>Protokoll von pg_dump steht allerdings explizit, dass er jetzt "large=20
>>objects" auslagern würde.
>> =20
>>
>
>Zum Schluß? Im Dump sollte als letzte Zeilen stehen:
>
>--
>-- PostgreSQL database dump complete
>--
> =20
>
Ich leite die Ausgabe von pg_dump in eine Datei, als letzter Eintrag=20
steht dort "sichere Kommentare für large objects". Dies steht ebenfalls=
=20
als letzter Eintrag in meiner kleinen TestDB, mit der ein Dump/Restore=20
einwandfrei funtioniert.

Ich verwende jetzt folgenden dump-Befehl, der auch erfolgreich durchläu=
ft:
pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -b -D -v -f=20


Allerdings erhalte ich beim Restore die Fehlermeldung:
pg_restore.exe -i -h localhost -p 5432 -U postgres -d -a=20
--disable-triggers -v

....
pg_restore: restoring large object data
pg_restore: [archiver] could not write to large object (result:=20
4294967295, expected: 797)
pg_restore: *** aborted because of error
Prozess beendet mit Exitcode 1.


Zumindest sieht es so aus, als wären die BLOBs im Dump enthalten (das=20
suggeriert die Meldung).
Ich habe auch mal ein FULL VACUUM laufen lassen, was keinen Unterschied=20
gebracht hat.


>>Ich verwende PostgreSQL 8.1 auf Windows.
>> =20
>>
>
>*Seufz*. Aber ich soll ja kein Windoze-Bashing mehr machen...
>
:-)) Ich hatte noch überlegt zu erwähnen, bitte jegliche Kommentare=20
dahingehend zu vermeiden, da mir die Linux-Umgebung auch lieber wäre ;-=
))

Vielleicht liegt es tatsächlich daran, dass pg_dump unter Windows und=20
größeren Datenbanken nicht zurecht kommt.

Trotzdem vielen Dank.
Ulrich



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Backup/Restore mit BLOBs

am 16.06.2006, um 9:02:44 +0200 mailte Ulrich Cech folgendes:
> >Zum Schluß? Im Dump sollte als letzte Zeilen stehen:
> >--
> >-- PostgreSQL database dump complete
> >--
> >=20
> Ich leite die Ausgabe von pg_dump in eine Datei, als letzter Eintrag st=
eht=20
> dort "sichere Kommentare für large objects". Dies steht ebenfalls als=
=20
> letzter Eintrag in meiner kleinen TestDB, mit der ein Dump/Restore=20
> einwandfrei funtioniert.

Mmh. Ich hab mit BLOB's noch nix gemacht.


>=20
> Ich verwende jetzt folgenden dump-Befehl, der auch erfolgreich durchlä=
uft:
> pg_dump.exe -i -h localhost -p 5432 -U postgres -F c -b -D -v -f=20
>
>=20
> Allerdings erhalte ich beim Restore die Fehlermeldung:
> pg_restore.exe -i -h localhost -p 5432 -U postgres -d -a=20
> --disable-triggers -v
>=20
> ...
> pg_restore: restoring large object data
> pg_restore: [archiver] could not write to large object (result: 4294967=
295,=20
> expected: 797)
> pg_restore: *** aborted because of error
> Prozess beendet mit Exitcode 1.

Kann es sein, daß Du damit ein Problem hast:

pg_dump has a few limitations:


Members of tar archives are limited to a size less than 8 GB. (This=
is an inher-
ent limitation of the tar file format.) Therefore this format cannot =
be used if
the textual representation of any one table exceeds that size. The to=
tal size of a
tar archive and any of the other output formats is not limited, excep=
t possibly by
the operating system.


Aber eigentlich eher nein, weil Du verwendest ja -Fc und das ist kein tar=
..

Die Meldung 'could not write' könnte irgendwie auf Probleme mit
Filesystem, Rechten, Dateigröße oder sowas hindeuten. Ich weiß es n=
icht.


Kannst Du nicht mal ein Linux-System testweise hochziehen und dort den
Dump reinziehen?

Andreas
--=20
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
===3D Schollglas Unternehmensgruppe ===

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: Backup/Restore mit BLOBs

Hallo,

>>ich habe die tar-Variante getestet, leider bekomme ich bei ca. 800MB im=
mer=20
>>die folgende Fehlermeldung:
>>pg_dump: [Tar-Achiverer] konnte keine temporären Dateinamen erzeugen:=
No=20
>>such file or directory
>> =20
>>
>
>Wilder Schuß ins blaue: keine Umgebungsvariable TEMP oder TMP, kein
>Verzeichnis C:\temp oder sowas in der Richtung.
> =20
>
Gute Idee! Ich habe gerade nachgeschaut, ist leider alles vorhanden=20
(aber es könnte natürlich ein Berechtigungsproblem sein, dass der Use=
r=20
keine Schreibrechte auf das TMP-Verzeichnis hat...), dass werde ich mal=20
prüfen....
Das war es leider auch nicht...

>Ich hab schon seit 10 Jahren das Gefühl, daß Windows zum arbeiten vö=
llig
>ungeeignet ist...
>
> =20
>
Ich befürchte, mir wird unter Windows nichts andere übrig bleiben als=
=20
das komplette "data"-Verzeichnis zu sichern...

Danke und Gruß,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Backup/Restore mit BLOBs

Hallo,

>Mmh. Ich hab mit BLOB's noch nix gemacht.
>
> =20
>
Ist doch kein Problem, bin ja über jeden Hinweis/Grashalm :-) etc.=20
dankbar...

> Die Meldung 'could not write' könnte irgendwie auf Probleme mit
>
>Filesystem, Rechten, Dateigröße oder sowas hindeuten. Ich weiß es =
nicht.
>
>
>Kannst Du nicht mal ein Linux-System testweise hochziehen und dort den
>Dump reinziehen?
>
> =20
>
Ja, das werde ich demnächst mal versuchen, obwohl das dann schwierig=20
wird, einen Linux-Server in einer reinen Windows-Serverlandschaft=20
durchzusetzen ;-))... aber vielleicht wäre das mal ein erster Einstieg.=
...

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Backup/Restore mit BLOBs

Am Freitag, 16. Juni 2006 09:02 schrieb Ulrich Cech:
> pg_restore: restoring large object data
> pg_restore: [archiver] could not write to large object (result:
> 4294967295, expected: 797)
> pg_restore: *** aborted because of error

pg_dump ist immer sehr geheimnisvoll über den eigentlichen Grund für =
Fehler.=20
Das pg_dump in 8.2 ist da besser, also bei Bedarf vielleicht das mal=20
probieren.

--=20
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Backup/Restore mit BLOBs

Hallo,

>pg_dump ist immer sehr geheimnisvoll über den eigentlichen Grund für=
Fehler.=20
>Das pg_dump in 8.2 ist da besser, also bei Bedarf vielleicht das mal=20
>probieren.
>
> =20
>
ich glaube langsam immer mehr, dass es tatsächlich an der Dateigröß=
e=20
unter Windows liegt. Bisher sind alle Versuche, einen Dump zu erzeugen=20
und wieder einzulesen, fehlgeschlagen, zumindest mit der 7GB DB (eine=20
kleine Testdatenbank hat funktioniert).
Seit kurzem (der Dump hat mittlerweile eine Größe von etwas über 2G=
B)=20
erscheint jetzt sogar beim pg_dump-Aufruf folgende Meldung:
....
pg_dump: sicherer Large Objects
pg_dump: [Custom-Archivierer] Warnung: erwartete Dateiposition stimmt=20
nicht mit ftell überein -- benutze ftell
pg_dump: sichere Kommentare für Large Objects

Dann muss ich wohl mal auf die Version 8.2 warten und bis dahin=20
versuchen, zumindest einmal die Woche den DB-Server herunterzufahren und=20
das komplette "data"-Verzeichnis sichern, so dass es wenigstens ein=20
bißchen "Backup" gibt ;-)...

Danke und Gruß,
Ulrich


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Backup/Restore mit BLOBs

Hallo,

als kurzer Zwischenstand folgende Situation:
Ich habe am Wochenende auf 8.1.4-1 upgedatet. Der Fehler beim pg_dump=20
(...ftell...) erscheint immer noch, auch beim pg_restore erscheint eine=20
Fehlermeldung (..."invalid argument..."; leider habe ich verpasst, die=20
Ausgabe komplett zu notieren). Anschließend bricht der Restore-Vorgang=20
ab, es sieht aber so aus, als passiere dies beim Rekonstruieren der=20
Kommentare zu den BLOBs (wo faktisch nichts zu rekonstruieren ist).

Zumindest, und das ist die positive Entwicklung, sind die BLOBs=20
vorhanden und können wieder extrahiert werden, so dass mit dem Dump=20
jetzt tatsächlich eine Sicherung der Daten vorliegt.

Ich bin schon sehr auf die nächste Version gespannt, vielleicht=20
verschwinden dann die restlichen Fehlermeldungen auch noch.

Nochmals vielen Dank für alle Hilfestellungen.

Ulrich


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Backup/Restore mit BLOBs

Ulrich Cech wrote:
> Hallo,
>=20
> als kurzer Zwischenstand folgende Situation:
> Ich habe am Wochenende auf 8.1.4-1 upgedatet. Der Fehler beim pg_dump
> (...ftell...) erscheint immer noch, auch beim pg_restore erscheint eine
> Fehlermeldung (..."invalid argument..."; leider habe ich verpasst, die
> Ausgabe komplett zu notieren). Anschließend bricht der Restore-Vorgan=
g
> ab, es sieht aber so aus, als passiere dies beim Rekonstruieren der
> Kommentare zu den BLOBs (wo faktisch nichts zu rekonstruieren ist).
>=20
> Zumindest, und das ist die positive Entwicklung, sind die BLOBs
> vorhanden und können wieder extrahiert werden, so dass mit dem Dump
> jetzt tatsächlich eine Sicherung der Daten vorliegt.
>=20
> Ich bin schon sehr auf die nächste Version gespannt, vielleicht
> verschwinden dann die restlichen Fehlermeldungen auch noch.

http://archives.postgresql.org/pgsql-committers/2006-05/msg0 0284.php

ist wohl das problem mit den COMMENTS der BLOBS - und wird in 8.1.5
behoben sein ...


Stefan

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Backup/Restore mit BLOBs

Hallo Stefan,

anbei endlich die komplette Ausgabe vom pg_restore mit einigen Fehlern=20
(u.a. bei den COMMENTS der BLOBs).
Was mir vor allem Sorgen macht sind die Fehlermeldungen bezüglich=20
Inhaltsverzeichniseintrag u.s.w. Ein "Extraktionstest" hat jedoch ein=20
BLOB problemlos erstellen können, d.h. die BLOBs scheinen jetzt wirklic=
h=20
rekonstruiert worden zu sein.

************************************************************ *************=
*******
pg_restore.exe -i -h localhost -p 5432 -U postgres -d archive
--disable-triggers -v "c:\_myplace\a4a.backup"
pg_restore: verbinde mit der Datenbank zur Wiederherstellung
pg_restore: [Archivierer (DB)] Fehler in Phase INITIALIZING:
pg_restore: [Archivierer (DB)] could not execute query: ERROR: invalid b=
yte
sequence for encoding "UTF8": 0xe46973
Command was: --
-- PostgreSQL database dump
--

-- Started on 2006-07-03 01:00:00 Westeuropäische Normalzeit

SET client_encoding =3D 'UTF8';
pg_restore: erstelle SCHEMA public
pg_restore: erstelle COMMENT SCHEMA public
pg_restore: erstelle PROCEDURAL LANGUAGE plpgsql
pg_restore: [Archivierer (DB)] Fehler in Phase PROCESSING TOC:
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 253; 2=
612
16386 PROCEDURAL LANGUAGE plpgsql=20
pg_restore: [Archivierer (DB)] could not execute query: ERROR: language
"plpgsql" already exists
Command was: CREATE PROCEDURAL LANGUAGE plpgsql;
pg_restore: erstelle DOMAIN lo
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 207; 1=
247
16403 DOMAIN lo postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: type "lo"
already exists
Command was: CREATE DOMAIN lo AS oid;
pg_restore: erstelle FUNCTION autoinc()
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 15; 12=
55
16406 FUNCTION autoinc() postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"autoinc" already exists with same argument types
Command was: CREATE FUNCTION autoinc() RETURNS "trigger"
AS '$libdir/autoinc', 'autoinc'
LANGUAGE c;
pg_restore: erstelle FUNCTION lo_manage()
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 14; 12=
55
16405 FUNCTION lo_manage() postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"lo_manage" already exists with same argument types
Command was: CREATE FUNCTION lo_manage() RETURNS "trigger"
AS '$libdir/lo', 'lo_manage'
LANGUAGE c;
pg_restore: erstelle FUNCTION lo_oid(lo)
pg_restore: [Archivierer (DB)] Fehler in Inhaltsverzeichniseintrag 13; 12=
55
16404 FUNCTION lo_oid(lo) postgres
pg_restore: [Archivierer (DB)] could not execute query: ERROR: function
"lo_oid" already exists with same argument types
Command was: CREATE FUNCTION lo_oid(lo) RETURNS oid
AS $_$SELECT $1::pg_catalog.oid$_$
LANGUAGE sql IMMUTABLE STRICT;
pg_restore: erstelle TABLE archivemodel
pg_restore: Wiederherstellung der Daten von Tabelle
=BBarchivemodel=AB
pg_restore: Wiederherstellung der Large-Object-Daten
pg_restore: 3903641 Large Objects wiederhergestellt
pg_restore: Wiederherstellung der Daten von Tabelle =BBBLOB COMMENTS=AB
pg_restore: [Custom-Archivierer] Fehler beim Suchen in Datei: Invalid
argument
pg_restore: *** abgebrochen wegen Fehler

Prozess beendet mit Exitcode 1.
************************************************************ *************=
*******


Danke und Gruß,
Ulrich




Stefan Kaltenbrunner wrote:

> http://archives.postgresql.org/pgsql-committers/2006-05/msg0 0284.php
>
>ist wohl das problem mit den COMMENTS der BLOBS - und wird in 8.1.5
>behoben sein ...
>
>
>Stefan
> =20
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings