Doppelte im P-Key

Hallo Mädels und Jungs,

ich verwende die 8.1 von Etch Debian und will das auf eine 8.3 upgraden. Dazu habe ich einen Dump gemacht und diesen wieder in die neue Datenbank geladen. Dabei konnte der Primarykey (MyProductNr) wegen doppelten nicht erstellt werden. :frowning:

Eine Abfrage auf der alten Datenbank sagt auch das ist so:

abygale.de=# SELECT myproductnr FROM productkey GROUP BY myproductnr HAVING COUNT(myproductnr) > 1;
 myproductnr
-------------
    10793732
    16901513
    17213857
    18310773
(4 Zeilen)

Ein Beispiel:

abygale.de=# SELECT * from productkey where onixrecordreference = 'A4776948';
 myproductnr | onixrecordreference | onixmessagesender | onixsentdate | notificationtype |          modtime
-------------+---------------------+-------------------+--------------+------------------+----------------------------
    17213857 | A4776948            | Libri GmbH        | 20080514     | 05               | 2007-12-05 17:08:33.632821
    17213857 | A4776948            | Libri GmbH        | 20080514     | 03               | 2007-12-05 17:08:33.632821
(2 Zeilen)

Hab Ihr vielleicht eine Idee wie die da reingekommen sein könnten?
Oder wie ich das in Zukunft verhindern kann?

Danke und Grüße
Alexander

Bist Du sicher, daß da ein unique Index (wird bei einem PK automatisch erzeugt) drauflag? Meine Frage ist gleichzeitig Antwort auf Deine zweite Frage.

Andreas

Hallo akretschmer,

ja da bin ich mir sicher hab nachgeschaut. Es hätte ja dann beim Import in 8.3 auch keine Fehlermeldung gegeben wenn da keiner gewesen wäre und ich hätte das gar nicht bemerkt.

Grüße
Alexander

Läuft die alte DB noch?

Falls ja, wäre es interessant , das dort zu untersuchen, klingt nach Bugreport.

Also, dort ein \dt von der Tabelle und auch Dein “SELECT myproductnr FROM productkey GROUP BY myproductnr HAVING COUNT(myproductnr) > 1;” dort.

Andreas

Hab Ihr vielleicht eine Idee wie die da reingekommen sein könnten?
Oder wie ich das in Zukunft verhindern kann?

z.B. durch ein Restore auf eine nicht leere DB …

wenn ich ein normales backup in eine existierende DB wiederherstelle - dann geht das unbedingt schief -> vorhandene records sind doppelt (also die welche schon drin sind + die aus dem backup) - nichtmal fehlermeldungen gibt es - alle constraints und guten ratschlaege werden ignoriert :slight_smile:

Hallo,

die alte DB gibts noch aber die doppelten Sätze nicht mehr die hab ich entfernt und den Dump neu erstellt damit ich das in die neue DB importieren kann. Das heisst in den alten Sicherung muß es auch die doppelten Sätze noch geben müßte man gegebenfalls nochmal laden.

Der Having war in der alten Datenbank gemacht.

So sieht die Tabelle aus:

abygale.de=# \d productkey
                    Tabelle »public.productkey«
       Spalte        |             Typ             |   Attribute   
---------------------+-----------------------------+---------------
 myproductnr         | bigint                      | not null
 onixrecordreference | text                        | 
 onixmessagesender   | text                        | 
 onixsentdate        | text                        | 
 notificationtype    | text                        | 
 modtime             | timestamp without time zone | default now()
Indexe:
    »productkey_pkey« PRIMARY KEY, btree (myproductnr)
    »keynotificationtype« btree (notificationtype)
    »keyproductdelete« btree (onixrecordreference, onixmessagesender)
    »keyproductdelete1« btree (modtime, onixsentdate)

Das das beim Import keine Fehlermeldung gibt kann nicht stimmen. Genau dort wird ja der Prim-Key neu angelegt und verursacht dann einen Fehler. Ich habe es ja auch erst bemerkt als ich den Dump in die neue DB importiert habe. Als ich die nicht vorhandene Fehlermeldung lass :wink:

Grüße
Alexander

tjajaa … was heisst denn “importiert” … womit hast du die daten importiert …

ich spreche von einem restore - eines dumps … das NICHT als plain erzeugt wurde, sondern so ein “richtiges” binäres posrgres DB-backup ist.

Hm, pg_dump macht den Dump ist ein Textfile kein binäres. Importtiert mit psql.

Erzeugen:
nohup pg_dump -f abygale.de_dump abygale.de &

Wiederherstellen:
nohup psql -f abygale.de_dump abygale.de &

