{"id":30878,"date":"2019-10-31T21:37:56","date_gmt":"2019-10-31T18:37:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-i-mehanizmy-ih-kontrolya\/"},"modified":"2019-10-31T21:37:56","modified_gmt":"2019-10-31T18:37:56","slug":"tranzaktsii-i-mehanizmy-ih-kontrolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transaktionen und deren Kontrollmechanismen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transaktionen<\/h2>\n

<\/p>\n

Eine Transaktion bezeichnet eine Folge von Datenoperationen mit einem Anfang und einem Ende.<\/h4>\n

\nEine Transaktion ist die sequenzielle Ausf\u00fchrung von Lese- und Schreiboperationen. Das Ende einer Transaktion kann entweder die Speicherung von \u00c4nderungen (Commit) oder die R\u00fcckg\u00e4ngigmachung von \u00c4nderungen (Rollback) sein. In Bezug auf Datenbanken ist eine Transaktion eine Gruppe von Anfragen, die als eine einzige Anfrage betrachtet werden.<\/p>\n

Transaktionen m\u00fcssen den ACID-Eigenschaften entsprechen.<\/h4>\n

\nAtomarit\u00e4t. Eine Transaktion wird entweder vollst\u00e4ndig ausgef\u00fchrt oder gar nicht.<\/p>\n

Konsistenz. Beim Abschluss einer Transaktion d\u00fcrfen die auferlegten Einschr\u00e4nkungen f\u00fcr die Daten (z. B. Constraints in der DB) nicht verletzt werden. Konsistenz bedeutet, dass das System von einem korrekten Zustand in einen anderen korrekten Zustand \u00fcberf\u00fchrt wird.<\/p>\n

Isolation. Parallel ausgef\u00fchrte Transaktionen d\u00fcrfen sich nicht gegenseitig beeinflussen, z. B. keine Daten \u00e4ndern, die von einer anderen Transaktion verwendet werden. Das Ergebnis parallel ausgef\u00fchrter Transaktionen sollte so sein, als ob die Transaktionen nacheinander durchgef\u00fchrt worden w\u00e4ren.<\/p>\n

Best\u00e4ndigkeit. Nach der Best\u00e4tigung d\u00fcrfen \u00c4nderungen nicht verloren gehen.
\n<\/a><\/noindex><\/p>\n

Transaktionsprotokoll<\/h2>\n

<\/p>\n

Das Protokoll speichert \u00c4nderungen, die durch Transaktionen vorgenommen wurden, und gew\u00e4hrleistet die Atomarit\u00e4t und die Integrit\u00e4t der Daten im Falle eines Systemausfalls.<\/h4>\n

\nDas Protokoll enth\u00e4lt die Werte, die die Daten vor und nach der \u00c4nderung durch die Transaktion hatten. Die Write-ahead-Log-Strategie erfordert, dass vor Beginn der Transaktion die vorherigen Werte im Protokoll festgehalten werden, und nach Abschluss der Transaktion die Endwerte. Bei einem pl\u00f6tzlichen Systemabsturz liest die Datenbank das Protokoll in umgekehrter Reihenfolge und macht die von den Transaktionen vorgenommenen \u00c4nderungen r\u00fcckg\u00e4ngig. Wenn die Datenbank auf eine unterbrochene Transaktion st\u00f6\u00dft, f\u00fchrt sie diese aus und erg\u00e4nzt die \u00c4nderungen im Protokoll. Im Zustand zum Zeitpunkt des Absturzes liest die Datenbank das Protokoll in regul\u00e4rer Reihenfolge und stellt die von Transaktionen vorgenommenen \u00c4nderungen wieder her. Auf diese Weise wird die Integrit\u00e4t der bereits best\u00e4tigten Transaktionen und die Atomarit\u00e4t unterbrochener Transaktionen sichergestellt.<\/p>\n

Ein einfaches Wiederholen fehlgeschlagener Transaktionen reicht nicht aus, um die Wiederherstellung zu gew\u00e4hrleisten. <\/p>\n

