In der Informatik ist SÄURE (atomicity, Konsistenz, Isolierung, Beständigkeit) eine Reihe von Eigenschaften, die versichern, dass Datenbanktransaktionen zuverlässig bearbeitet werden. Im Zusammenhang von Datenbanken wird eine einzelne logische Operation auf den Daten eine Transaktion genannt. Zum Beispiel ist eine Übertragung des Kapitals von einem Bankkonto bis einen anderen, wenn auch das vielfache Änderungen (wie das Belasten eines Kontos und Glauben einem anderen) einschließen könnte, eine einzelne Transaktion.

Jim Gray hat diese Eigenschaften eines zuverlässigen Transaktionssystems in definiert

das Ende der 1970er Jahre und entwickelten Technologien, um sie automatisch zu erreichen.

1983 haben Andreas Reuter und Theo Härder die Akronym-SÄURE ins Leben gerufen, um sie zu beschreiben.

Eigenschaften

Atomicity

Atomicity verlangt, dass jede Transaktion "alle oder nichts" ist: Wenn ein Teil der Transaktion scheitert, scheitert die komplette Transaktion, und der Datenbankstaat wird unverändert verlassen. Ein Atomsystem muss atomicity in all und jeder Situation, einschließlich Macht-Misserfolge, Fehler und Unfälle versichern.

Konsistenz

Das Konsistenz-Eigentum stellt sicher, dass jede Transaktion die Datenbank von einem gültigem Staat bis einen anderen bringen wird. Irgendwelche der Datenbank geschriebenen Daten müssen gemäß allen definierten Regeln, einschließlich, aber nicht beschränkt auf Einschränkungen, Kaskaden, Abzüge und jede Kombination davon gültig sein.

Isolierung

Isolierung bezieht sich auf die Voraussetzung, dass keine Transaktion im Stande sein sollte, eine andere Transaktion zu stören. Eine Weise, das zu erreichen, ist sicherzustellen, dass keine Transaktionen, die dieselben Reihen betreffen, gleichzeitig laufen können, seitdem ihre Folge, und folglich das Ergebnis, unvorhersehbar sein könnten. Dieses Eigentum von SÄURE wird häufig wegen der riesigen Geschwindigkeitsabnahme teilweise entspannt, die dieser Typ des Parallelitätsmanagements zur Folge hat.

Beständigkeit

Beständigkeit bedeutet, dass sobald eine Transaktion begangen worden ist, wird es so, sogar im Falle des Macht-Verlustes, der Unfälle oder der Fehler bleiben. In einer Verwandtschaftsdatenbank, zum Beispiel, einmal eine Gruppe von SQL Behauptungen führen durch, müssen die Ergebnisse dauerhaft versorgt werden. Wenn die Datenbank sofort danach abstürzt, sollte es möglich sein, die Datenbank zum Staat wieder herzustellen, nachdem die letzte Transaktion begangen hat.

Beispiele

Die folgenden Beispiele werden verwendet, um weiter die SAUREN Eigenschaften zu erklären. In diesen Beispielen hat die Datenbank zwei Felder, A und B in zwei Aufzeichnungen. Eine Integritätseinschränkung verlangt, dass der Wert in A und der Wert in B zu 100 resümieren müssen. Der folgende SQL-Code schafft einen Tisch, wie beschrieben, oben:

SCHAFFEN SIE TISCH acidtest (Eine GANZE ZAHL, B KONTROLLE DER GANZEN ZAHL (+ B = 100));

</syntaxhighlight>

Misserfolg von Atomicity

Die Transaktion macht 10 von A Abstriche und trägt 10 zu B bei. Das ist eine gültige Transaktion, da die Daten fortsetzen, die Einschränkung zu befriedigen, nachdem sie durchgeführt hat. Nehmen Sie jedoch an, dass nach dem Entfernen 10 von A die Transaktion unfähig ist, B zu modifizieren. Wenn die Datenbank den neuen Wert von A, atomicity behalten hat und die Einschränkung beide verletzt würde. Atomicity verlangt, dass beide Teile dieser Transaktion oder keinen, abgeschlossen sind.

Konsistenz-Misserfolg

