seit kurzem habe ich auf einem Server erhebliche Probleme. Gewisse SELECT-Abfragen lassen regelmäßig - aber nur bei bestimmten Daten - die Datenbank crashen. Diese SELECT-Abfragen beinhalten JOINS über 5 Tabellen wobei teilweisen auch Sub-SELECT-Abfragen enthalten sind. Bei den meisten Datensätzen funktionieren diese, doch ich habe schon 5 Datensatzkombinationen gefunden, bei denen die Datenbank danach neu gestertet werden muss. Insgesamt sind vielleicht 500 Datensätze vorhanden. Wenn ich diese 5 betroffenen Datensätze jedoch jeweils einzeln aufrufe, werden mir diese tadellos angezeigt.
Einze zusätzliche Eingenart kommt noch hinzu: Wenn ich SELECT … WHERE … IN (SELECT…) in Join umwandle, funktioniert wieder eine Abrage mehr??
Folgendes spuckt mir die Log-Datei aus:
2010-06-06 06:10:26 CEST LOG: Datenbanksystem wurde am 2010-06-06 06:00:31 CEST heruntergefahren
2010-06-06 06:10:26 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:27 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:29 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:29 CEST LOG: Datenbanksystem ist bereit um Verbindungen anzunehmen
2010-06-06 06:10:29 CEST LOG: Autovacuum-Launcher startet
2010-06-06 10:18:25 CEST LOG: Serverprozess (PID 408) beendete mit Status 128
2010-06-06 10:18:25 CEST LOG: aktive Serverprozesse werden abgebrochen
2010-06-06 10:18:25 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-06 10:18:25 CEST DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht hat.
2010-06-06 10:18:25 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-06 10:18:25 CEST LOG: alle Serverprozesse beendet; initialisiere neu
2010-06-06 10:18:35 CEST FATAL: bereits bestehender Shared-Memory-Block wird noch benutzt
2010-06-06 10:18:35 CEST TIPP: Prüfen Sie, ob irgendwelche alten Serverprozesse noch laufen und beenden Sie diese.
Was wurde seitdem verändert (Hardware, Software, Antivirus, Firewall,…)? Grundsätzlich wäre auch wichtig zu wissen, welches OS auf dem Server läuft.
Kannst du ermitteln,
a) welcher Prozess den Crash verursacht (da ich sowieso vermute, dass es Windows ist, schau im Ereignisprotokoll nach)
b) ob die Tabelle, um die es geht, ggf. von einer AV-Software kaputt gemacht wurde
Hier sind noch zwei Links aus der Mailingliste, die sich auch damit beschäftigen:
Die AV-Software (Panda) hat keinerlei Aktivitäten in dem Data-Verzeichnis verzeichnet.
Egal, ob ich nun den von uns geschriebenen Prozess oder die SQL-Konsole des pgAdmin benutze, die DB terminiert regelmäßig, wenn ich bestimmte Daten aufrufe.
Ein Versuch, einen Dump (Plain in SQL) und eine Wiederherstellung in eine neue DB aufgrund der SQL-Datei war erfolgreich, doch das Problem tritt weiterhin auf. Portiere ich die Db auf einen anderen Server, so tritt dieses Problem nicht auf. Eine komplette Postgres-Neuinstallation brachte auch nichts.
So ähnlich hätte ich es auch vermutet.
Bislang scheint es niemanden zu geben, der die Ursache sicher eingrenzen kann. In fast allen (mir bekannten) Fällen ist AV-Software oder Firewall Ursache dafür, manchmal sogar nur Fragmente dieser (ggf. auch schon deinstallierten) Software. Soll heißen, ich würde dir empfehlen, dass Serversystem neu aufzusetzen, da du sonst die “Nadel im Heuhaufen” suchst. Das PostgreSQL selbst läuft ja mit deinen Daten auf einem anderen System, sodass in der restlichen Umgebung des Servers die Ursache zu suchen wäre…
Vielleicht noch ein Tipp am Rande: dreh mal das Debug-Level ordentlich hoch, evtl. gibt’s ja doch noch einen Hinweis.
Müsste doch reichen. Wie kann ich das feststellen?
Mir ist ebenfalls aufgefallen, dass wenn ich ein SUB-SELECT folgender Art anwende
SELECT * FROM tabelle1 WHERE id IN (SELECT id FROM tabelle2 WHERE …)
und die tabelle2 mehr als zwei Zeilen ausgibt, dass der Fehler dann vermehrt auftritt. Bei nur einer Zeile in Ergebnis der tabelle1 ist alles in Ordnung.
Sobald ich das in Join umwandle geht es auch???
Kann damit eventuell jemand was anfangen? Oder benötigt in Sub-SELECT soviel mehr buffer?
Leider schmiert die DB bei 1024MB shared_buffer immernoch ab. Kann ich irgendwie übergrüfen, ob die AV etwas beschädigt hat? Wenn ich die Tabellen einzeln aufrufe, dann funktioniert alles?!
Ich habe mal eine Analyse drüberlaufen lassen. Was sagen mir in folgedem bericht die toten Zeilen:
INFO: »tabelle…«: 16 von 16 Seiten gelesen, enthalten 643 lebende Zeilen und 7 tote Zeilen; 643 Zeilen in Stichprobe, schätzungsweise 643 Zeilen insgesamt
Meine Idee war nur, dass die DB ev. viel zu wenig Speicher für die anstehende Arbeit hat. Aber eigentlich dürfte sie deswegen nicht abstürzen - das habe ich nur einmal im Zusammenhang mit einem Monitoring-System erlebt. Der Cluster hat die DB umgeschaltet, weil aufgrund des Loads die DB nicht rechtzeitig genug antworten konnte.
Das sagt nur, daß aufgrund von UPDATE oder DELETE noch 7 nicht mehr benötigte Versionen alter Datensätze vorhanden sind, ein Preis, den PostgreSQL für MVCC zahlt und der VACUUM nötig macht.
Wenn ich nun die client_min_messages, log_min_messages und log_error_verbosity werte auf debug5 setze, bekomme ich folgenden LOG:
davor nur std.sql
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull,a.atttypmod,a.attlen,a.attnum,pg_get_expr(def.adbin, def.adrelid) as adsrc,dsc.description FROM pg_catalog.pg_namespace n JOIN pg_catalog.pg_class c ON (c.relnamespace = n.oid) JOIN pg_catalog.pg_attribute a ON (a.attrelid=c.oid) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND a.attnum = def.adnum) LEFT JOIN pg_catalog.pg_description dsc ON (c.oid=dsc.objoid AND a.attnum = dsc.objsubid) LEFT JOIN pg_catalog.pg_class dc ON (dc.oid=dsc.classoid AND dc.relname=‘pg_class’) LEFT JOIN pg_catalog.pg_namespace dn ON (dc.relnamespace=dn.oid AND dn.nspname=‘pg_catalog’) WHERE a.attnum > 0 AND NOT a.attisdropped AND c.relname LIKE E’lager_artikel’ AND a.attname LIKE E’%’ ORDER BY nspname,relname,attnum
2010-06-08 18:32:52 CEST DEBUG: StartTransactionCommand
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect>
2010-06-08 18:32:52 CEST DEBUG: StartTransaction
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect nochmals>
2010-06-08 18:32:52 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect und nochmals>
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 6 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 6480) beendete mit Status 128
2010-06-08 18:32:52 CEST LOG: Serverprozess (PID 6480) beendete mit Status 128
2010-06-08 18:32:52 CEST LOG: aktive Serverprozesse werden abgebrochen
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 3360
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 7992
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 5852
2010-06-08 18:32:52 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-08 18:32:52 CEST DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht hat.
2010-06-08 18:32:52 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-08 18:32:52 CEST DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht hat.
2010-06-08 18:32:52 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 7608
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 3560
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 5664
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 7992) beendete mit Status 2
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 3360) beendete mit Status 2
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST LOG: alle Serverprozesse beendet; initialisiere neu
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(1): 2 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: invoking IpcMemoryCreate(size=1099546624)
2010-06-08 18:33:02 CEST FATAL: bereits bestehender Shared-Memory-Block wird noch benutzt
2010-06-08 18:33:02 CEST TIPP: Prüfen Sie, ob irgendwelche alten Serverprozesse noch laufen und beenden Sie diese.
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(1): 1 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: exit(1)
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: Logger fährt herunter
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(0): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(0): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: exit(0)
Leider kann ich daraus nicht die Ursache erkennen. Könnte mir hierbei evtl jemand helfen?
“Die Beschreibung der Ereigniskennung ( 0 ) in (FormService.exe ) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Möglicherweise müssen Sie das Flag /AUXSOURCE= zum Ermitteln der Beschreibung verwenden. Weitere Informationen stehen in Hilfe und Support. Ereignisinformationen: Unsupported operation.”
Also das Log der Datenbank sagt nichts zum Absturz aus.
grübel
Wenn der entsprechende Prozess vom Betriebssystem abgeschossen wurde (warum auch immer) hat der Prozess keine Gelegenheit mehr, irgendetwas ins Log zu schreiben.
Daher sieht man dort wohl auch nichts.
Richtig.
Ich denke, der einzige Hinweis ist nun nur noch diese FormService.exe. K. A. wozu die gehört, zu DB-Server jedenfalls nicht.
Wenn das auch keine Spur ist, bin ich für Plan B, Serversystem neu installieren.
Bitte entschuldigt. Der Formservice ist ein von uns entwickelter Service. Das spielt aber in dem Sinn keine Rolle, da die DB ausch dann crashed, wenn ich dieselbe Anfrage wie im FormService.exe im SQl-Query-Browser der pgAdmin ausführe. Die Fehlermeldung dort bringt nur Fehler
Mehr leider nicht.