Beispiel. Der Kontostand des Nutzers betr\u00e4gt 500 \u20ac, und der Nutzer entscheidet sich, Geld am Geldautomaten abzuheben. Es werden zwei Transaktionen ausgef\u00fchrt. Die erste liest den Kontostand, und wenn gen\u00fcgend Mittel vorhanden sind, gibt sie dem Nutzer das Geld aus. Die zweite zieht den entsprechenden Betrag vom Konto ab. Angenommen, es gab einen Systemfehler, und die erste Transaktion wurde nicht ausgef\u00fchrt, w\u00e4hrend die zweite erfolgreich war. In diesem Fall k\u00f6nnen wir dem Nutzer kein Geld erneut auszahlen, ohne das System in den urspr\u00fcnglichen Zustand mit einem positiven Kontostand zur\u00fcckzusetzen.<\/i><\/p>\n

Isolationsstufen<\/h2>\n

<\/p>\n

Lesen von festgelegten Daten (Read Committed)<\/h4>\n

\nDas Problem des schmutzigen Lesens (Dirty Read) besteht darin, dass eine Transaktion das Zwischenresultat einer anderen Transaktion lesen kann.<\/p>\n

Beispiel. Anfangswert des Kontostands 0 \u20ac. T1 f\u00fcgt 50 \u20ac zum Kontostand hinzu. T2 liest den Kontostand (50 \u20ac). T1 macht die \u00c4nderungen r\u00fcckg\u00e4ngig und wird beendet. T2 f\u00fchrt seine Verarbeitung mit falschen Kontostandsdaten fort.<\/i><\/p>\n

Die L\u00f6sung besteht darin, dass das Lesen von fixierten Daten (Read Committed) das Lesen von durch Transaktionen ge\u00e4nderten Daten verbietet. Wenn Transaktion A eine bestimmte Menge an Daten ge\u00e4ndert hat, muss Transaktion B, wenn sie auf diese Daten zugreifen m\u00f6chte, auf den Abschluss von Transaktion A warten.<\/p>\n

Wiederholtes Lesen (Repeatable Read)<\/h4>\n

\nDas Problem der verlorenen \u00c4nderungen (Lost Updates). T1 speichert \u00c4nderungen \u00fcber die \u00c4nderungen von T2.<\/p>\n

Beispiel. Anfangswert des Kontos 0 $ und zwei Transaktionen f\u00fcllen gleichzeitig das Konto auf. T1 und T2 lesen das Kontoguthaben, das 0 $ betr\u00e4gt. Dann f\u00fcgt T2 200 $ zu 0 $ hinzu und speichert das Ergebnis. T1 f\u00fcgt 100 $ zu 0 $ hinzu und speichert das Ergebnis. Das Endergebnis betr\u00e4gt 100 $ statt 300 $.<\/i><\/p>\n

Das Problem des nicht wiederholbaren Lesens (Unrepeatable Read). Ein erneutes Lesen derselben Daten gibt unterschiedliche Werte zur\u00fcck.<\/p>\n

Beispiel. T1 liest einen Kontostand von 0 $. Dann f\u00fcgt T2 50 $ zum Kontostand hinzu und wird abgeschlossen. T1 liest die Daten erneut und stellt fest, dass sie nicht mit dem vorherigen Ergebnis \u00fcbereinstimmen.<\/i><\/p>\n

Die wiederholbare Leseebene (Repeatable Read) gew\u00e4hrleistet, dass ein wiederholtes Lesen das gleiche Ergebnis zur\u00fcckgibt. Daten, die von einer Transaktion gelesen wurden, d\u00fcrfen von anderen bis zum Abschluss der Transaktion nicht ver\u00e4ndert werden. Wenn Transaktion A eine bestimmte Datens\u00e4tze liest, muss Transaktion B warten, bis Transaktion A abgeschlossen ist, um auf diese Daten zuzugreifen.<\/p>\n