Konsistenz ist ein sehr allgemeiner Begriff, der fordert, dass die Daten alle Gültigkeitserklärungsregeln entsprechen. Im vorherigen Beispiel ist die Gültigkeitserklärung eine Voraussetzung dass + B = 100. Außerdem kann es angedeutet werden, dass sowohl A als auch B ganze Zahlen sein müssen. Eine gültige Reihe für A und B kann auch einbezogen werden. Alle Gültigkeitserklärungsregeln müssen überprüft werden, um Konsistenz zu sichern.

Nehmen Sie an, dass eine Transaktion versucht, 10 von Abstriche zu machen, ohne B zu verändern. Weil Konsistenz überprüft wird, nach jeder Transaktion ist es bekannt, dass + B = 100 bevor die Transaktion beginnt. Wenn die Transaktion 10 von erfolgreich umzieht, wird atomicity erreicht. Jedoch wird eine Gültigkeitserklärungskontrolle dass + B = 90 zeigen. Das entspricht ordnungsmäßig der Datenbank nicht. Die komplette Transaktion muss annulliert werden, und die betroffenen Reihen zu ihrem Vortransaktionsstaat wiederholt.

In Wirklichkeit geht das viel weiter als einfach A und B, weil er jede einzelne Kaskade oder Abzug-Kette einbezieht, die mit den Ereignissen in der Transaktion, und so jeder Kontrolle über alle indirekt eingeklemmten Werte ebenso verbunden ist.

Wenn es andere Einschränkungen, Abzüge oder Kaskaden gegeben hätte, würde jede einzelne Änderungsoperation ebenso als der obengenannte überprüft worden sein, bevor die Transaktion begangen worden ist.

Isolierungsmisserfolg

Um Isolierung zu demonstrieren, nehmen wir an, dass zwei Transaktionen zur gleichen Zeit, jeder durchführen versuchend, dieselben Daten zu modifizieren. Einer der zwei muss warten bis zum anderen vollendet, um Isolierung aufrechtzuerhalten.

Denken Sie zwei Transaktionen. T wechselt 10 von bis B über. T wechselt 10 von B bis A über. Vereinigt gibt es vier Handlungen:

• machen Sie 10 von Einem Abstriche
• tragen Sie 10 zu B bei.
• machen Sie 10 von B Abstriche
• tragen Sie 10 zu A bei.

Wenn diese Operationen in der Ordnung durchgeführt werden, wird Isolierung aufrechterhalten, obwohl T warten muss. Denken Sie, was geschieht, wenn T halbwegs durch scheitert. Die Datenbank beseitigt die Effekten von T, und T sieht nur gültige Daten.

Durch das Durchschießen der Transaktionen könnte die wirkliche Ordnung von Handlungen sein:. Denken Sie wieder, was geschieht, wenn T scheitert. T macht noch 10 von A Abstriche. Jetzt trägt T 10 zu Einer Wiederherstellung davon zu seinem Anfangswert bei. Jetzt scheitert T. Wie sollte der Wert von A sein? T hat es bereits geändert. Außerdem T hat nie B geändert. T macht 10 davon Abstriche. Wenn T erlaubt wird zu vollenden, wird der Wert von B der Wert des 10 zu niedrigen und A sein wird unverändert sein, eine ungültige Datenbank verlassend. Das ist als ein Schreiben bekannt - schreiben Misserfolg, weil zwei Transaktionen versucht haben, demselben Datenfeld zu schreiben.

Beständigkeitsmisserfolg

Nehmen Sie an, dass eine Transaktion 10 von bis B überwechselt. Es zieht 10 von A um. Es trägt dann 10 zu B bei. An diesem Punkt wird eine "Erfolg"-Nachricht dem Benutzer gesandt. Jedoch werden die Änderungen noch im Plattenpuffer Schlange gestanden, der wartet, um für die Platte begangen zu werden. Macht scheitert, und die Änderungen werden verloren. Der Benutzer nimmt (gültig) an, dass die Änderungen vorgenommen worden sind.

Durchführung

Die Verarbeitung einer Transaktion verlangt häufig eine Folge von Operationen, die dem Misserfolg aus mehreren Gründen unterworfen ist. Zum Beispiel kann das System kein Zimmer auf seinen Laufwerken übrighaben, oder es kann seine zugeteilte Zentraleinheitszeit verbraucht haben.

