DBMS-Parallelitätskontrolle: Zeitstempel- und sperrenbasierte Protokolle

Gleichzeitiger Zugriff ist recht einfach, wenn alle Benutzer nur Daten lesen. Sie können sich nicht gegenseitig stören. In der Praxis würde es jedoch bei jeder Datenbank eine Mischung aus Lese- und Schreibvorgängen geben, und daher ist die Parallelität eine Herausforderung.

Die DBMS-Parallelitätskontrolle wird verwendet, um solche Konflikte zu lösen, die meistens bei Mehrbenutzersystemen auftreten. Daher ist die Parallelitätskontrolle das wichtigste Element für das ordnungsgemäße Funktionieren eines Datenbankverwaltungssystems, bei dem zwei oder mehr Datenbanktransaktionen gleichzeitig ausgeführt werden, die Zugriff auf dieselben Daten erfordern.

Mögliche Probleme der Parallelität

Hier sind einige Probleme, die bei der Verwendung der DBMS-Parallelitätskontrollmethode wahrscheinlich auftreten werden:

• Verlorene Updates treten auf, wenn mehrere Transaktionen dieselbe Zeile auswählen und die Zeile basierend auf dem ausgewählten Wert aktualisieren
• Probleme mit nicht festgeschriebenen Abhängigkeiten treten auf, wenn die zweite Transaktion eine Zeile auswählt, die von einer anderen Transaktion aktualisiert wird (schmutzig lesen)
• Nicht wiederholbares Lesen tritt auf, wenn eine zweite Transaktion mehrmals versucht, auf dieselbe Zeile zuzugreifen und jedes Mal andere Daten liest.
• Problem mit der falschen Zusammenfassung tritt auf, wenn eine Transaktion den Wert aller Instanzen eines wiederholten Datenelements zusammenfasst und die zweite Transaktion einige Instanzen dieses bestimmten Datenelements aktualisiert. In diesem Fall spiegelt die resultierende Zusammenfassung kein korrektes Ergebnis wider.

Warum die Parallelitätsmethode verwenden?

Gründe für die Verwendung der Parallelitätskontrollmethode sind DBMS:

• Anwendung der Isolation durch gegenseitigen Ausschluss zwischen widersprüchlichen Transaktionen
• Zur Lösung von Lese-Schreib- und Schreib-Schreib-Konfliktproblemen
• Wahrung der Datenbankkonsistenz durch ständige Beibehaltung von Ausführungshindernissen
• Das System muss die Interaktion zwischen den gleichzeitigen Transaktionen steuern. Diese Steuerung wird mithilfe von Parallelsteuerungsschemata erreicht.
• Die Parallelitätskontrolle trägt dazu bei, die Serialisierbarkeit sicherzustellen

Beispiel

Nehmen wir an, dass zwei Personen gleichzeitig zu elektronischen Kiosken gehen, um eine Kinokarte für denselben Film und dieselbe Vorstellungszeit zu kaufen.

Für die Filmvorführung in diesem Kino ist jedoch nur noch ein Platz frei. Ohne Parallelitätskontrolle im DBMS ist es möglich, dass am Ende beide Kinobesucher eine Eintrittskarte kaufen. Die Parallelitätskontrollmethode lässt dies jedoch nicht zu. Beide Kinobesucher können weiterhin auf die in der Kinositzdatenbank enthaltenen Informationen zugreifen. Die Parallelitätskontrolle stellt jedoch nur dem Käufer ein Ticket zur Verfügung, der den Transaktionsprozess zuerst abgeschlossen hat.

Parallelitätskontrollprotokolle

Verschiedene Protokolle zur Parallelitätssteuerung bieten unterschiedliche Vorteile hinsichtlich der von ihnen zugelassenen Parallelität und der von ihnen verursachten Mehraufwandmenge. Im Folgenden sind die Parallelitätssteuerungstechniken in DBMS aufgeführt:

• Sperrbasierte Protokolle
• Zwei-Phasen-Verriegelungsprotokoll
• Zeitstempelbasierte Protokolle
• Validierungsbasierte Protokolle

Eine Sperre ist eine Datenvariable, die einem Datenelement zugeordnet ist. Diese Sperre bedeutet, dass Operationen an dem Datenelement ausgeführt werden können. Sperren in DBMS helfen dabei, den Zugriff auf die Datenbankelemente durch gleichzeitige Transaktionen zu synchronisieren.

Alle Sperranforderungen werden an den Concurrency-Control-Manager gestellt. Transaktionen werden erst fortgesetzt, wenn der Sperranforderung stattgegeben wird.

Binäre Schlösser: Eine binäre Sperre für ein Datenelement kann entweder den Status „gesperrt“ oder „entsperrt“ haben.