Die serielle Lesebene (Serializable)<\/h4>\n

\nDas Problem des Phantomlesens (Phantom Reads). Zwei Abfragen, die Daten basierend auf einer Bedingung ausw\u00e4hlen, geben unterschiedliche Werte zur\u00fcck.<\/p>\n

Beispiel. T1 fragt die Anzahl aller Benutzer an, deren Kontostand \u00fcber 0 $ und unter 100 $ liegt. T2 zieht 1 $ von einem Benutzer mit einem Kontostand von 101 $ ab. T1 f\u00fchrt die Abfrage erneut aus.<\/i><\/p>\n

Serielle Lesebene (Serializable). Transaktionen werden als vollst\u00e4ndig sequenziell ausgef\u00fchrt. Das Aktualisieren und Hinzuf\u00fcgen von Datens\u00e4tzen, die unter die Abfragebedingungen fallen, ist untersagt. Wenn Transaktion A Daten der gesamten Tabelle angefordert hat, wird die gesamte Tabelle f\u00fcr andere Transaktionen bis zum Abschluss von Transaktion A gesperrt.<\/p>\n

Scheduler<\/h2>\n

<\/p>\n

Bestimmt die Reihenfolge, in der Operationen bei parallel ablaufenden Transaktionen ausgef\u00fchrt werden m\u00fcssen.<\/h4>\n

\nStellt ein festgelegtes Ma\u00df an Isolation sicher. Wenn das Ergebnis der Operationen nicht von deren Reihenfolge abh\u00e4ngt, sind solche Operationen kommutativ (Permutable). Leseoperationen und Operationen mit unterschiedlichen Daten sind kommutativ. Lese-Schreib-Operationen und Schreib-Schreib-Operationen sind nicht kommutativ. Die Aufgabe des Planers besteht darin, die von parallel ablaufenden Transaktionen durchgef\u00fchrten Operationen so abzuwechseln, dass das Ergebnis mit dem des sequenziellen Ablaufs der Transaktionen \u00fcbereinstimmt.<\/p>\n

Mechanismen zur Kontrolle paralleler Aufgaben (Concurrency Control)<\/h2>\n

<\/p>\n

Der optimistische Ansatz basiert auf der Erkennung und Behebung von Konflikten, w\u00e4hrend der pessimistische Ansatz darauf abzielt, Konflikte zu verhindern.<\/h4>\n

\nBeim optimistischen Ansatz erhalten mehrere Benutzer Kopien der Daten. Der erste, der die Bearbeitung abschlie\u00dft, speichert die \u00c4nderungen, w\u00e4hrend die anderen ihre \u00c4nderungen zusammenf\u00fchren m\u00fcssen. Der optimistische Algorithmus erlaubt einen Konflikt, aber das System muss sich nach dem Konflikt erholen.<\/p>\n

Bei einer pessimistischen Herangehensweise blockiert der erste Benutzer, der auf die Daten zugreift, anderen den Zugriff auf diese Daten. Wenn Konflikte selten sind, ist es sinnvoll, eine optimistische Strategie zu w\u00e4hlen, da diese ein h\u00f6heres Ma\u00df an Parallelit\u00e4t bietet.<\/p>\n

Sperrung (Locking)<\/h2>\n

<\/p>\n

Wenn eine Transaktion Daten sperrt, m\u00fcssen alle anderen Transaktionen, die auf diese Daten zugreifen m\u00f6chten, auf die Freigabe warten.<\/h4>\n

\nEine Sperre kann auf eine Datenbank, eine Tabelle, eine Zeile oder ein Attribut angewendet werden. Eine gemeinsame Sperre (Shared Lock) kann auf dieselben Daten von mehreren Transaktionen angewendet werden, erlaubt allen Transaktionen (einschlie\u00dflich der, die die Sperre gesetzt hat) das Lesen, verbietet jedoch \u00c4nderungen und exklusive Sperren. Eine exklusive Sperre (Exclusive Lock) kann nur von einer Transaktion gesetzt werden, erlaubt der sperrenden Transaktion alle Aktionen und verbietet allen anderen Transaktionen jegliche Aktionen.<\/p>\n

