Datenbank-Kopie - Fehler beim Import

Fragen und Probleme rund um die Abfragespache SQL.

Datenbank-Kopie - Fehler beim Import

Beitragvon murphy » Fr 30. Apr 2010, 09:36

Hallo an alle,

ich habe ein kleines tcl-Skript geschrieben, welches den Datenbestand einer Produktivumgebung in die Testumgebung kopieren soll. Das ganze sieht so aus:

Code: Alles auswählen
;proc pg_copy:copy_db {} {
    puts ""
    puts "---------------------------------------------------------------------"
    puts "Action: copy_db invoked by option $::argv"
    puts "---------------------------------------------------------------------"
    puts ""
    puts "NOTICE: See $::PG_COPY(logfile) for further information."
    puts ""
    puts ""
    puts "Source: $::PG_COPY(sourcedb)"
    puts "Target: $::PG_COPY(targetdb)"
   
    puts ""
    puts "exporting TARGET (backup): $::PG_COPY(targetdb) --> [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(targetdb).sql]"
    if {[catch {
            eval exec pg_dump -Fp -c -h $::PG_COPY(dbhost) -p $::PG_COPY(dbport) -U $::PG_COPY(dbuser) $::PG_COPY(targetdb) > [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(targetdb).sql]
        } err]} {
        puts "ERROR: $err"
        puts "    program abort..."
        exit
    }
   
    puts ""
    puts "exporting SOURCE: $::PG_COPY(sourcedb) --> [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]"
    if {[catch {
            eval exec pg_dump -Fp -c -h $::PG_COPY(dbhost) -p $::PG_COPY(dbport) -U $::PG_COPY(dbuser) $::PG_COPY(sourcedb) > [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]
        } err]} {
        puts "ERROR: $err"
        puts "    program abort..."
        exit
    }
   
    puts ""
    puts "checking existing connections on $::PG_COPY(targetdb)"
    if {[catch {
            eval exec psql -d postgres -c \"SELECT client_addr, datname, current_query FROM pg_stat_activity WHERE datname = '$::PG_COPY(targetdb)' ORDER BY client_addr\"
        } err]} {
        puts "ERROR: $err"
        puts "    program abort..."
        exit
    }

    puts ""
    puts "waiting 10sec..."
    after 10000
   
    puts ""
    puts "importing: $::PG_COPY(targetdb) <-- [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]"
    if {[catch {
            eval exec psql --host $::PG_COPY(dbhost) --port $::PG_COPY(dbport) --username $::PG_COPY(dbuser) --dbname=$::PG_COPY(targetdb) -L $::PG_COPY(logfile)  -f [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]
        } err]} {
        puts "ERROR: $err"
        puts "    program abort..."
        exit
    }
   
    puts ""
    puts "deleting files (except the backup-file)"
    if {[catch {
            file delete [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]
        } err]} {
        puts "ERROR: $err"
        puts "    program abort..."
        exit
    }
   
    puts ""
    puts "done..."
}
Entscheidend sind natürlich nur die Stellen, in denen die psql-Kommandos stehen.

Im Prinzip geht das auch, wenn ich die Schritte einzeln laufen lassen. Lasse ich das ganze Skript laufen, erhalte ich folgenden Fehler:

Code: Alles auswählen
psql:/meditec/install/pg_copy_mediprod.sql:4407: ERROR:  cannot drop schema public because other objects depend on it
TIP:  Use DROP ... CASCADE to drop the dependent objects too.
psql:/meditec/install/pg_copy_mediprod.sql:4419: ERROR:  schema "public" already exists
Mir ist absolut unklar, was der DB hier nicht passt? Kann jemand helfen.

Vielen Dank! murphy
murphy
Erfahrener Benutzer
 
Beiträge: 186
Registriert: Mi 19. Aug 2009, 16:40

Beitragvon ads » Fr 30. Apr 2010, 10:03

Uargs, TCL ... wer tut sich denn so was an?
Es wäre schön, wenn du statt deinem Skript einfach die ausgeführten Befehle posten kannst. Dann muss sich nicht jeder erst mal in den Source einlesen.

Zu deiner Fehlermeldung: Was steht denn in Zeile 4407 und 4419 drin?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Beitragvon murphy » Fr 30. Apr 2010, 10:11

Die relevanten Stellen sind die hier:

Code: Alles auswählen
pg_dump -Fp -c -h $::PG_COPY(dbhost) -p $::PG_COPY(dbport) -U $::PG_COPY(dbuser) $::PG_COPY(targetdb) > [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(targetdb).sql]
pg_dump -Fp -c -h $::PG_COPY(dbhost) -p $::PG_COPY(dbport) -U $::PG_COPY(dbuser) $::PG_COPY(sourcedb) > [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]
psql -d postgres -c \"SELECT client_addr, datname, current_query FROM pg_stat_activity WHERE datname = '$::PG_COPY(targetdb)' ORDER BY client_addr\"
psql --host $::PG_COPY(dbhost) --port $::PG_COPY(dbport) --username $::PG_COPY(dbuser) --dbname=$::PG_COPY(targetdb) -L $::PG_COPY(logfile)  -f [file join $::env(MEDITEC) install pg_copy_$::PG_COPY(sourcedb).sql]


Die Zeilen aus dem Dump sind folgende:

Code: Alles auswählen
4407: DROP SCHEMA public;
4419: CREATE SCHEMA public;


Danke.
murphy
Erfahrener Benutzer
 
Beiträge: 186
Registriert: Mi 19. Aug 2009, 16:40

Beitragvon ads » Fr 30. Apr 2010, 10:18

Das sind nicht die ausgeführten Befehle, du hast lediglich die Zeilen aus dem Source kopiert. Wer z. B. nicht weiß, dass "join" Strings verknüpft, steht immer noch dumm da.

So, du fügst ein -c hinzu, um die Datenobjekte vorher zu löschen. Existiert denn in der Zieldatenbank ein Schema "public"?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Beitragvon murphy » Fr 30. Apr 2010, 10:31

Hab das mal noch ein bisschen aufgräumt; hast recht, nu isses einfacher für alle :-)

Code: Alles auswählen
pg_dump -Fp -c -h HOST -p PORT -U USER TARGETDB > pg_copy_TARGETDB.sql
pg_dump -Fp -c -h HOST -p PORT -U USER SOURCEDB > pg_copy_SOURCEDB.sql

psql --host HOST --port PORT --username USER --dbname=TARGETDB -L LOGFILE -f pg_copy_SOURCEDB.sql
Das -c soll ja alles vor dem Import wegräumen, also auch das Schema PUBLIC.

Code: Alles auswählen
mediprod=# \dn
        Liste der Schemas
        Name        | Eigentümer
--------------------+-------------
 information_schema | postgres
 pg_catalog         | postgres
 pg_toast           | postgres
 pg_toast_temp_1    | postgres
 public             | postgres
(5 Zeilen)

mediprod=#
Bitte nicht davon stören lassen, dass es die ProduktivDB, der Aufbau ist aber identisch.
murphy
Erfahrener Benutzer
 
Beiträge: 186
Registriert: Mi 19. Aug 2009, 16:40

Beitragvon ads » Fr 30. Apr 2010, 10:47

Gut. Und welche Objekte sind in der Source DB im Schema "public" noch vorhanden, die es in der Prod DB nicht gibt?

Das -c löscht alle Objekte weg, die es in der Prod DB gibt. Anscheinend gibt es aber noch mehr Objekte in der anderen Datenbank. Darum kann "public" nicht gelöscht werden.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Beitragvon murphy » Fr 30. Apr 2010, 10:53

Mensch klar!!! Du hast ja sowas von recht. Es wird in der ZielDB igendwas geben, was in der Quelle nicht da ist, und deswegen kann das Schema nicht gelöscht werden... Wie logisch...
Bevor ich da jetzt lange suche, ist es sicher besser die ZielDB per Skipt zu droppen und komplett neu anzulegen und dann das -c beim Export wegzulassen, oder???
murphy
Erfahrener Benutzer
 
Beiträge: 186
Registriert: Mi 19. Aug 2009, 16:40

Beitragvon ads » Fr 30. Apr 2010, 10:56

Keine Ahnung - kommt drauf an, ob du die Sachen in der Ziel DB verlieren willst oder nicht.
Musst du entscheiden.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Beitragvon murphy » Fr 30. Apr 2010, 10:59

Jepp, die ZielDB ist ein "Spielsystem", nicht so entscheidend. Kann alles weg.

ads, tausend Dank, das war der richtige Gedankenanstoß!

murphy
murphy
Erfahrener Benutzer
 
Beiträge: 186
Registriert: Mi 19. Aug 2009, 16:40

Beitragvon ads » Fr 30. Apr 2010, 11:00

Na dann das "-c" aus dem pg_dump Aufruf löschen.

akretschmer: schreibst ihm bitte eine Rechnung? ;-)
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support
ads
Erfahrener Benutzer
 
Beiträge: 4147
Registriert: Mi 8. Feb 2006, 11:58
Wohnort: MD

Nächste

Zurück zu SQL

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste

cron