Geteilt/exklusiv: Diese Art von Sperrmechanismus trennt die Sperren in DBMS basierend auf ihrer Verwendung. Wenn eine Sperre für ein Datenelement erworben wird, um einen Schreibvorgang auszuführen, wird dies als exklusive Sperre bezeichnet.

1. Gemeinsame Sperre (S):

Eine gemeinsame Sperre wird auch als schreibgeschützte Sperre bezeichnet. Mit der gemeinsamen Sperre kann das Datenelement zwischen Transaktionen gemeinsam genutzt werden. Dies liegt daran, dass Sie niemals die Berechtigung haben, Daten für das Datenelement zu aktualisieren.

Stellen Sie sich beispielsweise einen Fall vor, in dem zwei Transaktionen den Kontostand einer Person ermitteln. Der Datenbank lässt sie lesen, indem eine gemeinsame Sperre eingerichtet wird. Wenn jedoch eine andere Transaktion den Kontostand aktualisieren möchte, verhindert die gemeinsame Sperre dies, bis der Lesevorgang abgeschlossen ist.

2. Exklusive Sperre (X):

Mit der exklusiven Sperre kann ein Datenelement sowohl gelesen als auch geschrieben werden. Dies ist exklusiv und kann nicht gleichzeitig für dasselbe Datenelement gehalten werden. Die X-Sperre wird mit der Anweisung lock-x angefordert. Transaktionen können das Datenelement nach Abschluss des Schreibvorgangs entsperren.

Wenn beispielsweise eine Transaktion den Kontostand einer Person aktualisieren muss, können Sie diese Transaktion zulassen, indem Sie eine X-Sperre darauf setzen. Wenn die zweite Transaktion also lesen oder schreiben möchte, verhindert die exklusive Sperre diesen Vorgang.

3. Vereinfachtes Sperrprotokoll

Diese Art von sperrenbasierten Protokollen ermöglicht Transaktionen, vor Beginn der Operation eine Sperre für jedes Objekt zu erhalten. Transaktionen können das Datenelement nach Abschluss der Schreiboperation entsperren.

4. Vorläufige Sperrung

Das Pre-Claiming-Lock-Protokoll hilft dabei, Vorgänge auszuwerten und eine Liste der erforderlichen Datenelemente zu erstellen, die zum Starten eines Ausführungsprozesses erforderlich sind. In der Situation, in der alle Sperren gewährt wurden, wird die Transaktion ausgeführt. Danach werden alle Sperren freigegeben, wenn alle Vorgänge abgeschlossen sind.

Verhungern

Unter Hunger versteht man die Situation, wenn eine Transaktion auf unbestimmte Zeit warten muss, um eine Sperre zu erhalten.

Die Gründe für Hunger sind:

• Wenn das Warteschema für gesperrte Elemente nicht ordnungsgemäß verwaltet wird
• Im Falle eines Ressourcenlecks
• Die gleiche Transaktion wird wiederholt als Opfer ausgewählt

Deadlock

Ein Deadlock bezeichnet eine bestimmte Situation, in der zwei oder mehr Prozesse aufeinander warten, um eine Ressource freizugeben, oder in der mehr als zwei Prozesse in einer kreisförmigen Kette auf die Ressource warten.

Dieses Sperrprotokoll unterteilt die Ausführungsphase einer Transaktion in drei verschiedene Teile.

• In der ersten Phase, wenn die Transaktion ausgeführt wird, benötigt sie die Erlaubnis für die benötigten Sperren.
• Im zweiten Teil erhält die Transaktion alle Sperren. Wenn eine Transaktion ihre erste Sperre aufhebt, beginnt die dritte Phase.
• In dieser dritten Phase kann die Transaktion keine neuen Sperren verlangen. Stattdessen werden nur die erworbenen Sperren freigegeben.

Das Two-Phase Locking-Protokoll ermöglicht es jeder Transaktion, in zwei Schritten eine Sperr- oder Entsperranforderung zu stellen:

• Wachstumsphase: In dieser Phase kann die Transaktion Sperren erhalten, aber keine Sperren freigeben.
• Schrumpfungsphase: In dieser Phase kann eine Transaktion Sperren freigeben, aber keine neue Sperre erhalten

Das 2PL-Protokoll bietet zwar Serialisierbarkeit, stellt jedoch nicht sicher, dass keine Deadlocks auftreten.

Im oben dargestellten Diagramm können Sie sehen, dass lokale und globale Deadlock-Detektoren nach Deadlocks suchen und diese lösen, indem sie die Transaktionen in ihren Anfangszustand zurücksetzen.

Strenge Zweiphasen-Verriegelungsmethode

Das Strict-Two-Phase-Locking-System ähnelt fast dem 2PL. Der einzige Unterschied besteht darin, dass Strict-2PL nach der Verwendung niemals eine Sperre aufhebt. Es hält alle Sperren bis zum Commit-Punkt und gibt alle Sperren auf einmal frei, wenn der Prozess beendet ist.