Eine Deadlock-Situation liegt vor, wenn Transaktionen in einem Zustand der Wartezeit feststecken, der unbegrenzt lange dauert.<\/h4>\n

\nBeispiel: Die erste Transaktion wartet auf die Freigabe von Daten, die von der zweiten Transaktion gesperrt sind, w\u00e4hrend die zweite Transaktion auf die Freigabe von Daten wartet, die von der ersten gesperrt sind.<\/i><\/p>\n

Die optimistische L\u00f6sung f\u00fcr das Deadlock-Problem erm\u00f6glicht das Auftreten von Deadlocks, stellt jedoch das System wieder her, indem eine der am Deadlock beteiligten Transaktionen zur\u00fcckgesetzt wird.<\/h4>\n

\nIn regelm\u00e4\u00dfigen Abst\u00e4nden wird nach Deadlocks gesucht. Ein Ansatz zur Erkennung besteht darin, die Ausf\u00fchrungszeit zu \u00fcberwachen und anzunehmen, dass ein Deadlock aufgetreten ist, wenn eine Transaktion zu lange dauert. Wenn ein Deadlock erkannt wird, wird eine der Transaktionen zur\u00fcckgesetzt, was anderen am Deadlock beteiligten Transaktionen erm\u00f6glicht, abzuschlie\u00dfen. Die Auswahl des Opfers kann auf den Kosten der Transaktionen oder deren Alter beruhen (Wait-Die und Wound-Wait-Strategien). <\/p>\n

Jeder Transaktion T<\/b> wird ein Zeitstempel TS<\/b> zugewiesen, der den Beginn der Transaktionsausf\u00fchrung enth\u00e4lt.<\/p>\n

Wait-Die. <\/p>\n

Wenn TS(Ti)<\/b> < TS(Tj)<\/b>, dann Ti<\/b> wartet, ansonsten Ti<\/b> wird zur\u00fcckgesetzt und beginnt neu mit demselben Zeitstempel.<\/u><\/p>\n

Wenn eine j\u00fcngere Transaktion eine Ressource erlangt hat und eine \u00e4ltere dieselbe Ressource anfordert, darf die \u00e4ltere Transaktion warten. Hat jedoch eine \u00e4ltere Transaktion eine Ressource erlangt, wird die j\u00fcngere Transaktion, die diese Ressource anfordert, zur\u00fcckgesetzt.<\/p>\n

Wound-Wait. <\/p>\n

Wenn TS(Ti)<\/b> < TS(Tj)<\/b>, dann Tj<\/b> rollt zur\u00fcck und beginnt erneut mit demselben Zeitstempel, andernfalls Ti<\/b> wartet.<\/u><\/p>\n

Wenn eine neuere Transaktion eine Ressource beansprucht hat und eine \u00e4ltere Transaktion dieselbe Ressource anfordert, wird die neuere Transaktion zur\u00fcckgerollt. Wenn eine \u00e4ltere Transaktion die Ressource beansprucht hat, darf die j\u00fcngere Transaktion, die diese Ressource anfordert, warten. Die Wahl des Opfers basierend auf dem Alter verhindert das Auftreten von Deadlocks, rollt jedoch Transaktionen zur\u00fcck, die sich nicht im Zustand des Deadlocks befinden. Das Problem besteht darin, dass Transaktionen mehrfach zur\u00fcckgerollt werden k\u00f6nnen, da eine \u00e4ltere Transaktion die Ressource lange halten kann.<\/p>\n

Eine pessimistische L\u00f6sung f\u00fcr das Deadlock-Problem erlaubt es einer Transaktion nicht, mit der Ausf\u00fchrung zu beginnen, wenn das Risiko eines Deadlocks besteht.<\/h4>\n

