psql -l zeigt keine Datenbanken mehr

Hallo zusammen

Seit dem Wochenende habe ich nen halben SuperGAU auf unserem DB Server in der Bude! Aus irgendeinem Grund, wird bei psql -l einfach keine Datenbank mehr anzeigt! Auch via PGadmin seh ich auf einmal keine Datenbanken mehr.

Das krasse: der Betrieb läuft problemlos - ich kann sogar auf der “nicht vorhandenen” Datenbank trackerdb selects abschicken und bekomm Antworten… :confused:
Ebenfalls läuft auch kein Dump mehr - da dieser mit psql -l die DBs abfragen tut.

Hier die Beispiele:

postgres@db:~$ psql trackerdb              
Welcome to psql 7.4.23, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit

trackerdb=# \dt
                 List of relations
 Schema |           Name           | Type  | Owner 
--------+--------------------------+-------+-------
 public | address                  | table | 
 public | billingclass             | table | 
 public | billingitem              | table | 
 public | billingproduct           | table | 
 public | billingproductgroup      | table | 
 public | credititem               | table | 
 public | dboperation              | table | 
 public | docsisaccounting         | table | 
 public | docsiscpe                | table | 
 public | docsismodem              | table | 
 public | docsismodemdata          | table | 
 public | docsismonitoring         | table | 
 public | docsismonitoring_mac_kum | table | 
 public | domain                   | table | 
 public | emailaccount             | table | 
 public | invoice                  | table | 
 public | ipaccounting             | table | 
 public | logentry                 | table | 
 public | payment                  | table | 
 public | radiusaccount            | table | 
 public | staticip                 | table | 
 public | subscription             | table | 
 public | subscriptiontype         | table | 
 public | voipaccount              | table | 
 public | voipcall                 | table | 
(25 rows)



postgres@db:~$ psql -l                     
    List of databases
 Name | Owner | Encoding 
------+-------+----------
(0 rows)

Hat mir jemand irgendwelche Ideen oder Problemlösungen? Irgendwie weiss ich echt nicht mehr weiter :frowning:

Danke und Gruss

Was ist genau passiert, was steht im Log und was zeigt select * from pg_database ;?

Andreas

Welche psql Version (psql --version) ist das? Kommt die vielleicht von einer anderen Installation und connected zu einer anderen Default Datenbank?

Oh, und an dieser Stelle hoffe ich (nur zur Sicherheit), ihr habt gregelmäßige Backups.

7.4.23. Wer lesen kann, …

Andreas

Hier mal der select

trackerdb=# select * from pg_database;
 datname | datdba | encoding | datistemplate | datallowconn | datlastsysoid | datvacuumxid | datfrozenxid | datpath | datconfig | datacl 
---------+--------+----------+---------------+--------------+---------------+--------------+--------------+---------+-----------+--------
(0 rows)

Nur mal so ne dumme Frage, “ohne” Datenbank… obwohl die DB existiert… wie mach ich nen dump? Langsam hab ich bissel Panik.

Was ich im Log unter /var/log/ gefunden habe war das:

2009-02-08 01:25:20 ERROR:  relation "field" does not exist 
2009-02-08 01:25:20 ERROR:  relation "dbconfig" does not exist
2009-02-08 01:25:25 ERROR:  relation "attachments" does not exist
2009-02-08 01:25:32 ERROR:  relation "attachments" does not exist

Und seit dem müllt es mir die DB zu mit dem attachements Fehler. Gibts noch na nderes Log, das ich konsultieren könnte?

Das ist die Datenbankversion, nicht die psql Version. Wer lesen kann … :slight_smile:

Ok, was genau wurde am Wochenende verändert? Irgendeinen Grund muss es ja haben, dass es nicht mehr funktioniert.

Stehen die Fehlermeldungen im Log in irgendeinem Zusammenhang mit Aktionen, die du ausführst?



postgres@db:~$ psql --version
psql (PostgreSQL) 7.4.23
contains support for command-line editing

Es wurde weder ein Update noch eine zweite DB Instanz installiert - das Problem tratt am Wochenende auf als niemand am arbeiten war. :confused:

Gut, stehen die Einträge im Log in irgendeinem Verhältnis zu deinen Versuchen?

Kannst du psql mal mit den Optionen -e und -E starten und die dann ausgegebenen Queries manuell probieren?

Den Dump macht man nicht, wenn man das Restore braucht. Dann ist es zu spät.

Irgend was ist kapott, zumindest die pg_database.

Sind es viele Tabellen? Uhm, ich wollt grad vorschlagen, diese via COPY zu exportieren, daß man die Daten wenigstens hat. Aber hat 7.4 schon COPY?

Was für andere Objekte hast Du noch so, z.B. Trigger oder Rules oder stored Procs?

Wenn pg_dump nicht geht, weil es keine DBs findet, vielleicht geht pg_dumpall?


Andreas