Es gibt zwei populäre Familien von Techniken: Schreiben Sie vorn Protokollierung und Schattenpaginierung. In beiden Fällen müssen Schlösser auf der ganzen Information erworben werden, die, und abhängig vom Niveau der Isolierung vielleicht auf allen Daten aktualisiert wird, der ebenso gelesen wird. Darin schreiben, dass vorn Protokollierung, atomicity durch das Kopieren der ursprünglichen (unveränderten) Daten zu einem Klotz vor dem Ändern der Datenbank versichert wird. Das erlaubt der Datenbank, zu einem konsequenten Staat im Falle eines Unfalls zurückzukehren.

In der Beschattung werden Aktualisierungen auf eine teilweise Kopie der Datenbank angewandt, und die neue Kopie wird aktiviert, wenn die Transaktion begeht.

Blockierung gegen multiversioning

Viele Datenbanken verlassen sich auf Blockierung, um SAURE Fähigkeiten zur Verfügung zu stellen. Wenn sie Mittel schließt, dass die Transaktion die Daten kennzeichnet, auf die es zugreift, so dass der DBMS weiß, um anderen Transaktionen nicht zu erlauben, es zu modifizieren bis, ist die erste Transaktion erfolgreich oder scheitert. Das Schloss muss immer vor in einer Prozession gehenden Daten einschließlich Daten erworben werden, die gelesen, aber nicht modifiziert werden. Nichttriviale Transaktionen verlangen normalerweise eine Vielzahl von Schlössern, wesentlich oberirdisch hinauslaufend sowie andere Transaktionen blockierend. Zum Beispiel, wenn Benutzer A eine Transaktion führt, die eine Reihe von Daten lesen muss, die Benutzer B modifizieren will, muss Benutzer B warten, bis die Transaktion des Benutzers A vollendet. Zwei Phase-Blockierung wird häufig angewandt, um volle Isolierung zu versichern.

Eine Alternative zur Blockierung ist Mehrversionsparallelitätskontrolle, in der die Datenbank jeder Lesen-Transaktion die vorherige, unmodifizierte Version von Daten zur Verfügung stellt, die durch eine andere aktive Transaktion modifiziert wird. Das erlaubt Lesern zu funktionieren, ohne Schlösser zu erwerben. D. h. Schreiben-Transaktionen blockieren Lesen-Transaktionen nicht, und Leser blockieren Schriftsteller nicht. Zum Beispiel zurückgehend, wenn die Transaktion des Benutzers A um Daten bittet, die Benutzer B modifiziert, stellt die Datenbank mit der Version zur Verfügung der Daten haben die bestanden, als Benutzer B seine Transaktion angefangen hat. Benutzer A bekommt eine konsequente Ansicht von der Datenbank, selbst wenn andere Benutzer Daten ändern. Eine Durchführung entspannt das Isolierungseigentum, nämlich Schnellschuss-Isolierung.

Verteilte Transaktionen

Das Garantieren SAURER Eigenschaften in einer verteilten Transaktion über eine verteilte Datenbank, wo kein einzelner Knoten für alle Daten verantwortlich ist, die eine Transaktion betreffen, präsentiert zusätzliche Komplikationen. Netzverbindungen könnten scheitern, oder ein Knoten könnte seinen Teil der Transaktion erfolgreich vollenden und dann erforderlich sein, seine Änderungen wegen eines Misserfolgs auf einem anderen Knoten zu wiederholen. Die zweiphasigen begehen Protokoll (um mit der zweiphasigen Blockierung nicht verwirrt zu sein) stellt atomicity für verteilte Transaktionen zur Verfügung, um sicherzustellen, dass sich jeder Teilnehmer in der Transaktion einigt, ob die Transaktion begangen werden sollte oder nicht. Kurz, in der ersten Phase, befragt ein Knoten (der Koordinator) die anderen Knoten (die Teilnehmer) und nur, wenn die ganze Antwort, dass sie bereit sind, den Koordinator in der zweiten Phase tut, formalisieren Sie die Transaktion.

Siehe auch

• Offene Systemverbindung
• Transactional NTFS
• Grundsätzlich Verfügbare, Weiche staatliche, Schließliche Konsistenz (BASIS)
• Parallelitätskontrolle

Referenzen

• Grau, Jim, und Reuter, Andreas, Verteilte Transaktionsverarbeitung: Konzepte und Techniken. Morgan Kaufmann, 1993. Internationale Standardbuchnummer 1-55860-190-2.