\nZur Erkennung von Deadlocks wird ein Graph (Wartegraph, wait-for-graph) erstellt, dessen Knoten Transaktionen darstellen. Die Kanten sind gerichtet von den Transaktionen, die auf die Freigabe von Daten warten, zu den Transaktionen, die diese Daten bereits erfasst haben. Ein Deadlock wird angenommen, wenn der Graph Zyklen aufweist. Der Aufbau des Wart \u0433\u0440\u0430\u0444\u0430, insbesondere in verteilten Datenbanken, ist ein kostenintensiver Prozess.<\/p>\n

Die Zwei-Phasen-Sperre verhindert Deadlocks, indem sie zu Beginn der Transaktion alle Ressourcen erfasst, die von der Transaktion ben\u00f6tigt werden, und sie am Ende wieder freigibt.<\/h4>\n

\nAlle sperrenden Operationen m\u00fcssen vor der ersten entsperrenden Operation durchgef\u00fchrt werden. Es gibt zwei Phasen: die Wachstumsphase (Growing Phase), in der die Sperren akkumuliert werden, und die Schrumpfungsphase (Shrinking Phase), in der die Sperren freigegeben werden. Wenn es nicht m\u00f6glich ist, eine der ben\u00f6tigten Ressourcen zu erfassen, beginnt die Transaktion von vorn. Es kann vorkommen, dass eine Transaktion die erforderlichen Ressourcen nicht erlangen kann, insbesondere wenn mehrere Transaktionen um dieselben Ressourcen konkurrieren.<\/p>\n

Das Zwei-Phasen-Commit gew\u00e4hrleistet die Ausf\u00fchrung des Commits auf allen Replikaten der Datenbank.<\/h4>\n

\nJede Datenbank protokolliert die Informationen \u00fcber die Daten, die ge\u00e4ndert werden sollen, im Log und best\u00e4tigt dem Koordinator mit OK (Voting-Phase). Nachdem alle mit OK geantwortet haben, sendet der Koordinator ein Signal, das alle verpflichtet, ein Commit durchzuf\u00fchren. Nach dem Commit Server<\/a> antworten mit OK; wenn auch nur einer nicht mit OK antwortet, sendet der Koordinator ein Signal zur Stornierung der \u00c4nderungen an alle Server (Completion-Phase).<\/p>\n

Methode der Zeitstempel<\/h2>\n

<\/p>\n

Eine \u00e4ltere Transaktion wird zur\u00fcckgesetzt, wenn versucht wird, auf Daten zuzugreifen, die von einer neueren Transaktion verwendet werden.<\/h4>\n

\nJeder Transaktion wird ein Zeitstempel zugewiesen TS<\/b> der dem Zeitpunkt des Beginns der Ausf\u00fchrung entspricht. Wenn Ti<\/b> \u00e4lter Tj<\/b>, dann TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Wenn eine Transaktion zur\u00fcckgesetzt wird, erh\u00e4lt sie einen neuen Zeitstempel. Jedes Datenobjekt Q<\/b> das von der Transaktion verwendet wird, wird mit zwei Zeitstempeln versehen. W-TS(Q)<\/b> \u2014 der Zeitstempel der j\u00fcngsten Transaktion, die erfolgreich einen Schreibvorgang \u00fcber Q<\/b>. R-TS(Q)<\/b> \u2014 der Zeitstempel der j\u00fcngsten Transaktion, die einen Lesevorgang \u00fcber Q<\/b>.<\/p>\n

Wenn eine Transaktion T<\/b> eine Anfrage zum Lesen von Daten stellt, Q<\/b> gibt es zwei M\u00f6glichkeiten.<\/p>\n

Wenn TS(T)<\/b> < W-TS(Q)<\/b>, das hei\u00dft, die Daten wurden durch eine j\u00fcngere Transaktion aktualisiert, dann wird die Transaktion T<\/b> zur\u00fcckgesetzt.<\/u><\/p>\n

