Was tun bei Verbindungsabbruch

[xaromz]

Hallo,

ich habe mal eine Frage zur grundsätzlichen Strategie:
Wenn man mit Datenbanken arbeitet, kann es ja immer passieren, dass der Datenbankserver plötzlich nicht mehr erreichbar ist (Netzwerk abgeschmiert, Server abgestürzt...).
Wie ist in so einem Fall die beste Vergehensweise, wenn gerade die Ergebnisse eines Queries durchgegangen werden?

Sollte man, nachdem die Verbindung wieder steht, die Abfrage von vorne beginnen, oder in der Zeile weitermachen, wo man aufgehört hat (dann kann sich aber ja das Ergebnis schon geändert haben)?
Was macht eine Datenbank, wenn z. B. ein Insert/Update-Query nur halb ankommt? Ich hoffe doch, den Müll verwerfen, oder?

Macht Ihr vielleicht alles ganz anders? Ich bin gespannt auf Eure Methoden, mit dieser Situation umzugehen.

Gruß
xaromz

[gmc616]

Hallo xaromz,

Zitat von xaromz:

Sollte man, nachdem die Verbindung wieder steht, die Abfrage von vorne beginnen, oder in der Zeile weitermachen, wo man aufgehört hat (dann kann sich aber ja das Ergebnis schon geändert haben)?

Ich denke die Frage hast du dir grade selbst beantwortet.

Zitat von xaromz:

Was macht eine Datenbank, wenn z. B. ein Insert/Update-Query nur halb ankommt? Ich hoffe doch, den Müll verwerfen, oder?

Eigentlich schon. Große DB's arbeiten mit den Commit/RollBack-Verfahren (heißt des so?).
Somit ist eine Transaktiontion in der DB erst gültig, wenn ein Commit gesendet wurde.
Stürzt der DB-Server mal ab, sind die Daten auf dem Stand des letzten Commits.
Bricht die DB-Verbindung weg, is es ähnlich. Das letzte Commit zählt.

Ich hoffe, ich hab nix falsches erzählt.

[Bernhard Geyer]

Zitat von gmc616:

Ich hoffe, ich hab nix falsches erzählt.

Dies gilt für Datenbanken die das ACID-Eigenschaften besitzt.
Dies sollte für jede "normale" SQL-Datenbank der Fall sein.

Bei Desktopdatenbanken schaut es anders aus. Hier kann sehr wohl ein Verbindungsabbruch zu einer zerschossenen DB oder ungültigen Zustand in der DB führen.

[xaromz]

Hallo,

Zitat von gmc616:

Ich denke die Frage hast du dir grade selbst beantwortet.

Schon klar , dann verändere ich meine Frage: Wenn sowas passiert, sollte man dann sämtliche schon verarbeiteten Werte verwerfen und nochmal von vorne anfangen? Bei meinem aktuellen Projekt erstelle ich für jede Tabellenzeile ein Objekt, ich müsste also alle gelesenen Objekte wieder zerstören und neu erstellen. Da ich ungefär 100 Stellen im Programm habe, wo sowas passiert, wäre ich an einer einfacheren Lösung interessiert. Aber wahrscheinlich ist es wie immer im Leben: Einfache Lösungen gibt es nicht.

Zitat von gmc616:

Eigentlich schon. Große DB's arbeiten mit den Commit/RollBack-Verfahren (heißt des so?).

Ja, das heißt so.

Zitat von gmc616:

Somit ist eine Transaktiontion in der DB erst gültig, wenn ein Commit gesendet wurde.
Stürzt der DB-Server mal ab, sind die Daten auf dem Stand des letzten Commits.
Bricht die DB-Verbindung weg, is es ähnlich. Das letzte Commit zählt.

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig .

Gruß
xaromz

[Bernhard Geyer]

Zitat von xaromz:

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig .

Solche ein Query bekommt die Datenbank gar nicht mit da dies auf tieferer Ebene (vermutlich TCP oder erste Layer darüber) erkannt wird und gar nicht bis zum QueryAnalyser der DB kommen.

[RavenIV]

Zitat von Bernhard Geyer:

Solche ein Query bekommt die Datenbank gar nicht mit da dies auf tieferer Ebene (vermutlich TCP oder erste Layer darüber) erkannt wird und gar nicht bis zum QueryAnalyser der DB kommen.

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Die Transaktionen müssen schon von der Applikation (in diesem Fall die Datenbenk-Software) verwaltet werden. Die meisten DBMS arbeiten intern auf transaktionsbasis, wovon der Anwender (deine Software) nichts mitbekommt.

[Peinhard]

Zitat von xaromz:

Da ich bisher keine Transaktionen verwende (ich habe keine abhängigen Queries), habe ich natürlich auch kein Commit, aber ich gehe trotzdem 'mal davon aus, dass eine Datenbank einen Verbindungsabbruch mitten im Query erkennt. Wenn ich nämlich ein DELETE sende und die WHERE-Klausel verloren geht, ist das nicht so lustig .

Dann arbeitet deine Datenbank bzw die Verbindung/Sitzung mit hoher Wahrscheinlichkeit im AutoCommit-Modus - jedenfalls wenn es sich um ein 'richtiges' DBMS handelt und du erfolgreich Änderungen vornehmen kannst. Das bedeutet, daß das DBMS jeden einzelnen Befehl automatisch selbst in eine Transaktion 'einkapselt'. Lies mal büschen was über Transaktionen, AutoCommit und auch implizite Transaktionen. Und so ganz 'egal' wie du eingangs erwähntest ist die DB natürlich auch nicht - Fileserver-DBs zB verhalten sich deutlich weniger 'gnädig', da kann's dann zB die beliebten 'corrupt indices' setzen.

Die Sorge, daß eine nur 'halb angekommene' Query abgearbeitet wird, ist aber schon 'im Vorfeld' unbegründet, wie Bernhard schon schrieb.

[Bernhard Geyer]

Zitat von RavenIV:

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Dann ist es halt die Klasse/Modul welches auf TCP aufsetzt und den komplett gültige empfang von SQL-Anweisungen verwaltet. Also Layer 5 des OSI-Referenzmodells

[Peinhard]

Zitat von RavenIV:

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Wenn der Befehl aber nur 'halb' ankommt, weil die Verbindung während seiner Übermittlung abreißt, fehlt sozusagen seine 'Terminierung'. Die Engine müßte iü ja auch 'wissen' ob da noch was kommt, oder ob's das jetzt war und sie loslegen soll/kann. Und der Stack 'weiß' zwar nicht was drin ist, aber schon, ob die Übermittlung vollständig ist. Und wenn nicht, geht der Befehl da gar nicht erst raus, sondern es wird eine (dem Szenario entsprechend nicht erfolgreiche) 'Neuverhandlung' versucht. Correct me if I'm wrong...

[RavenIV]

Zitat von Bernhard Geyer:

Zitat von RavenIV:

Das halte ich für ein Gerücht.
Woher soll z.B. der TCP-Stack wissen, was in den TCP-Paketen drin ist.

Dann ist es halt die Klasse/Modul welches auf TCP aufsetzt und den komplett gültige empfang von SQL-Anweisungen verwaltet. Also Layer 5 des OSI-Referenzmodells

Hast Du das OSI-Modell durchgelesen?
Es kann nicht Schicht 5 sein. Die weis noch nichts von DB-Transaktionen.
Erst Schicht 7 – Anwendungsschicht kennt das und kann das auch erst machen.