Ich bin wirklich verwirrt darüber, wie man die Tatsache verdaut, dass eine Transaktion atomar ist. Wenn eine Transaktion aus „Abfragen“ besteht, wie wird sie dann atomar sein? Ich beziehe das Wort „Abfragen“ auf eine allgemeine SQL-Abfrage. Daher wird eine Transaktion nur zu einer Reihe von SQL-Abfragen, die gleichzeitig ausgeführt werden. Aber die Tatsache, dass jede Abfrage mehrere Operationen, ich verstehe wirklich nicht, wie die zuvor ausgeführten Abfragen (in der gleichen Menge) zurückgesetzt werden, wenn ein Fehler in einer späteren Abfrage auftritt. Was fehlt mir hier? Vielen Dank!
Antwort
TL; DR; Das Transaktionsprotokoll enthält alle Informationen, die zum erneuten Erstellen oder Rückgängigmachen jeder Transaktion erforderlich sind, je nachdem, ob es einen Festschreibungsdatensatz für diese Transaktion enthält oder nicht.
In SQL-Datenbanken wird die Transaktionsatomizität am häufigsten mithilfe von implementiert Write-Ahead-Protokollierung (dh die Transaktionsprotokolleinträge werden geschrieben, bevor die tatsächlichen Tabellen und Indizes aktualisiert werden).
Abfragen im engeren Sinne des Wortes, d. h. SELECT Anweisungen und andere Lesevorgänge, die den Datenbankstatus nicht ändern, werden nicht protokolliert, da nichts festgeschrieben oder zurückgesetzt werden muss, und als solches gilt das Konzept der Atomizität hier nicht wirklich. zumindest auf DBMS-Ebene. Die anwendungsintensiven Abfrageergebnisse müssen möglicherweise die Atomizität erzwingen, indem die Ergebnisse früherer Abfragen verworfen werden, wenn eine der nachfolgenden Abfragen fehlschlägt und das Rollback verursacht.
Wenn DML-Anweisungen (INSERT, UPDATE, DELETE, MERGE) und andere Anweisungen, die den Datenbankstatus ändern, erhalten Bei der Ausführung werden die vorgenommenen Änderungen zuerst in das Write-Ahead-Protokoll (WAL) geschrieben. Wenn alle Anweisungen erfolgreich sind und ein Commit (explizit oder implizit) ausgegeben wird, wird diese Tatsache auch in der WAL aufgezeichnet und das Protokoll wird beibehalten. Dies macht die Änderungen dauerhaft. Sie können zu einem späteren Zeitpunkt während eines Prüfpunkts oder einer Protokollwiedergabe in die tatsächlichen Tabellen- und Indexsegmente geschrieben werden.
Wenn jedoch eine der Anweisungen fehlschlägt, enthält das Protokoll keinen Festschreibungsdatensatz für Diese Transaktion und das DBMS machen Tabellen- und Indexänderungen rückgängig, die bisher unter Verwendung der vorhergehenden Protokolldatensätze dieser Transaktion vorgenommen wurden.
Wenn der DBMS-Prozess abstürzt oder der Strom ausfällt, ist dies ebenfalls nicht der Fall Ein Festschreibungsdatensatz für die Transaktion während des Flugs und die Tabellen- oder Indexänderungen, die möglicherweise bereits beibehalten wurden, werden während der Protokollwiedergabe rückgängig gemacht.
Kommentare
- Dies ist nicht ' nicht korrekt: " Abfragen im engeren Sinne des Wortes, dh SELECT-Anweisungen und andere Leseoperationen die den Datenbankstatus nicht ändern, werden nicht protokolliert, da nichts festgeschrieben oder zurückgesetzt werden muss " – abhängig von Ihren Datenbankeinstellungen kann sogar ein SELECT einen impliziten tr starten ansaction. brentozar.com/archive/2018/02/…
- I ' Ich sage nicht, dass sie ' nicht unter Transaktionskontrolle stehen. Ich ' sage das, da sie es sind Sie ändern nichts, sie werden nicht protokolliert.
Antwort
Eine Transaktion ist atomar, wenn sie wie eingekapselt ist dies:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT In diesem Fall werden beide Aktualisierungen in den beiden separaten Tabellen zusammen festgeschrieben oder sie werden zusammen zurückgesetzt (fehlgeschlagen). Atomizität bedeutet Dies ist die kleinste Einheit einer Transaktion, die festgeschrieben wird.
Wenn Sie jedoch später versuchen, eine separate Abfrage außerhalb dieses Bereichs auszuführen, handelt es sich um eine separate Transaktion.
Wenn Sie Folgendes versuchen:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; In Ihrer Anwendung führen Sie dann andere Arbeiten aus, z. B. C # -Code, und kehren dann zur Datenbank zurück später und tun Sie dies:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Dann sind sowohl das frühere Benutzer-Update als auch das nachfolgende Posts-Update erfolgreich oder scheitern zusammen.
Im wirklichen Leben können Sie eine Transaktion jedoch nicht wie folgt offen halten das für einen längeren Zeitraum, weil Sie andere Personen daran hindern, in der Datenbank zu arbeiten. Aus diesem Grund werden Sie häufig Ratschläge wie „Halten Sie Ihre Transaktion kurz und bündig“ erhalten, dh einsteigen, Ihre Arbeit erledigen und wieder aussteigen. Halten Sie Transaktionen nicht explizit offen.
Kommentare
- Eine Transaktion ist immer atomar, nicht ' nicht wahr?
- Ja, aber abhängig von Ihren Datenbankeinstellungen sind möglicherweise implizite Transaktionen aktiviert. Dies bedeutet, dass Sie ' sind Sie erhalten ein BEGIN TRAN, auch wenn Sie nicht ' danach fragen. Dies variiert je nach Anbieter. Ich höre beispielsweise, dass Oracle standardmäßig implizite Transaktionen verwendet, SQL Server jedoch nicht.Sie könnten denken, dass Sie ' nur eine Transaktion erhalten, wenn Sie aus einem Oracle-Hintergrund stammen, wenn Sie möglicherweise mehrere verschiedene Transaktionen in SQL Server erhalten – jede davon wäre atomar.