Was ist den dann ein falsches PostgreSql Backup?
Wie machst Du das?

Grüße
Alexander

Er meint ein Backup im “custom” Format.
Selbiges wird mit pg_restore zurückgespielt.

Aha, danke für die Info das hatte ich bisher noch nie benützt. Was wären davon die Vorteile?

Zumindest das es zu einem Fehler kommt wenn man zufällig vergisst die Datenbank zu löschen finde ich einen großen Nachteil.

Grüße
Alexander

Depends.
Man kann zum Beispiel bequem nur Teile des Backups zurückspielen.
Man kann auch das Backup vor dem Einspielen umsortieren.


Zumindest das es zu einem Fehler kommt wenn man zufällig vergisst die Datenbank zu löschen finde ich einen großen Nachteil.

Komm schon, das willst du nicht wirklich der Datenbank als Fehler anlasten, oder?

Das ist wohl eher ein Layer-8 - Problem.

Andreas

ein pg_restore, welches ohne zu mucken die integrität einer DB vernichtet kann man nur als fehlerhaft ansehen …

zumal im ergebnis nicht nur die integrität der daten hinueber ist - sondern die des ganzen gebildes einschliesslich modell … das muss man erstmal einem erklaeren koennen, wie in einer tabelle doppelte PKs sein koennen, wo doch ein unique-constraint drauf liegt …

es ist ja huebsch, dass ich auch “nur teile” wiederherstellen kann - ganz und garnicht huebsch ist, dass vorhandener inhalt einfach ueberhaupt nicht beruecksichtigt wird.

dabei soll doch oberste PG-direktive die TOTALE INTEGRITÄT sein :slight_smile:

Wer redet denn davon? Du siehst nicht existente Probleme.

Andreas

symbiont: du erzählst wieder mal totalen Schmarrn.

Beim Restore wird genau die Integrität der Daten sichergestellt die du wiederherstellst. Wenn du versuchst, Daten einzuspielen die fehlende Referenzen haben wirst du schnell feststellen dass das nicht funktioniert. Soviel zu dem Thema.

Wenn du die Integrität deiner Daten z. B. über einen Trigger und eine Funktion sicherstellst weil die Komplexibilität der Daten zu hoch für eine simple Referenz ist dann wirst du beim Wiederherstellen der Datenbank eine böse Überraschung erleben: pg_dump konnte die korrekte Reihenfolge der einzuspielenden Daten nicht feststellen (wie auch, die Semantik der Triggerfunktion ist unbekannt) und hat möglicherweise eine falsche Reihenfolge gewählt. Mittels pg_restore kannst du die Reihenfolge manuell korrigieren.

Und zu den bereits vorhandenen Daten: über deinen Spruch möchtest du noch mal nachdenken, bevor du dich das nächste Mal disqualifizierst.

probier es aus … du wirst staunen

table mit pk … und daten drin -> einmal backup … einmal restore in die selbe db … ohne schnulli

dann hast du daten die es garnicht geben duerfte

Dann hast du immer noch ein Layer-8 Problem: woher soll die Datenbank wissen was du da anstellen willst? Sie spielt - soweit technisch möglich - brav die Daten ein die du ihr vorsetzt.

Was genau du der Datenbank verfütterst dafür bist du selber verantwortlich.


So, nach diesem kleinen Ausflug in die graue Theorie des Backups, können wir jetzt wieder zum Thema zurückkommen?

Ja, probier es bitte selber aus. Danke.

test=# create database symbiont;
CREATE DATABASE
test=# \c symbiont
You are now connected to database "symbiont".
symbiont=# create table test (id int primary key);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE
symbiont=*# insert into test values (1);
INSERT 0 1
symbiont=*# commit;
COMMIT
symbiont=# \q
kretschmer@pegasus:~$ pg_dump -U webmaster symbiont > symbiont.sql
kretschmer@pegasus:~$ psql -U webmaster test -f symbiont.sql
SET
SET
SET
COMMENT
SET
SET
SET
psql:symbiont.sql:28: ERROR:  relation "test" already exists
kretschmer@pegasus:~$ psql -U webmaster symbiont -c "select * from test"
 id
----
  1
(1 row)

Und nun zeigst Du mir, wo hier was inkonsistent ist. Ich erwarte Deine Antwort hier im Forum.

Andreas

meinst du nicht auch, dass ein constraint ein constraint ein constraint ist? meinst du nicht auch, dass das mindeste was man von einer DB erwarten darf - ein fehler sein sollte - wenn der constraint verletzt wuerde? auch bei einem restore?

tja keine ahnung was bei dir anders ist …

ach ja … wir sprechen vom “custom” format …

freilich - bei einem script geht es schief