Seite 1 von 5 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 44

Thema: "breche Verbindung ab wegen Absturz eines anderen Serverprozesses"

  1. #1
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard "breche Verbindung ab wegen Absturz eines anderen Serverprozesses"

    Hallo,

    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.


    Ich benutze die Version 8.4

    Vielen dank schonmal im Voraus

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

    Standard

    Zitat Zitat von vogelpohl Beitrag anzeigen
    Hallo,

    seit kurzem habe ich auf einem Server erhebliche Probleme.
    Was wurde seitdem verändert (Hardware, Software, Antivirus, Firewall,...)? Grundsätzlich wäre auch wichtig zu wissen, welches OS auf dem Server läuft.


    Zitat Zitat von vogelpohl Beitrag anzeigen
    Gewisse SELECT-Abfragen lassen regelmäßig - aber nur bei bestimmten Daten - die Datenbank crashen.
    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:

    PostgreSQL crashes
    DB terminating

    Entscheidene Frage sollte für dich aber sein, was sich verändert hat, seidem des Problem auftritt...

  3. #3
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard

    Vielen Dank für die schnelle Antwort.

    Plattform: Windows Server 2003 (32Bit, 3GB Ram)

    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.

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

    Standard

    Zitat Zitat von vogelpohl Beitrag anzeigen
    Portiere ich die Db auf einen anderen Server, so tritt dieses Problem nicht auf.

    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.

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

    Standard

    Ich kann da murphy nur zustimmen - AV-Software macht da mehr kaputt als es hilft.

    Ach so, noch eine Frage - das ist aber mehr ein Schuß ins Blaue: wie ist deine "shared_buffers" Einstellung?
    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

  6. #6
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard

    Zitat Zitat von murphy Beitrag anzeigen
    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.
    ich denke, dass das die beste Möglichkeit sein wird

  7. #7
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Ach so, noch eine Frage - das ist aber mehr ein Schuß ins Blaue: wie ist deine "shared_buffers" Einstellung?
    shared_buffers=32MB
    temp_buffers=8MB

    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?

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

    Standard

    Setz mal "shared_buffers" höher, auf 1/4 bis 1/6 vom Hauptspeicher. Und schau, ob dann die Datenbank noch abstürzt.
    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
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Setz mal "shared_buffers" höher, auf 1/4 bis 1/6 vom Hauptspeicher. Und schau, ob dann die Datenbank noch abstürzt.
    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?!

  10. #10
    vogelpohl ist offline Neuer Benutzer
    Registriert seit
    06.06.2010
    Beiträge
    19

    Standard

    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

Seite 1 von 5 123 ... LetzteLetzte

Ähnliche Themen

  1. Frage Datenbanken auf anderen Server "umpolen"
    Von Karl der Heinz im Forum Allgemeines
    Antworten: 17
    Letzter Beitrag: 13.04.2012, 10:15
  2. Antworten: 7
    Letzter Beitrag: 03.02.2012, 09:58
  3. Antworten: 14
    Letzter Beitrag: 03.11.2010, 13:43
  4. Antworten: 11
    Letzter Beitrag: 09.07.2009, 10:07
  5. "Group-by" und "max" Funktionen verknüpfen
    Von superguddy777 im Forum SQL
    Antworten: 1
    Letzter Beitrag: 22.08.2007, 08:35

Stichworte

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