@ads
Auch mit -e oder -E bekomm ich keine besseren Ergebnisse. Und ne, diese Logeinträge haben nichts mit meinen Versuchen zu tun - an der DB wurde nach meinem Wissen nicht gearbeitet.

@akretschmer
pg_dumpall zeigt mir gerade mal template1 und pg_group. Mehr kennt die DB nicht mehr. Den COPY Befehl kennt 7.4, also ich kann ich wählen… die kopier ich die Daten ?

Gruss und Danke für eure Hilfe

Okay. Mit

psql test -c "select table_name from information_schema.tables where table_schema='public'"

kannst Du alle Tabellen eines Schemas listen. Mit etwas Magie und Tools wie sed oder awk oder perl frickelst Du daraus für alle Tabellen Befehle a la

COPY table to '/tmp/table.csv';

Das kannst Du dann als Scriptfile in psql laufen lassen.

Achtung: das erstellt nur die Daten der Tabellen als CSV-Dateien. Dir fehlt dann noch immer die Tabellendefinition und alle anderen Objekte der DB.

Einfacher wäre es natürlich, einfach das letzte Backup zu verwenden…


Andreas

Alles klar - rein theoretisch kann man auch die ganzen Definitionen und restlichen Objekte mit einem leeren Gerüst hoch ziehen und die Daten einfach als Import wieder einbauen?

Ich arbeit auch lieber länger, sofern ich ned die Daten von Sonntag-Dienstag verliere :astonished:

Ist mir klar, dass die nichts anderes anzeigen. Aber psql müsste dir die generierten SQL-Queries zeigen und die kannst du manuell ausführen.

Schau, was dabei herauskommt und ob es Fehler gibt.

Sicherlich. Aber es gibt Fallstricke ohne Ende, schon z.B. ist die Reihenfolge wichtig, wenn FK-Beziehungen im Spiel sind. pg_dump(all) wurde erfunden, dies zu vereinfachen…

Andreas

Mhm is klar… bah! :frowning:

Mh mal dumm gefragt: diese pg_database existiert die irgendwo auf dem Filesystem oder ist das Postgres intern? Und mal ganz abgedreht: was passiert, wenn man der eigene “temporäre” Angaben macht, damit die Datenbank wieder “vorhanden” ist?

Da diese Überlegung so simpel ist, denke ich, dass es nicht machbar ist weil … ?

… das keine realen Tabellen sind sondern aus den vorhandenen Daten generierte.

So, wie sieht es aus, habt ihr ein Backup?

Aber wo die Fehler genau herkommen weiss ich nicht, dafür müsste vielleicht mal jemand direkt auf den Server schauen.

Du nicht wissen wirst, was in

test=*# \d pg_database
    Table "pg_catalog.pg_database"
    Column     |   Type    | Modifiers
---------------+-----------+-----------
 datname       | name      | not null
 datdba        | oid       | not null
 encoding      | integer   | not null
 datistemplate | boolean   | not null
 datallowconn  | boolean   | not null
 datconnlimit  | integer   | not null
 datlastsysoid | oid       | not null
 datfrozenxid  | xid       | not null
 dattablespace | oid       | not null
 datconfig     | text[]    |
 datacl        | aclitem[] |

da nun alles einzutragen ist. Außerdem, vermute ich mal, wird PG gar nicht zulassen, daß Du in Systemtabellen rumschmierst. Wowereit.

Andreas

@ads
Ja wir haben ein Backup - nur mit einem Restore ist es nicht gemacht. Es kann nicht sein, dass einfach über Nacht mal die pg_database verschwindet und man in den Logfiles von Postgres nichts sieht.

Ganz zu schweigen, dass das letzte Backup vom Sonntag ist - logisch, die pg_database ist seit Sonntag leer.

Ehm blöde Frage, wie spiele ich nen Dump ein, wenn die DB nicht vorhanden ist und somit nicht drop-bar ist? :astonished:

In der Tat. Daher haben ads und ich auch nach Ursachen gefragt. Denkbar ist vieles, z.B. auch ein Plattenschaden. Falls die Platte so alt wie die Version von PG ist, würde mich das nicht wundern.

Ganz zu schweigen, dass das letzte Backup vom Sonntag ist - logisch, die pg_database ist seit Sonntag leer.

Ich kann Deiner Logik nicht ganz folgen. Möglicherweise solltest Du Dein Backup-Konzept überdenken.

Ehm blöde Frage, wie spiele ich nen Dump ein, wenn die DB nicht vorhanden ist und somit nicht drop-bar ist? > :astonished: >

Bei dem, was passiert ist, würde ich der kompletten DB nicht mehr trauen. Also, alles komplett flach machen und mit initdb einen neuen Cluster aufbauen. Und vorher drüber meditieren, ob nicht Platte oder DB oder besser beides erneuert werden sollte. 7.4 steht unmittelbar vor Ende der Ünterstützung, aktuell ist 8.3 und 8.4 ist fast im Beta-Stadium.

Andreas