Ich frage mich nur, was passiert, wenn Sie eine Transaktion in einer Datenbank beginnen und vergessen haben, sie festzuschreiben oder zurückzusetzen. Fällt der Server aus? Nehmen wir an, Sie haben es 3 Tage lang liegen lassen.
Es gibt auch Benutzer, die davon ausgehen, dass die anderen Benutzer nicht wissen, dass eine nicht abgeschlossene Transaktion vorliegt (nehmen wir nur an, dass die Benutzer nur Daten in die Datenbank einfügen). Was sind die Konsequenzen dieser Aktion?
Antworten:
Eine offene Transaktion für sich allein hat fast keine Konsequenzen. Eine einfache
BEGIN TRANSACTION
-- wait for a while, doing nothing
-- wait a bit longer
COMMITenthält im schlimmsten Fall einige Bytes an Statuswerten. Keine große Sache.
Die meisten Programme erledigen die eigentliche Arbeit innerhalb der Transaktion, und dies ist eine andere Sache. Der Sinn einer Transaktion ist, dass Sie sicher sein können, dass mehrere Fakten in der Datenbank gleichzeitig wahr sind, obwohl andere Benutzer gleichzeitig in dieselbe Datenbank schreiben.
Nehmen Sie das kanonische Beispiel des Geldtransfers zwischen Bankkonten. Das System muss sicherstellen, dass das Quellkonto vorhanden ist, über ausreichende Mittel verfügt, dass das Zielkonto vorhanden ist und dass sowohl Lastschrift als auch Gutschrift erfolgen oder beides nicht erfolgt. Es muss dies garantieren, während andere Transaktionen stattfinden, vielleicht sogar zwischen diesen beiden Konten. Das System stellt dies sicher, indem es die betreffenden Tabellen sperrt . Welche Schlösser genommen werden, und wie viel von anderen Leuten Arbeit , die Sie sehen, wird durch die Transaktion gesteuert Isolationsstufe .
Wenn Sie also viel arbeiten, besteht eine gute Chance, dass andere Transaktionen in die Warteschlange gestellt werden und auf die Objekte warten, für die Sie Sperren haben. Dies verringert den Gesamtdurchsatz des Systems. Irgendwann stoßen sie an Zeitlimits und versagen, was ein Problem für das gesamte Systemverhalten darstellt. Wenn Sie eine optimistische Isolationsstufe verwenden, schlägt Ihre Transaktion möglicherweise fehl, wenn Sie ein Commit aufgrund der Arbeit anderer ausführen.
Das Halten von Sperren beansprucht Systemressourcen. Dies ist der Speicher, den das System nicht zum Verarbeiten anderer Anforderungen verwenden kann, wodurch der Durchsatz verringert wird.
Wenn eine Menge Arbeit hat sich das System durchgeführt wurde kann wählen auszuführen Sperreneskalation . Anstatt einzelne Zeilen zu sperren, wird die gesamte Tabelle gesperrt. Dann sind mehr gleichzeitige Benutzer betroffen, der Systemdurchsatz sinkt weiter und die Auswirkungen auf die Anwendung sind größer.
Datenänderungen werden in die Protokolldatei geschrieben, ebenso wie die Sperren, die sie schützen. Diese können erst aus dem Protokoll gelöscht werden, wenn die Transaktion festgeschrieben wurde. Daher kann eine sehr lange Transaktion dazu führen, dass die Protokolldatei mit den damit verbundenen Problemen aufgebläht wird.
Wenn die aktuelle Arbeit Tempdb verwendet, was für große Arbeitslasten wahrscheinlich ist, sind die Ressourcen dort möglicherweise bis zum Ende der Transaktion gebunden. In extremen Fällen kann dies dazu führen, dass andere Aufgaben fehlschlagen, da nicht mehr genügend Platz für sie vorhanden ist. Ich hatte Fälle, in denen ein schlecht codiertes UPDATE Tempdb füllte, so dass nicht genügend Speicherplatz für die SORT eines Berichts vorhanden war und der Bericht fehlschlug.
Wenn Sie die Transaktion ROLLBACKEN oder das System ausfällt und sich erholt, hängt die Zeit, die das System benötigt, um wieder verfügbar zu sein, davon ab, wie viel Arbeit geleistet wurde. Das Öffnen einer Transaktion wirkt sich nicht auf die Wiederherstellungszeit aus, sondern darauf, wie viel Arbeit geleistet wurde. Wenn die Transaktion offen war, aber eine Stunde lang inaktiv war, erfolgt die Wiederherstellung fast augenblicklich. Wenn für diese Stunde konstant geschrieben wurde, gilt als Faustregel, dass die Erholungszeit ebenfalls etwa eine Stunde beträgt.
Wie Sie sehen können, kann eine lange Transaktion problematisch sein. Bei OLTP-Systemen empfiehlt es sich, eine Datenbanktransaktion pro Geschäftstransaktion durchzuführen. Für die Eingabe von Batch-Workprozessen in Blöcken mit häufigen Festschreibungen und Neustartlogik. Normalerweise können mehrere tausend Datensätze in einer einzelnen DB-Transaktion verarbeitet werden. Dies sollte jedoch auf Parallelität und Ressourcenverbrauch überprüft werden.
Seien Sie nicht versucht, in die andere Richtung zu gehen und Transaktionen und Sperren gänzlich zu vermeiden. Wenn Sie die Konsistenz Ihrer Daten gewährleisten müssen (und warum sollten Sie sonst eine Datenbank verwenden?), Erfüllen Isolationsstufen und Transaktionen einen sehr wichtigen Zweck. Erfahren Sie mehr über Ihre Optionen und entscheiden Sie, mit welchem Gleichgewicht von Nebenläufigkeit und Korrektheit Sie für jeden Teil Ihrer Anwendung leben möchten.
Ihre größte Konsequenz ist das Sperren der in der Transaktion verwendeten Objekte. Insbesondere wenn Sie davon ausgehen, dass Ihre Benutzer Daten einfügen, kann diese lang laufende Transaktion SELECT-Anweisungen für häufig verwendete Tabellen enthalten. Die Aktualisierungsanweisungen Ihrer Benutzer erhalten möglicherweise nicht die erforderliche Sperre, um die Aktualisierungen oder Einfügungen abzuschließen.
Eine sekundäre Sache, die passieren könnte, ist die Protokolldateiaktivität. Wenn Sie beispielsweise ein großes Dataset aktualisieren, bleibt der Teil des Protokolls, den die Transaktion verwendet, für die Dauer dieser Transaktion aktiv. Sie können diesen Teil des Protokolls erst wieder verwenden, wenn die Transaktion festgeschrieben oder zurückgesetzt wurde. In Szenarien, in denen Sie sich möglicherweise in einem stark aktiven OLTP-System befinden, kann dies dazu führen, dass Ihre Protokolldatei schnell wächst und Ihr Speichergerät voll wird.
Eine unvollständige Transaktion kann eine große Anzahl von Sperren enthalten und zum Blockieren führen
Wenn eine Transaktion nicht abgeschlossen wird, weil eine Abfrage das Zeitlimit überschreitet oder weil der Stapel mitten in einer Transaktion abgebrochen wird, ohne dass eine COMMIT- oder ROLLBACK-Anweisung zum Abschließen der Transaktion ausgegeben wird, bleibt die Transaktion offen, und alle während dieser Transaktion erlangten Sperren werden fortgesetzt gehalten werden. Nachfolgende Transaktionen, die unter derselben Verbindung ausgeführt werden, werden als verschachtelte Transaktionen behandelt, sodass nicht alle in diesen abgeschlossenen Transaktionen erworbenen Sperren freigegeben werden. Dieses Problem wiederholt sich mit allen Transaktionen, die über dieselbe Verbindung ausgeführt werden, bis ein ROLLBACK ausgeführt wird. Infolgedessen wird eine große Anzahl von Sperren aufrechterhalten, Benutzer werden blockiert und Transaktionen gehen verloren, was zu Daten führt, die sich von Ihren Erwartungen unterscheiden.