Probleme mit Umlauten in dump/restore

Hallo,

habe eine 200GB-Datenbank mit zwei Instanzen unter Windows in Version 8.0.3 welche mit SQL_ASCII codiert sind. Diese möchte ich jetzt in eine 8.3er-Datenbank mit UTF8 restoren. Jedoch scheint es Probleme mit dem Zeichensatz zu geben.
Die Datenbank habe ich mit der “pg_dumpall -E …” erstellt - muss ich die Datei vor dem restore noch in UTF8 umwandeln? Wie kann ich diese große Datei bearbeiten?!

Und bei der Wiederherstellung zeigt er Probleme mit einer Tabelle an, in der es Verletzungen des Domaintypes geben sollte - warum gibt es da Probleme? Das Problem sollte dann doch auch in der 8.0.3er Datenbank bestehen?

Danke und Ciao, PaulchenPlump

Wie kommt es zu diesem Schein?

Die Datenbank habe ich mit der “pg_dumpall -E …” erstellt - muss ich die Datei vor dem restore noch in UTF8 umwandeln? Wie kann ich diese große Datei bearbeiten?!

Nein. Mit normalen Texttools. Was willst Du denn bearbeiten?

Und bei der Wiederherstellung zeigt er Probleme mit einer Tabelle an, in der es Verletzungen des Domaintypes geben sollte - warum gibt es da Probleme? Das Problem sollte dann doch auch in der 8.0.3er Datenbank bestehen?

Danke und Ciao, PaulchenPlump

Nein, nicht zwingend. Viel mehr kann man bei Deiner überaus exakten und detailreichen Fehlerschreibung nicht erraten.

Andreas

Hallo Andreas,

vielen Dank für den indirekten Hinweis auf eine Suchmaschine - mehr konnte ich der Antwort leider nicht entnehmen…

Habe es mittlerweile mit folgendem Dreisatz hinbekommen:

  • pg_dump -f your_db.dmp your_db
  • iconv -f ISO8859-1 -t UTF-8 your_db.dmp > utf.dmp
  • psql your_utf_db < utf.dmp
    Ich bin davon ausgegangen, dass psql die Konvertierung automatisch vornimmt. :frowning:


OK, die hatte ich schon gelöscht und habe nun einen neuen Import angeworfen, mit dem gleichen Resultat:

ERROR:  domain domName does not allow null values
CONTEXT:  COPY tbl_TabellenName, line 3, column splMitDomName: null input
STATEMENT:  COPY tbl_TabellenName (splMitDomName, splWeitereSpalten) FROM stdin;

Und hier die Definition des Domaintypes:
CREATE DOMAIN domName AS integer NOT NULL;
Und der Tabelle
CREATE TABLE tbl_TabellenName (splMitDomName domName, splWeitereSpalten domWeitereSpalten) WITH (OIDS=FALSE);
Wie kann das kommen, die Daten sollten doch in der Ursprungsdatenbank gar nicht möglich sein?

Ciao PaulchenPlump

Es ist, auch in Version 8.3, nicht in der Lage, Gedanken zu erraten. Bis das mal implementiert ist, kann man sich aber mit dem pg_dump - Schalter -E behelfen.


Wie kann das kommen, die Daten sollten doch in der Ursprungsdatenbank gar nicht möglich sein?

Ciao PaulchenPlump

Ja, das ist interessant. Gibt es in der 8.0 - DB in der Tat Datensätze, die gegen den Constraint verstoßen?

Falls Du das an einem kurzen Beispiel (create table, create constraint, …) nachvollziehbar demonstrieren kannst, wäre das ein Fall für die Hackers-Mailingliste.

Andreas

Hallo Andreas,

Den brauch ich doch noch nicht?! Habe ja nur SQL_ASCII-Daten und das Clientencoding lautet ja auch so…

Ich bin selbst überrascht, aber JA die gibt es! Ich habe das Problem eingrenzen und auch mit der neuen PG 8.3 nachvollziehen können.
Hier das Beispielscript:

CREATE DOMAIN domname AS integer NOT NULL;

CREATE TABLE __p (spldritte integer NOT NULL) WITHOUT OIDS;
INSERT INTO __p (spldritte) VALUES (10);
INSERT INTO __p (spldritte) VALUES (20);
INSERT INTO __p (spldritte) VALUES (30);
INSERT INTO __p (spldritte) VALUES (40);

CREATE TABLE __j (splmitdomname domname, spldritte integer) WITHOUT OIDS;
INSERT INTO __j (splmitdomname, spldritte) VALUES (1, 10);
INSERT INTO __j (splmitdomname, spldritte) VALUES (2, 20);
INSERT INTO __j (splmitdomname, spldritte) VALUES (3, 30);

CREATE TABLE tbl_tabellenname (splmitdomname domname, splweiterespalten integer) WITHOUT OIDS;

Dies legt erst einmal die Strukturen und Beispieldaten an.
Folgendes Insertstatement müsste allerdings einen Fehler produzieren, tut es aber nicht:

INSERT INTO tbl_TabellenName (SELECT  __j.splmitdomname, __p.spldritte FROM __p LEFT JOIN __j USING(spldritte))

Das Problem hängt offenbar mit dem Join zusammen - inner join oder direkte Inserts produzieren sofort einen Fehler.
Jetzt bin ich aber mal gespannt… :wink:


PaulchenPlump