{"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 ist eine Abfolge von Datenoperationen, die einen Anfang und ein Ende hat.<\/h4>\n

\nEine Transaktion ist die sequenzielle Ausf\u00fchrung von Lese- und Schreiboperationen. Das Ende einer Transaktion kann entweder das Speichern von \u00c4nderungen (Commit) oder das Zur\u00fccksetzen der \u00c4nderungen (Rollback) sein. Im Hinblick auf Datenbanken bedeutet eine Transaktion mehrere Anfragen, die als eine einzige Anfrage behandelt werden.<\/p>\n

Transaktionen m\u00fcssen die ACID-Eigenschaften erf\u00fcllen.<\/h4>\n

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

Konsistenz. Bei Abschluss der Transaktion d\u00fcrfen die Datenbeschr\u00e4nkungen (z. B. Constraints in der DB) nicht verletzt werden. Konsistenz bedeutet, dass das System von einem konsistenten Zustand in einen anderen \u00fcberf\u00fchrt wird.<\/p>\n

Isolierung. Parallel ausgef\u00fchrte Transaktionen d\u00fcrfen sich nicht gegenseitig beeinflussen, z. B. keine Daten \u00e4ndern, die eine andere Transaktion verwendet. Das Ergebnis der parallelen Transaktionen sollte so sein, als w\u00e4ren die Transaktionen sequenziell ausgef\u00fchrt worden.<\/p>\n

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

Transaktionsprotokoll<\/h2>\n

<\/p>\n

Das Protokoll speichert \u00c4nderungen, die durch Transaktionen vorgenommen werden, und gew\u00e4hrleistet die Atomarit\u00e4t und Best\u00e4ndigkeit 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 verlangt, dass fr\u00fchere Werte vor Beginn der Transaktion und die Endwerte nach Abschluss der Transaktion im Protokoll festgehalten werden. Im Fall eines pl\u00f6tzlichen Systemstopps liest die Datenbank das Protokoll in umgekehrter Reihenfolge und macht die von den Transaktionen vorgenommenen \u00c4nderungen r\u00fcckg\u00e4ngig. Bei einer unterbrochenen Transaktion f\u00fchrt die Datenbank diese aus und dokumentiert die \u00c4nderungen im Protokoll. Im Zustand zum Zeitpunkt des Ausfalls liest die Datenbank das Protokoll in normaler Reihenfolge und stellt die von den Transaktionen vorgenommenen \u00c4nderungen wieder her. So wird die Best\u00e4ndigkeit von bereits durchgef\u00fchrten Transaktionen und die Atomarit\u00e4t der unterbrochenen Transaktion gew\u00e4hrleistet.<\/p>\n

Einfaches Wiederholen fehlerhafter Transaktionen reicht nicht aus, um eine Wiederherstellung zu erreichen. <\/p>\n

Beispiel. Der Benutzer hat 500$ auf dem Konto und entscheidet, diese \u00fcber einen Geldautomaten abzuheben. Es werden zwei Transaktionen durchgef\u00fchrt. Die erste liest den Kontostand und gibt Geld aus, wenn gen\u00fcgend Mittel vorhanden sind. Die zweite zieht den ben\u00f6tigten Betrag vom Kontostand ab. Angenommen, es kam zu einem Systemfehler und die erste Transaktion wurde nicht ausgef\u00fchrt, w\u00e4hrend die zweite erfolgreich war. In diesem Fall k\u00f6nnen wir dem Benutzer kein Geld erneut geben, ohne das System in den urspr\u00fcnglichen Zustand mit einem positiven Kontostand zur\u00fcckzuf\u00fchren.<\/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 ein Zwischenergebnis einer anderen Transaktion lesen kann.<\/p>\n

Beispiel. Der Anfangsstand betr\u00e4gt 0$. T1 f\u00fcgt 50$ zum Stand hinzu. T2 liest den Stand (50$). T1 macht die \u00c4nderungen r\u00fcckg\u00e4ngig und wird abgeschlossen. T2 f\u00fchrt mit falschen Daten zum Stand fort.<\/i><\/p>\n

Die L\u00f6sung besteht darin, festgelegte Daten (Read Committed) zu lesen, die das Lesen von durch die Transaktion ge\u00e4nderten Daten verhindern. Wenn Transaktion A einen bestimmten Datensatz ge\u00e4ndert hat, muss Transaktion B warten, bis Transaktion A abgeschlossen ist, um auf diese Daten zuzugreifen.<\/p>\n

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

\nDas Problem verlorener \u00c4nderungen (Lost Updates). T1 speichert \u00c4nderungen \u00fcber den \u00c4nderungen von T2.<\/p>\n

Beispiel. Der Anfangsstand betr\u00e4gt 0$ und zwei Transaktionen f\u00fcgen gleichzeitig zum Stand hinzu. T1 und T2 lesen den Stand als 0$. 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$ anstelle von 300$.<\/i><\/p>\n

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

Beispiel. T1 liest einen Kontostand von 0$. Dann f\u00fcgt T2 50$ hinzu und wird abgeschlossen. T1 liest die Daten erneut und bemerkt eine Diskrepanz zum vorherigen Ergebnis.<\/i><\/p>\n

Wiederholtes Lesen (Repeatable Read) garantiert, dass ein erneutes Lesen dasselbe Ergebnis zur\u00fcckgibt. Daten, die von einer Transaktion gelesen wurden, d\u00fcrfen bis zum Abschluss der Transaktion nicht von anderen ge\u00e4ndert werden. Wenn Transaktion A einen bestimmten Datensatz gelesen hat, muss Transaktion B warten, bis Transaktion A abgeschlossen ist, um auf diese Daten zuzugreifen.<\/p>\n

Sortiertes Lesen (Serializable)<\/h4>\n

\nDas Problem des Phantomlesens (Phantom Reads). Zwei Abfragen, die Daten aufgrund einer bestimmten Bedingung abrufen, geben unterschiedliche Werte zur\u00fcck.<\/p>\n

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

Ordnungsgem\u00e4\u00dfes Lesen (Serializable). Transaktionen werden als vollkommen sequenziell ausgef\u00fchrt. Es ist verboten, Datens\u00e4tze zu aktualisieren und hinzuzuf\u00fcgen, die unter die Bedingungen der Abfrage fallen. Wenn Transaktion A die Daten der gesamten Tabelle angefragt hat, wird die Tabelle f\u00fcr die anderen Transaktionen bis zum Abschluss von Transaktion A vollst\u00e4ndig eingefroren.<\/p>\n

Planer (Scheduler)<\/h2>\n

<\/p>\n

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

\nStellt ein festgelegtes Ma\u00df an Isolation sicher. Wenn das Ergebnis der Ausf\u00fchrung der Operationen nicht von ihrer Reihenfolge abh\u00e4ngt, sind solche Operationen kommutativ (Permutable). Leseoperationen und Operationen an verschiedenen Daten sind kommutativ. Lese-Schreib-Operationen und Schreib-Schreib-Operationen sind nicht kommutativ. Die Aufgabe des Planers besteht darin, die Operationen, die von parallelen Transaktionen ausgef\u00fchrt werden, so abwechselnd zu gestalten, dass das Ergebnis der Ausf\u00fchrung \u00e4quivalent zu einer sequenziellen Ausf\u00fchrung der Transaktionen ist.<\/p>\n

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

<\/p>\n

Optimistisch basierend auf der Erkennung und Behebung von Konflikten, pessimistisch auf der Verhinderung von Konflikten.<\/h4>\n

\nBeim optimistischen Ansatz erhalten mehrere Benutzer Kopien der Daten. Der erste, der die Bearbeitung abschlie\u00dft, speichert die \u00c4nderungen, die anderen m\u00fcssen dann eine Zusammenf\u00fchrung der \u00c4nderungen vornehmen. Der optimistische Algorithmus erm\u00f6glicht das Entstehen von Konflikten, aber das System muss sich nach dem Konflikt erholen.<\/p>\n

Beim pessimistischen Ansatz verhindert der erste Benutzer, der die Daten erfasst hat, dass andere die Daten erhalten. Wenn Konflikte selten auftreten, ist es sinnvoll, eine optimistische Strategie zu w\u00e4hlen, da sie ein h\u00f6heres Ma\u00df an Parallelit\u00e4t gew\u00e4hrleistet.<\/p>\n

Sperrung (Locking)<\/h2>\n

<\/p>\n

Wenn eine Transaktion die Daten sperrt, m\u00fcssen die anderen Transaktionen beim Zugriff auf die Daten auf die Freigabe warten.<\/h4>\n

\nEin Block kann auf eine Datenbank, eine Tabelle, eine Reihe oder ein Attribut angewendet werden. Ein Shared Lock kann auf dieselben Daten von mehreren Transaktionen angewendet werden, erlaubt allen Transaktionen (einschlie\u00dflich der anwendenden) das Lesen, verbietet jedoch \u00c4nderungen und exklusiven Zugriff. Ein Exclusive Lock kann nur von einer Transaktion angewendet werden, erlaubt alle Aktionen der anwendenden Transaktion und verbietet alle Aktionen der anderen.<\/p>\n

Als Deadlock bezeichnet man eine Situation, in der Transaktionen in einem Zustand des Wartens feststecken, der unendlich lange dauert.<\/h4>\n

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

Eine optimistische L\u00f6sung des Deadlock-Problems erm\u00f6glicht es, dass ein Deadlock auftritt, stellt jedoch das System wieder her, indem eine der Transaktionen, die an dem Deadlock beteiligt sind, zur\u00fcckgesetzt wird.<\/h4>\n

\nIn bestimmten Zeitabst\u00e4nden wird nach Deadlocks gesucht. Eine der M\u00f6glichkeiten zur Erkennung ist die Zeit: Man betrachtet eine Situation als Deadlock, wenn eine Transaktion zu lange ausgef\u00fchrt wird. Wenn ein Deadlock erkannt wird, wird eine der Transaktionen zur\u00fcckgesetzt, was es den anderen Transaktionen, die am Deadlock beteiligt sind, erm\u00f6glicht, abzuschlie\u00dfen. Die Wahl des Opfers kann auf den Kosten der Transaktionen oder ihrem Alter basieren (Wait-Die- und Wound-Wait-Schemata). <\/p>\n

Jeder Transaktion T<\/b> wird ein Zeitstempel zugewiesen TS<\/b> der die Startzeit der Ausf\u00fchrung der Transaktion enth\u00e4lt.<\/p>\n

Wait-Die. <\/p>\n

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

Wenn eine junge Transaktion eine Ressource erfasst hat und eine \u00e4ltere dieselbe Ressource anfordert, darf die \u00e4ltere Transaktion warten. Wenn die \u00e4ltere Transaktion eine Ressource erfasst hat, wird die junge Transaktion, die diese Ressource anfordert, zur\u00fcckgesetzt.<\/p>\n

Wound-Wait. <\/p>\n

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

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

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

\nZur Erkennung von Deadlocks wird ein Diagramm (Wartegraf, wait-for-graph) erstellt, dessen Knoten Transaktionen sind und dessen Kanten von Transaktionen, die auf die Freigabe von Daten warten, zu der Transaktion f\u00fchren, die diese Daten erfasst hat. Es wird angenommen, dass ein Deadlock aufgetreten ist, wenn das Diagramm eine Zyklenbildung aufweist. Der Aufbau des Wartediagramms, insbesondere in verteilten Datenbanken, ist ein kostspieliger Prozess.<\/p>\n

Zwei-Phasen-Sperre \u2014 Vermeidung von Deadlocks durch Erfassung aller Ressourcen, die von einer Transaktion zu Beginn der Transaktion verwendet werden, und Freigabe dieser Ressourcen am Ende.<\/h4>\n

\nAlle sperrenden Operationen m\u00fcssen der ersten freigebenden Operation vorausgehen. Es gibt zwei Phasen \u2014 die Wachstumsphase, in der Ressourcen erfasst werden, und die Schrumpfungsphase, in der Ressourcen freigegeben werden. Wenn es nicht m\u00f6glich ist, eine der Ressourcen zu erfassen, beginnt die Transaktion neu. Es kann vorkommen, dass eine Transaktion die ben\u00f6tigten Ressourcen nicht erfassen kann, zum Beispiel wenn mehrere Transaktionen um dieselben Ressourcen konkurrieren.<\/p>\n

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

\nJede Datenbank f\u00fcgt Informationen \u00fcber die Daten, die ge\u00e4ndert werden sollen, in das Protokoll ein und antwortet dem Koordinator mit OK (Voting Phase). Nachdem alle mit OK geantwortet haben, sendet der Koordinator ein Signal, das alle verpflichtet, den Commit durchzuf\u00fchren. Nach dem Commit Server<\/a> antworten sie mit OK; wenn auch nur einer nicht mit OK geantwortet hat, sendet der Koordinator ein Signal zum Abbrechen der \u00c4nderungen an alle Server (Completion Phase).<\/p>\n

Methode der Zeitstempel.<\/h2>\n

<\/p>\n

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

\nJedem Transaktion wird ein Zeitstempel zugewiesen TS<\/b> der dem Beginn 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 durch die Transaktion betroffen ist, wird mit zwei Zeitstempeln markiert. W-TS(Q)<\/b> \u2014 der Zeitstempel der j\u00fcngsten Transaktion, die 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 die Transaktion T<\/b> eine Datenleseanfrage stellt, Q<\/b> gibt es zwei M\u00f6glichkeiten.<\/p>\n

Wenn TS(T)<\/b> < W-TS(Q)<\/b>, das hei\u00dft, die Daten wurden von einer j\u00fcngeren Transaktion aktualisiert, dann wird die Transaktion T<\/b> r\u00fcckgesetzt.<\/u><\/p>\n

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

Wenn die Transaktion T<\/b> eine Daten\u00e4nderung anfragt, Q<\/b> gibt es zwei M\u00f6glichkeiten. <\/p>\n

Wenn TS(T)<\/b> < R-TS(Q)<\/b>, das hei\u00dft, die Daten wurden bereits von einer j\u00fcngeren Transaktion gelesen und wenn die \u00c4nderung durchgef\u00fchrt wird, entsteht ein Konflikt. Die Transaktion T<\/b> r\u00fcckgesetzt. <\/u><\/p>\n

Wenn TS(T)<\/b> < W-TS(Q)<\/b>, das hei\u00dft, die Transaktion versucht, einen neueren Wert zu \u00fcberschreiben, wird die Transaktion T zur\u00fcckgesetzt. In anderen F\u00e4llen wird die \u00c4nderung vorgenommen und W-TS(Q)<\/b> wird gleich TS(T)<\/b>.<\/u><\/p>\n

Es ist kein kostspieliger Aufbau eines Wartegraphen erforderlich. \u00c4ltere Transaktionen sind von neueren abh\u00e4ngig, daher gibt es im Wartegraphen keine Zyklen. Es gibt keine Deadlocks, da Transaktionen nicht warten, sondern sofort zur\u00fcckgesetzt werden. Kaskadierende R\u00fccksetzungen sind m\u00f6glich. Wenn Ti<\/b> zur\u00fcckgesetzt wurde, und Tj<\/b> Daten gelesen hat, die sie ge\u00e4ndert hat, Ti<\/b>, dann Tj<\/b> muss auch zur\u00fcckgesetzt werden. Wenn dies der Fall ist, Tj<\/b> bereits festgeschrieben wurde, f\u00fchrt dies zu einem Versto\u00df gegen das Stabilit\u00e4tsprinzip.<\/p>\n

Eine der L\u00f6sungen f\u00fcr kaskadierende R\u00fccksetzungen. Die Transaktion f\u00fchrt alle Schreibvorg\u00e4nge am Ende durch, und die anderen Transaktionen m\u00fcssen auf den Abschluss dieser Operation warten. Transaktionen warten auf das Commit, bevor sie lesen.<\/p>\n

Thomas-Schreibregel \u2014 eine Variation der Zeitstempel-Methode, bei der Daten, die von einer j\u00fcngeren Transaktion aktualisiert wurden, nicht von einer \u00e4lteren \u00fcberschrieben 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":"Transaktionen Eine Transaktion ist eine Abfolge von Operationen \u00fcber Daten, die einen Anfang und ein Ende hat. Eine Transaktion ist die sequenzielle Ausf\u00fchrung von Lese- und Schreibvorg\u00e4ngen.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}

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