Problem mit Datenbankverzeichnis

Hallo zusammen,
ich habe eine Postgres 8.0 auf einem Windows Server im Einsatz und gestern festgestellt, dass ich ein Problem auf Dateiebene mit einem Verzeichnis hatte.
Das Verzeichnis wurde mir 11 GB groß abgezeigt, die Partition war aber nur 10 GB groß.
Wenn ich in das Verzeichnis c:\postgreSQL\data\pg_tblspc\17253 wechel, wird mir der Inhalt des übergeordneten Verzeichnisses angezeigt (c:\GrappaOnline\postgreSQL\data\pg_tblspc).
Ich kann dann rekursiv X mal in das Verzeichnis 17253 wechseln.

Daraufhin habe ich dann das komplette Verzeichnis 17253 verschoben, der Fehler im Dateisystem wurde daraufhin zwar korrigiert aber meine Postgres fährt nicht mehr hoch.

Fragen dazu:
Steht jedes Verzeichnis für ein Tablespace in der DB?
Kann ich nun die komplette Datenbank abschreiben oder irgendwie diesen einen Tablespace neu aufbauen?

Vielen Dank für eure Antworten
Thomas

das Backup von gestern :slight_smile: raussuchen

das Dateisystem zu reparieren (das ist naemlich futsch)

und die Datenbank neu herstellen

Wenn der Server nicht startet ist wahrscheinlich auch dessen konfig im A… (die ist i.d.R. auch im Datenverzeichis untergebracht)

Denn - wenn nur der Tablespace futsch waere - wuerde das den Server erstmal nicht jucken bis du dich mit der DB verbinden willst.

ich wuerde den Einfachen weg gehen und das bisserl Server neu installieren …

gruss

erstmal danke für deine antwort. ich habe gehofft das ich noch ein bisschen basteln könnte …

wie gut das meine letzte sicherung von anfang mai ist :wink:

übrigens bist du dir sicher, dass in tablespace verzeichnissen auch serverkonfigurationen untergebracht sind?

ich denke ich werde noch ne idee von mir ausprobieren und wenn das nicht klappt die postgres neu installieren und das backup vom mai einspielen

ich könnte ja alle verzeichnisse im tablespace verzeichnis rauskopieren und gucken ob der server dann läuft
wenn das geht das backup einspielen und danach die anderen, noch funktionierenden tablespaces reinkopieren

so müsste ich wenigstens einen großteil der daten gerettet bekommen

klingt das zu naiv? :slight_smile:

sicher kannst du da noch basteln -

vielleicht hast du ja noch irgendwo anders eine pg installation und kannst dort schauen wie das datenverzeichnis es aussehen muss - ich denke mal nicht, dass du eine exotische installation hast

stelle halt sicher, dass du auf nem funktionierenden dateisystem arbeitest - wer weiss, was da passiert ist … hoert sich nach paar stromausfaellen an :slight_smile: - oder die DB ist vollgelaufen und PG hat fehlermeldungen des Dateisystems ignoriert - machen andere DBMS auch - aus performancegruenden wird halt davon ausgegangen, dass immer genuegend platz ist

die konfig kann auch sonstwo liegen nur bei den meisten installationen wird sie dort untergebracht sein wo PG sie std. installiert - und dass ist im daten verzeichnis fuer die table-spaces … sind aber acuh nur text-dateien …



Das ist falsch.

Andreas

hmm … nagut …

Da können auch Rundungsfehler sein, und wahlweise 1000 oder 1024 als Kilo gelten, you know?

Wenn ich in das Verzeichnis c:\postgreSQL\data\pg_tblspc\17253 wechel, wird mir der Inhalt des übergeordneten Verzeichnisses angezeigt (c:\GrappaOnline\postgreSQL\data\pg_tblspc).
Ich kann dann rekursiv X mal in das Verzeichnis 17253 wechseln.



Daraufhin habe ich dann das komplette Verzeichnis 17253 verschoben,

Hoffentlich vorher PG beendet?

der Fehler im Dateisystem wurde daraufhin zwar korrigiert aber meine Postgres fährt nicht mehr hoch.

Fehlermeldung?

Fragen dazu:
Steht jedes Verzeichnis für ein Tablespace in der DB?

Nein.

Kann ich nun die komplette Datenbank abschreiben oder irgendwie diesen einen Tablespace neu aufbauen?