Zentralisiertes 2PL

Bei Centralized 2 PL ist ein einzelner Standort für den Sperrverwaltungsprozess verantwortlich. Es gibt nur einen Sperrmanager für das gesamte DBMS.

Primäre Kopie 2PL

Primärer 2PL-Kopiermechanismus, viele Sperrmanager werden auf verschiedene Standorte verteilt. Danach ist ein bestimmter Sperrmanager für die Verwaltung der Sperre für eine Reihe von Datenelementen verantwortlich. Wenn die primäre Kopie aktualisiert wurde, wird die Änderung an die Slaves weitergegeben.

Verteiltes 2PL

Bei diesem zweistufigen Sperrmechanismus werden Sperrmanager an alle Standorte verteilt. Sie sind für die Verwaltung der Datensperren an diesem Standort verantwortlich. Wenn keine Daten repliziert werden, entspricht dies der primären Kopie 2PL. Die Kommunikationskosten von Distributed 2PL sind deutlich höher als die von primärer Kopie 2PL

Bei dieser Methode erhält die ältere Transaktion immer Vorrang. Es verwendet die Systemzeit, um den Zeitstempel der Transaktion zu ermitteln. Dies ist das am häufigsten verwendete Parallelitätsprotokoll.

Sperrbasierte Protokolle helfen Ihnen, die Reihenfolge zwischen den in Konflikt stehenden Transaktionen zu verwalten, wenn diese ausgeführt werden. Zeitstempelbasierte Protokolle verwalten Konflikte, sobald ein Vorgang erstellt wird.

Ejemplo:

Suppose there are there transactions T1, T2, and T3. 
T1 has entered the system at time 0010 
T2 has entered the system at 0020
T3 has entered the system at 0030
Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

Vorteile:

• Zeitpläne sind genau wie 2PL-Protokolle serialisierbar
• Kein Warten auf die Transaktion, wodurch die Möglichkeit von Deadlocks ausgeschlossen wird!

Nachteile:

Ein Verhungern ist möglich, wenn dieselbe Transaktion neu gestartet und immer wieder abgebrochen wird

Das validierungsbasierte Protokoll wird in den folgenden drei Phasen durchgeführt:

1. Lesephase
2. Validierungsphase
3. Schreibphase

Lesephase

In der Lesephase können die Datenwerte aus der Datenbank durch eine Transaktion gelesen werden, aber der Schreibvorgang oder die Aktualisierungen werden nur auf die lokalen Datenkopien angewendet, nicht auf die eigentliche Datenbank.

Validierungsphase

In der Validierungsphase werden die Daten überprüft, um sicherzustellen, dass beim Anwenden der Transaktionsaktualisierungen auf die Datenbank keine Verletzung der Serialisierbarkeit vorliegt.

Schreibphase

In der Schreibphase werden die Aktualisierungen auf die Datenbank angewendet, wenn die Validierung erfolgreich ist, andernfalls; Die Aktualisierungen werden nicht angewendet und die Transaktion wird zurückgesetzt.

Merkmale eines guten Parallelitätsprotokolls

Ein idealer DBMS-Mechanismus zur Parallelitätskontrolle verfolgt die folgenden Ziele:

• Muss gegenüber Standort- und Kommunikationsausfällen widerstandsfähig sein.
• Es ermöglicht die parallele Ausführung von Transaktionen, um maximale Parallelität zu erreichen.
• Seine Speichermechanismen und Rechenmethoden sollten bescheiden sein, um den Overhead zu minimieren.
• Es müssen einige Einschränkungen für die Struktur atomarer Aktionen von Transaktionen erzwungen werden.

Zusammenfassung

• Parallelitätskontrolle ist das Verfahren in DBMS zur Verwaltung gleichzeitiger Vorgänge, ohne dass es zu Konflikten kommt.
• Verlorene Updates, Dirty Read, Non-Repeatable Read und Incorrect Summary Issue sind Probleme, die aufgrund mangelnder Parallelitätskontrolle auftreten.
• Lock-Based, Two-Phase, Timestamp-Based, Validation-Based sind Arten von Parallelitätsverarbeitungsprotokollen
• Die Sperre kann „Gemeinsam“ (S) oder „Exklusiv“ (X) sein.
• Das Zwei-Phasen-Sperrprotokoll, das auch als 2PL-Protokoll bekannt ist, erfordert, dass eine Transaktion eine Sperre erhält, nachdem sie eine ihrer Sperren freigegeben hat. Es besteht aus zwei Phasen: Wachsen und Schrumpfen.
• Der zeitstempelbasierte Algorithmus verwendet einen Zeitstempel, um die Ausführung gleichzeitiger Transaktionen zu serialisieren. Das Protokoll verwendet die Systemzeit oder logische Anzahl als ein Zeitstempel.