Wenn TS(T)<\/b> >= W-TS(Q)<\/b>, dann wird das Lesen ausgef\u00fchrt und R-TS(Q)<\/b> wird MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Wenn eine Transaktion T<\/b> fordert eine \u00c4nderung der Daten an Q<\/b> gibt es zwei M\u00f6glichkeiten. <\/p>\n

Wenn TS(T)<\/b> < R-TS(Q)<\/b>, das bedeutet, dass die Daten bereits von einer j\u00fcngeren Transaktion gelesen wurden und eine \u00c4nderung zu einem Konflikt f\u00fchren w\u00fcrde. Die Transaktion T<\/b> zur\u00fcckgesetzt. <\/u><\/p>\n

Wenn TS(T)<\/b> < W-TS(Q)<\/b>, das bedeutet, dass die Transaktion versucht, einen neueren Wert zu \u00fcberschreiben, wodurch die Transaktion T zur\u00fcckgerollt wird. In anderen F\u00e4llen wird die \u00c4nderung erfolgreich durchgef\u00fchrt und W-TS(Q)<\/b> wird gleich TS(T)<\/b>.<\/u><\/p>\n

Es ist kein kostspieliger Aufbau eines Abh\u00e4ngigkeitsgraphen erforderlich. \u00c4ltere Transaktionen h\u00e4ngen von neueren ab, daher gibt es keine Zyklen im Warteschlangengraphen. Es gibt keine Deadlocks, da die Transaktionen nicht warten, sondern sofort zur\u00fcckgerollt werden. Kaskadierende Rollbacks sind m\u00f6glich. Wenn Ti<\/b> zur\u00fcckgerollt wurde, und Tj<\/b> Daten gelesen wurden, die ge\u00e4ndert wurden Ti<\/b>, dann Tj<\/b> muss ebenfalls zur\u00fcckgerollt werden. Wenn dabei Tj<\/b> schon festgeschrieben wurde, verletzt dies das Prinzip der Konsistenz.<\/p>\n

Eine der L\u00f6sungen f\u00fcr kaskadierende Rollbacks. Die Transaktion f\u00fchrt alle Schreiboperationen am Ende durch, wobei andere Transaktionen auf den Abschluss dieser Operation warten m\u00fcssen. Transaktionen warten auf das Commit, bevor sie lesen.<\/p>\n

Die Thomas-Schreibregel \u2013 eine Variante des Zeitstempelverfahrens, bei dem Daten, die von einer j\u00fcngeren Transaktion aktualisiert wurden, nicht von einer \u00e4lteren zur\u00fcckgeschrieben werden d\u00fcrfen.<\/h4>\n

\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30878","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Transaktionen und ihre Kontrollmechanismen | ProHoster","description":"Eine Transaktion ist eine Abfolge von Operationen \u00fcber Daten, die einen Anfang und ein Ende hat. Eine Transaktion umfasst die sequenzielle Ausf\u00fchrung von Lese- und Schreiboperationen. Das Ende einer Transaktion kann entweder das Speichern von \u00c4nderungen (Commit) oder das R\u00fcckg\u00e4ngigmachen von \u00c4nderungen (Rollback) sein. Im Zusammenhang mit Datenbanken ist eine Transaktion eine Gruppe von Anfragen, die als eine einzige Anfrage betrachtet wird. Transaktionen m\u00fcssen die ACID-Eigenschaften erf\u00fcllen: Atomarit\u00e4t. Eine Transaktion wird entweder vollst\u00e4ndig ausgef\u00fchrt.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0438 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0438\u0445 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f | ProHoster","og:description":"\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:56+00:00","article:modified_time":"2019-10-31T18:37:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:38","updated":"2026-02-22 15:31:13"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nTransaktion T<\/b> fordert eine \u00c4nderung der Daten an Q<\/b>useString TS(T)<\/b> < W-TS(Q)<\/b>, das hei\u00dft, die Transaktion versucht, einen neueren Wert zu \u00fcberschreiben. Die Transaktion T wird nicht wie beim Zeitstempel zur\u00fcckgesetzt.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"