Vielen Dank für eure Antworten
Thomas

Wenn Du das nur verschoben hast, und PG nicht lief zu der Zeit, dann hast Du wohl noch Chancen.


Andreas

Jedes Verzeichnis unter pg_tblspc steht für einen Tablespace, nur solltest du untlichst vermeiden dort selbst Änderungen vorzunehmen. Dafür gibt es entsprechende SQL-Befehle. Wenn dein Dateisystem kaputt ist kann die Datenbank da jedoch auch nichts mehr retten - und beschwert sich zu Recht beim Starten das ihr was fehlt.

symbiont: bevor du weiter irgendwelche Behauptungen in den Raum stellst probier das doch vorher einfach mal aus. So schwer ist es doch wohl nicht eine volle Festplatte zu simulieren - oder?
Wenn du mehr mit Fakten und weniger mit Vermutungen arbeiten würdest wäre uns allen geholfen.

mein gott … heul doch nicht gleich wieder … hat AK doch inzwischen schon geklaert, dass es quatsch sein koennte … tztz

ich kann rundungsfehler ausschließen da meine angaben alle in byte waren und auf der selben partition noch 8gb an anderen daten liegen :wink:

nein habe ich nicht

2008-09-25 06:06:03 PANIK: konnte Relation 17253/17254/18983 nicht öffnen: No such file or directory

das ist exakt das verzeichnis das kaputt war

da es aber lief habe ich keine chancen mehr?

Nuja … alle Hoffnung stirbt bekanntlich zuletzt - probieren sollte ja nicht so teuer sein :slight_smile:

Vorweg: von Kleinweichspezifischen Details habe ich keine Ahnung.

Hier steht in pg_tblspc pro Tablespace ein Link zum eigentlichen Ort.
Möglicherweise zeigt(e) das bei Dir wieder eine Ebene höher und nicht wirklich zum eigentlichen Tablespace. Wo liegt der, eine andere Partition oder Platte? Die Daten dort sollten noch da sein.


Andreas

diesen beschriebenen effekt kenn ich - da hats das dateisystem zerhauen …

ich gehe mal nicht davon aus, dass seine verzeichnise links enthalten … da hülft nur reparieren …

Ich gehe schon davon aus, denn sonst macht es wohl wenig Sinn, dies überhaupt anzubieten.

Vielleicht kann ja mal wer erklären, was man sich unter:

PostgreSQL uses a feature in the NTFS filesystem called ‘reparse points’ to implement tablespaces.

nun genau vorstellen kann.


Andreas

Ich mach da mal die Ingried:

Ein Reparse Point ist eine Datei oder ein Verzeichnis im NTFS-Dateisystem, die anzeigt, dass die Datei oder das Verzeichnis nicht innerhalb des Dateisystems liegt, sondern von einem eigenen Dateisystemtreiber behandelt wird und aus einer anderen Quelle stammt.

Andreas

kann es sein . u.a. … was ich natuerlich nun nicht weiss, ob PG diese geschichte genau fuer solche zwecke nutzt …
“to implement tablespace” riecht natuerlich danach - hast recht

Reparse Points (Windows)

so ich habe nun postgres neu installiert und mein backup eingespielt
system läuft also wieder :stuck_out_tongue:

hätte aber noch eine frage … reicht es die komplette platte zu sichern wenn postgres läuft oder muss dafür der dienst immer runtergefahren werden?

alternativ würde ich mich schlau machen wie ich über die kommandozeile bzw per batch die db sichern kann

viele grüße
Thomas

Nein, nein.

alternativ würde ich mich schlau machen wie ich über die kommandozeile bzw per batch die db sichern kann

viele grüße
Thomas

Mach das, das Handbuch hat ein extra Kapitel dafür. Lesenswert.

Andreas

danke für die ganzen tips hier!

ich habs jetzt so gemacht pg_dump db -U postgres >c:\dumptest.tar

nur doof das man das pw als umgebungsvariable setzen muss

Auch für das Passwort gibt es Lösungen, schlag mal unter Services nach und eine pgpass Datei kann man auch anlegen. Letztendlich kann man die Zugriffsrechte für den User, der das Backup zieht, auch als “braucht kein Passwort” definieren.

Ich vermisse jedoch noch etwas ganz wichtiges bei deinem Backup:
Du probierst nicht aus, ob du das wieder einspielen kannst. Ohne diese Information ist das Backup wertlos.