info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Frage zu Sperrverfahren beim Transaktionsmanagement
7 views
Skip to first unread message
algore87
Sep 19, 2015, 6:42:58 PM9/19/15
to
Hallo, ich bins mal wieder :)
bin mittlerweile fast mit dem Buch durch, doch beim Thema Sperrverfahren tu ich mir etwas schwer.
Es geht beim Thema Transaktionen darum die Nebenläufigkeitskontrolle in den Griff zu bekommen, bzw. die Probleme die mit ihr einher gehen. Es gibt vier Hauptprobleme, die auftreten können, wenn zwei Transaktionen zur gleichen Zeit verarbeitet werden.
Dirty Read, eine Transaktion verändert einen Wert, der von der zweiten gelesen wird, aus irgendeinem Grund bricht T1 ab (es kommt zum Rollback), doch T2 sieht diese "dirty data".
Unrepeatable Read. T1 liest einen Wert, dieser wird von T2 verändert und committed, wenn T1 erneut den Wert liest hat er sich verändert (aufgrund der veränderung von T2). Zwei mal lesen, zwei verschiedene Werte.
Lost-Update. T1 verändert einen Wert, T2 verändert diesen Wert ebenfalls, T1 committed, danach committed T2. Die Veränderung von T1 auf den Wert wird quasi übersehen, das Update geht verloren.
Phantom Read. Dabei geht es um das Einfügen von Datensätzen. T1 liest eine Tabelle, sie hat bswp. 3 Datensätze, T2 fügt in ihr einen Wert ein, sobald T1 erneut die Tabelle liest, besitzt sie 4 Datensätze. Der Datensatz erscheint aus dem nichts, quasi ein Phantom.
Um diese Probleme zu adressieren wird eines der Grundprinzipien des Transaktionsmanagements verwendet, nämlich die Isolation. Der Sinn dahinter, dass jede Transaktion isoliert voneinander zu betrachten ist. Praktisch lässt sich das nicht umsetzen, aufgrund von so vielen Transaktionen bei großen Datenbanken, dass das Hintereinanderreihen (=rein serieller Ausführungsplan) zu viel Zeit kosten würde. Also wird versucht die einzelnen Transaktionen ineinander so zu verschachteln, damit die Konsistenz, Dauerhaftigkeit gewahrt wird.
Aufgrund von starken Performanceunterschiede, beim adressieren der obigen Probleme, wurden mehrere Isolationslevel eingeführt. Quasi Stufen, die den Grad der Isolation regeln. Der SQL Standart schlägt 4 Stück vor. READ UNCOMMITTED READ COMMITTED REPEATABLE READ und SERIALIZABLE.
Um nun die einzelnen Probleme in den Griff zu bekommen gibt es mehrere Strategien. Eine der einfachsten, ist das Shared/Exclusive-Lock Sperrprinzip. Das besagt, dass wenn ein Objekt einer Transaktion gelesen wird, dieses Objekt ein geteiltes Schloss bekommt. Andere Transaktionen die das Objekt ebenfalls lesen möchten, können dies tun. Sobald jedoch eine der Transaktionen schreiben möchte, muss sie einen Exclusive-Lock, also einen exklusives Schloss anfordern, um dieses Schloss zu erhalten, müssen jedoch vorher sämtliche Shared-Locks entsperrt werden. Danach kann die Transaktion mit dem Exclusive-Lock loslegen, das Objekt zu verändern. Während dieses Schloss aktiv ist, können keine weiteren Transaktionen das Objekt lesen geschweige denn schreiben.
Das Problem mit dieser Art von Sperre ist, dass es zu Deadlocks, quasi Verklemmungen führen kann. Wenn zwei Aktionen gerade den Shared-Lock nutzen, die eine nun den Exclusive-Lock bei der anderen anfordert und die andere nun auf die Idee kommt ebenfalls, bei der anderen den Exclusive-Lock zu fordern. Beide warten auf den anderen.
Dieses Problem wird dahin gelöst, das es Möglichkeiten gibt über Graphen nachzuvollziehen, ob ein solcher Deadlock entstanden ist. Danach kann eine der beiden (die Opfertransaktion) gewaltsam abgebrochen werden um die Verklemmung zu lösen. Ein anderer Weg ist, generell ein Timeout auf Transaktionen zu geben, wird ein gewisse Wartezeit überschritten, bricht sie automatisch ab.
Ein weiteres Verfahren um die 4 Probleme zu lösen ist das des MVCC, Multiversionnebenläufigkeitskontrolle. Dabei gibt es nicht nur eine Version eines Objekts, sondern viele, die verschiedene Zustände (Werte) besitzen können. Kombiniert mit Zeitstempel, besitzt jede Transaktion zu beginn einen solchen Stempel um sie zu identifizieren. Jeder Lese- und Schreibvorgang wird wiederum geloggt. Also MVCC ist mir noch nicht so ganz klar.
Meine Frage dreht sich darum, welche Strategien denn wirklich eingesetzt werden und wovon das abhängt. Das hängt ja nicht vom Isolationslevel ab oder? Von der Engine der Datenbank? Kann entweder nur das Sperrverfahren eingesetzt werden oder auch MVCC? Also eine Mischung, bzw. MVCC hat ja auch etwas ähnliches wie die Locks oder? Um diese Deadlocks zu vermeiden sollte man eine niedrigeren Isolationlevel wählen oder? Irgendwo habe ich aufgeschnappt, dass das Problem bei Serializeable (der höchsten Stufe) ebenfalls nicht auftreten kann. Gemeint sind Deadlocks.
Hoffe ihr könnt mich etwas erleuchten. Vielen Dank
Mit freundlichen Grüßen,
A. S.
bin mittlerweile fast mit dem Buch durch, doch beim Thema Sperrverfahren tu ich mir etwas schwer.
Es geht beim Thema Transaktionen darum die Nebenläufigkeitskontrolle in den Griff zu bekommen, bzw. die Probleme die mit ihr einher gehen. Es gibt vier Hauptprobleme, die auftreten können, wenn zwei Transaktionen zur gleichen Zeit verarbeitet werden.
Dirty Read, eine Transaktion verändert einen Wert, der von der zweiten gelesen wird, aus irgendeinem Grund bricht T1 ab (es kommt zum Rollback), doch T2 sieht diese "dirty data".
Unrepeatable Read. T1 liest einen Wert, dieser wird von T2 verändert und committed, wenn T1 erneut den Wert liest hat er sich verändert (aufgrund der veränderung von T2). Zwei mal lesen, zwei verschiedene Werte.
Lost-Update. T1 verändert einen Wert, T2 verändert diesen Wert ebenfalls, T1 committed, danach committed T2. Die Veränderung von T1 auf den Wert wird quasi übersehen, das Update geht verloren.
Phantom Read. Dabei geht es um das Einfügen von Datensätzen. T1 liest eine Tabelle, sie hat bswp. 3 Datensätze, T2 fügt in ihr einen Wert ein, sobald T1 erneut die Tabelle liest, besitzt sie 4 Datensätze. Der Datensatz erscheint aus dem nichts, quasi ein Phantom.
Um diese Probleme zu adressieren wird eines der Grundprinzipien des Transaktionsmanagements verwendet, nämlich die Isolation. Der Sinn dahinter, dass jede Transaktion isoliert voneinander zu betrachten ist. Praktisch lässt sich das nicht umsetzen, aufgrund von so vielen Transaktionen bei großen Datenbanken, dass das Hintereinanderreihen (=rein serieller Ausführungsplan) zu viel Zeit kosten würde. Also wird versucht die einzelnen Transaktionen ineinander so zu verschachteln, damit die Konsistenz, Dauerhaftigkeit gewahrt wird.
Aufgrund von starken Performanceunterschiede, beim adressieren der obigen Probleme, wurden mehrere Isolationslevel eingeführt. Quasi Stufen, die den Grad der Isolation regeln. Der SQL Standart schlägt 4 Stück vor. READ UNCOMMITTED READ COMMITTED REPEATABLE READ und SERIALIZABLE.
Um nun die einzelnen Probleme in den Griff zu bekommen gibt es mehrere Strategien. Eine der einfachsten, ist das Shared/Exclusive-Lock Sperrprinzip. Das besagt, dass wenn ein Objekt einer Transaktion gelesen wird, dieses Objekt ein geteiltes Schloss bekommt. Andere Transaktionen die das Objekt ebenfalls lesen möchten, können dies tun. Sobald jedoch eine der Transaktionen schreiben möchte, muss sie einen Exclusive-Lock, also einen exklusives Schloss anfordern, um dieses Schloss zu erhalten, müssen jedoch vorher sämtliche Shared-Locks entsperrt werden. Danach kann die Transaktion mit dem Exclusive-Lock loslegen, das Objekt zu verändern. Während dieses Schloss aktiv ist, können keine weiteren Transaktionen das Objekt lesen geschweige denn schreiben.
Das Problem mit dieser Art von Sperre ist, dass es zu Deadlocks, quasi Verklemmungen führen kann. Wenn zwei Aktionen gerade den Shared-Lock nutzen, die eine nun den Exclusive-Lock bei der anderen anfordert und die andere nun auf die Idee kommt ebenfalls, bei der anderen den Exclusive-Lock zu fordern. Beide warten auf den anderen.
Dieses Problem wird dahin gelöst, das es Möglichkeiten gibt über Graphen nachzuvollziehen, ob ein solcher Deadlock entstanden ist. Danach kann eine der beiden (die Opfertransaktion) gewaltsam abgebrochen werden um die Verklemmung zu lösen. Ein anderer Weg ist, generell ein Timeout auf Transaktionen zu geben, wird ein gewisse Wartezeit überschritten, bricht sie automatisch ab.
Ein weiteres Verfahren um die 4 Probleme zu lösen ist das des MVCC, Multiversionnebenläufigkeitskontrolle. Dabei gibt es nicht nur eine Version eines Objekts, sondern viele, die verschiedene Zustände (Werte) besitzen können. Kombiniert mit Zeitstempel, besitzt jede Transaktion zu beginn einen solchen Stempel um sie zu identifizieren. Jeder Lese- und Schreibvorgang wird wiederum geloggt. Also MVCC ist mir noch nicht so ganz klar.
Meine Frage dreht sich darum, welche Strategien denn wirklich eingesetzt werden und wovon das abhängt. Das hängt ja nicht vom Isolationslevel ab oder? Von der Engine der Datenbank? Kann entweder nur das Sperrverfahren eingesetzt werden oder auch MVCC? Also eine Mischung, bzw. MVCC hat ja auch etwas ähnliches wie die Locks oder? Um diese Deadlocks zu vermeiden sollte man eine niedrigeren Isolationlevel wählen oder? Irgendwo habe ich aufgeschnappt, dass das Problem bei Serializeable (der höchsten Stufe) ebenfalls nicht auftreten kann. Gemeint sind Deadlocks.
Hoffe ihr könnt mich etwas erleuchten. Vielen Dank
Mit freundlichen Grüßen,
A. S.
Florian Weimer
Sep 21, 2015, 1:38:56 AM9/21/15
to
* algore:
> Ein weiteres Verfahren um die 4 Probleme zu lösen ist das des MVCC,
> Multiversionnebenläufigkeitskontrolle. Dabei gibt es nicht nur eine
> Version eines Objekts, sondern viele, die verschiedene Zustände
> (Werte) besitzen können. Kombiniert mit Zeitstempel, besitzt jede
> Transaktion zu beginn einen solchen Stempel um sie zu
> identifizieren. Jeder Lese- und Schreibvorgang wird wiederum
> geloggt. Also MVCC ist mir noch nicht so ganz klar.
MVCC läßt sich nicht so recht auf die 4 Probleme abbilden.
> Meine Frage dreht sich darum, welche Strategien denn wirklich
> eingesetzt werden und wovon das abhängt. Das hängt ja nicht vom
> Isolationslevel ab oder? Von der Engine der Datenbank? Kann entweder
> nur das Sperrverfahren eingesetzt werden oder auch MVCC? Also eine
> Mischung, bzw. MVCC hat ja auch etwas ähnliches wie die Locks oder?
Es hängt von der Datenbank ab. Die meisten MVCC-Implementierungen
bieten auch Sperren an, die von der Anwendung genutzt werden können,
und nutzen natürlich Sperren intern, um MVCC selbst zu implementieren.
> Um diese Deadlocks zu vermeiden sollte man eine niedrigeren
> Isolationlevel wählen oder?
Niedrigere Isolation erhöht jedenfalls den Durchsatz, auch durch den
Wegfall von Verklemmungen.
> Irgendwo habe ich aufgeschnappt, dass das Problem bei Serializeable
> (der höchsten Stufe) ebenfalls nicht auftreten kann. Gemeint sind
> Deadlocks.
Das stimmt im allgemeinen nicht.
> Ein weiteres Verfahren um die 4 Probleme zu lösen ist das des MVCC,
> Multiversionnebenläufigkeitskontrolle. Dabei gibt es nicht nur eine
> Version eines Objekts, sondern viele, die verschiedene Zustände
> (Werte) besitzen können. Kombiniert mit Zeitstempel, besitzt jede
> Transaktion zu beginn einen solchen Stempel um sie zu
> identifizieren. Jeder Lese- und Schreibvorgang wird wiederum
> geloggt. Also MVCC ist mir noch nicht so ganz klar.
> Meine Frage dreht sich darum, welche Strategien denn wirklich
> eingesetzt werden und wovon das abhängt. Das hängt ja nicht vom
> Isolationslevel ab oder? Von der Engine der Datenbank? Kann entweder
> nur das Sperrverfahren eingesetzt werden oder auch MVCC? Also eine
> Mischung, bzw. MVCC hat ja auch etwas ähnliches wie die Locks oder?
bieten auch Sperren an, die von der Anwendung genutzt werden können,
und nutzen natürlich Sperren intern, um MVCC selbst zu implementieren.
> Um diese Deadlocks zu vermeiden sollte man eine niedrigeren
> Isolationlevel wählen oder?
Wegfall von Verklemmungen.
> Irgendwo habe ich aufgeschnappt, dass das Problem bei Serializeable
> (der höchsten Stufe) ebenfalls nicht auftreten kann. Gemeint sind
> Deadlocks.
Wolfgang May
Sep 21, 2015, 5:52:08 AM9/21/15
to
algore87 <s25wfqfi...@user.narkive.com> wrote:
> Hallo, ich bins mal wieder :)
>
> bin mittlerweile fast mit dem Buch durch, doch beim Thema Sperrverfahren tu ich mir etwas schwer.
> Es geht beim Thema Transaktionen darum die Nebenläufigkeitskontrolle
in den Griff zu bekommen, bzw. die Probleme die mit ihr einher
gehen. Es gibt vier Hauptprobleme, die auftreten können, wenn zwei
Transaktionen zur gleichen Zeit verarbeitet werden.
[...]
> Hallo, ich bins mal wieder :)
>
> bin mittlerweile fast mit dem Buch durch, doch beim Thema Sperrverfahren tu ich mir etwas schwer.
> Es geht beim Thema Transaktionen darum die Nebenläufigkeitskontrolle
in den Griff zu bekommen, bzw. die Probleme die mit ihr einher
gehen. Es gibt vier Hauptprobleme, die auftreten können, wenn zwei
Transaktionen zur gleichen Zeit verarbeitet werden.
> Meine Frage dreht sich darum, welche Strategien denn wirklich
eingesetzt werden und wovon das abhängt. Das hängt ja nicht vom
Isolationslevel ab oder? Von der Engine der Datenbank? Kann entweder
nur das Sperrverfahren eingesetzt werden oder auch MVCC? Also eine
Mischung, bzw. MVCC hat ja auch etwas ähnliches wie die Locks oder?
Um diese Deadlocks zu vermeiden sollte man eine niedrigeren
Isolationlevel wählen oder? Irgendwo habe ich aufgeschnappt, dass
das Problem bei Serializeable (der höchsten Stufe) ebenfalls nicht
auftreten kann. Gemeint sind Deadlocks.
Man muss zwei Aspekte unterschieden: die "Isolation Levels", die abstrakte
Korrektheitsaussagen machen, und die jeweiligen Algorithmen, die dazu
angewendet werden.
Die 4 im SQL-Standard vorgesehenen Isolation Levels sind hier ganz gut beschrieben:
<https://de.wikipedia.org/wiki/Isolation_%28Datenbank%29>
Sie unterscheiden sich darin, welche der von Dir oben genannten Fehlersituationen damit
verhindert werden.
Nur "Serializable" verhindert alle. D.h., die anderen Levels erzeugen potentiell
unkorrekte Ablaeufe (je nach Struktur der Transaktionen und der Anwendungssituation
macht das aber nichts - wenn z.B. garkeine Transaktion schreibend zugreift,
oder nur nachts geschrieben und tagsueber gelesen wird, oder wenn die Anwendung
eher nur grobe Statistikwerte liefern soll).
Dann gibt es unterschiedliche Algorithmen zur Implementierung des
Serializable-Levels. Sperrverfahren sind nur eine der Moeglichkeiten;
es gibt auch andere, z.B. Conflict Graph, Timestamps, Optimistische
Strategien. Innerhalb der Sperrverfahren-Algorithmen koennen
ueblicherweise auch Deadlocks auftreten (stoert aber nach aussen hin
niemanden: dann wird halt eine Transaktion per Rollback abgeschossen
und neu gestartet). 2-Phasen-Locking garantiert Serialisierbarkeit,
aber verhindert erstmal keine Deadlocks. Das kann man durch (Laufzeit
kostende) Erweiterungen, z.B. "alles zu Beginn der Transaktion
locken", oder "Objekte nur in aufsteigender Reihenfolge locken" oder
durch Wartegraphalgorithmen tun.
Wolfgang
0 new messages