Meine Produktivdatenbank läuft auf dem System:
PostgreSQL 8.4.4-2.3
Linux version 2.6.34-12-desktop
openSuSE 11.3 (x86_64)
Die Datenbank hat folgende Einstellungen
ENCODING = ‘UTF8’
LC_CTYPE = ‘de_DE.UTF-8’
Beim Einlesen der Daten bricht der Prozess nach der 150sten Tabelle ab:
[Custom-Archivierer] konnte Block-ID 4322 nicht im Archiv finden – möglicherweise wegen Wiederherstellung außer der Reihe, was wegen fehlender Datenoffsets im Archiv nicht möglich ist
Das Schema allein lässt sich problemlos anlegen.
Was könnte ich tun um die Daten einzulesen?
Gruß
Uli
P.S. Habe direkt vorher die Version 8.3 deinstalliert und 8.4 installiert
Das Datenverzeichnis hatte ich weggelöscht
Du könntest mit “–list” ein Inhaltsverzeichnis des Dumps erstellen und probieren, die Daten für jede Tabelle einzeln auszukommentieren (such nach “DATA”). Mit “–use-list” kannst du dann das geänderte Inhaltsverzeichnis zum Wiederherstellen nutzen.
Es sieht so aus, als ob dein Archiv kaputt ist. Da wirst du wohl Daten verlieren.
Für die Zukunft: Backups ohne einen Test sind wertlos.
Ich habe ein anderes Backup von letzter Nacht probiert. Genau der gleiche Fehler ab genau der gleichen Tabelle!
Die Datenbank läuft problemlos, an den Daten kann ich nichts ungewöhnliches erkennen.
Es ist nicht das erste mal, dass ich mit pg_dump / pg_restore die Daten wiederherstelle, aber das erste mal dass ich die Sicherung aus einem Linux System zum wiederherstellen auf einem Windows System benutze. Vielleicht Probleme mit der Zeichenkodierung?
Mein Versuch plain text mit psql einzulesen ist an der großen Datei (12GB) gescheitert, die ich nicht auf eine externe Festplatte kopieren konnte.
Habe jetzt handliche Dateien mit:
Ja, der select geht problemlos.
Ich überlege, ob das ein Fehler auf der Zielplatte sein könnte.
Habe aber noch keinen chkdsk gemacht.
Am Montag versuche ich einen restore auf einem anderen Rechner
Zuerst Windows, dann Linux.
Melde mich wieder
Kannst Du ausschließen, daß auf dem Transport zwischen den Systemen was schief ging? Das kann z.B. schon durch FTP passieren. Ist es vielleicht ein Dateigrößenproblem?
Du könntest mittels Prüfsummen das mal prüfen…
Das einlesen der Backupdatei auf einem Linux Rechner ist erwartungsgemäß auch gescheitert.
Ich habe jetzt von diesem Linux Rechner
(Suse Linux, gleiche Version wie Server mit Produktivdatenbank; PostgreSql Version 8.4.4) eine Sicherung ausgeführt:
Im folgenden habe ich die Rechner so benannt:
Linux Produktivserver mit IP …99 -> LProd 99
Linux Testmaschine mit IP …104 -> LTest 104
LProd 99 macht pg_dump von localhost
Kopieren das Backups auf LTest 104
Restore des Backups auf LTest 104 schlägt fehl (wie oben beschrieben)
LTest 104 macht pg_dump von LProd 99
Restore des Backups auf LTest 104 funktioniert
Und hier der vorgeschlagene Dump:
LProd 99 macht pg_dump von LTest 104
Kopieren das Backups auf LTest 104
Restore des Backups auf LTest 104 funktioniert
Bitte wie? Das hätte meines Erachtens eher schief gehen sollen.
Ob es eine gute Idee wäre ein funktionierendes Backup auf den Produktivserver zurückzuspielen?
Das sieht aus als hätte die Daten einen Knacks, obwohl die Datenverarbeitung reibungslos läuft.
ich denke ich habs.
Es gibt immer mehr Randbedingungen als darstellbar sind.
Meine Sicherung wird (nein wurde) von einem in Java selbst geschriebenen Timer ausgeführt. Das hat in der Windowswelt prima funktioniert, scheint in Linux aber schief zu gehen. Immer Nachts um 5 Uhr wurde mit
Process process = Runtime.getRuntime().exec("./script/dbDump.bash");
die Sicherung ausgeführt.
Als ich vorhin ein Drop auf eine View machen wollte hab ich gesehen dass über 1000 AccessShareLocks auf IDLE stehen. Das Beenden der Java Applikation hat sie alle freigegeben.
Warum durch die Locks die Sicherung unbrauchbar wird weiss ich nicht, ist wohl aber so.
Ein manuelles Aufrufen von dbDump.bash führt zu einer korrekten Sicherung.
Jetzt ists mir wieder wohler.
Falls jemand noch was zu dem exec Aufruf weiss wärs schön (bin leider neu in Linux),
ansonsten vielen Dank für die Antworten.
Hat mir viel weitergeholfen.
um einen Job periodisch durchführen zu lassen, empfiehlt sich auf UN*X-Rechnern der cron Befehl. Infos dazu findest du auf deinem Linux-Rechner in einer Shell mittels ‘man cron’. Alternativ hilft Google natürlich ich auch.
Ja, richtig. Unter Windows nennt sich das Task-Managner, den man normalerweise für solche Aufgaben nutzt. Zudem hat PgAdmin auch eine solche Funktion und nennt sich pgAgent. Downloaden muß man diese Tool nicht separat, nur wird wird diese Tool bei der Installation von PgAdmin nicht automatisch mit installiert. Leider kennen dieses Tool nicht viele, weil sie es einfach vermeiden, sich einmal die Doku anzuschauen.
wie groß sind denn die dumps?
wie sind die busbreiten der OS?
PostgreSQL 8.4.5-1
Windows XP Prof SP3
ENCODING = ‘UTF8’
LC_CTYPE = ‘German_Germany.1252’
nun kann es durchaus sein (wo ich mir net sicher bin), dass pg_dump large file support inne hat … aber vielleicht hat irgendein tool beim kopieren zwischendurch die haelfte unterschlagen