Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Datenbank-Kopie - Fehler beim Import

  1. #1
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard Datenbank-Kopie - Fehler beim Import

    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:
    ;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:
    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

  2. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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

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

    PostgreSQL Service & Support

  3. #3
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    Die relevanten Stellen sind die hier:

    Code:
    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:
    4407: DROP SCHEMA public;
    4419: CREATE SCHEMA public;
    Danke.

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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

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

    PostgreSQL Service & Support

  5. #5
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

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

    Code:
    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:
    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.

  6. #6
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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

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

    PostgreSQL Service & Support

  7. #7
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    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???

  8. #8
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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

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

    PostgreSQL Service & Support

  9. #9
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

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

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

    murphy

  10. #10
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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

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

    PostgreSQL Service & Support

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Frage --schema-Parameter beim dump-Import falsch
    Von bolshi im Forum Migration
    Antworten: 3
    Letzter Beitrag: 12.04.2010, 15:32
  2. Fehler beim installieren
    Von Dantete im Forum Installation von PostgreSQL
    Antworten: 8
    Letzter Beitrag: 16.11.2008, 10:19
  3. SQL Datenbank-Import
    Von SimplyFred im Forum SQL
    Antworten: 4
    Letzter Beitrag: 27.11.2007, 11:28
  4. Datenbank vor einer Kopie schützen
    Von CenText im Forum Trigger und Funktionen
    Antworten: 10
    Letzter Beitrag: 30.07.2007, 11:10
  5. Problem beim Import
    Von Pegasus0211 im Forum Allgemeines
    Antworten: 3
    Letzter Beitrag: 17.11.2006, 08:24

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum