Was macht eine Transaktion um eine einzelne Anweisung?

Question

Ich verstehe, wie eine Transaktion nützlich sein kann, um ein Paar von Updates zu koordinieren. Was ich nicht verstehe, ist das Umbrechen einzelner Anweisungen in Transaktionen, was 90% von dem ist, was ich je gesehen habe. Tatsächlich ist es im realen Code nach meiner Erfahrung üblich, eine Reihe von logisch zusammenhängenden Transaktionen zu finden, die jeweils in ihre eigene Transaktion eingeschlossen sind, aber das Ganze ist nicht in eine Transaktion eingeschlossen.

Gibt es in MS-SQL einen Vorteil, wenn einzelne Auswahlen, einzelne Aktualisierungen, einzelne Einfügungen oder einzelne Löschvorgänge in eine Transaktion eingeschlossen werden?

Ich vermute, das ist abergläubische Programmierung.

Answer 1

Es tut nichts. Alle einzelnen SQL-Anweisungen (mit seltenen Ausnahmen wie Masseneinfügungen mit keinem Protokoll oder Tabelle abschneiden) sind automatisch "In einer Transaktion", ob Sie dies explizit sagen oder nicht (selbst wenn sie Millionen von Zeilen einfügen, aktualisieren oder löschen). .

EDIT: basierend auf @ Phillips Kommentar unten ... In den aktuellen Versionen von SQL Server, sogar Masseneinfügungen und Tabelle abschneiden schreiben einige Daten in das Transaktionslog, obwohl nicht so viel wie andere Operationen tun. Die entscheidende Unterscheidung von einer Transaktionsperspektive besteht darin, dass bei diesen anderen Typen von Operationen die Daten in Ihren Datenbanktabellen, die geändert werden, nicht im Protokoll in einem Zustand enthalten sind, in dem ein Rollback durchgeführt werden kann.

All dies bedeutet, dass die Änderungen, die die Anweisung an Daten in der Datenbank vornimmt, im Transaktionslog protokolliert werden, damit sie bei einem fehlgeschlagenen Vorgang rückgängig gemacht werden können.

Die einzige Funktion, die die Befehle "Begin Transaction", "Commit Transaction" und "RollBack Transaction" bieten, ist, dass Sie zwei oder mehr einzelne SQL-Anweisungen in dieselbe Transaktion einfügen können.

EDIT: (um Mark Kommentar zu verstärken ...) JA, könnte dies auf "abergläubische" Programmierung zurückzuführen sein, oder es könnte ein Hinweis auf ein grundlegendes Missverständnis über die Art der Datenbanktransaktionen sein. Eine gemeinnützige Interpretation ist, dass es einfach das Ergebnis einer Überdosierung von Konsistenz ist, die ein weiteres Beispiel für Emersons Euphemismus unangemessen und noch ist, dass:

Eine törichte Konsistenz der Kobold kleiner Geister ist,
von wenig verehrten Staatsmänner und Philosophen und Denker

Answer 2

Wenn Sie eine explizite Transaktion starten und eine DML ausgeben, bleiben die von der Anweisung gesperrten Ressourcen gesperrt, und die Ergebnisse der Anweisung sind von außerhalb der Transaktion nicht sichtbar, bis Sie sie manuell festschreiben oder zurücksetzen.

Dies ist, was Sie brauchen oder nicht brauchen.

Zum Beispiel möchten Sie möglicherweise vorläufige Ergebnisse in die äußere Welt zeigen, während immer noch eine Sperre auf ihnen.

In diesem Fall starten Sie eine andere Transaktion, die eine Sperranforderung stellt, bevor der erste somit verpflichtet, Race-Bedingung

Implizite Transaktionen vermieden werden festgelegt, oder zurück immediatley gerollt, nachdem die DML Anweisung abgeschlossen ist oder nicht.

Answer 3

Wie Charles Bretana sagte, "es tut nichts" - nichts zusätzlich zu dem, was bereits getan wird.

Haben Sie schon einmal von den "ACID" -Anforderungen einer relationalen Datenbank gehört? Dieses "A" steht für Atomic, was bedeutet, dass entweder die Anweisung in ihrer Gesamtheit funktioniert, oder nicht - und während die Anweisung ausgeführt wird, nein andere Abfragen können auf die betroffenen Daten durchgeführt werden. BEGIN TRANSACTION/COMMIT "erweitert" diese Sperrfunktion auf die Arbeit, die von mehreren Anweisungen ausgeführt wird, fügt jedoch keinen einzelnen Anweisungen hinzu.

jedoch das Datenbank-Transaktionsprotokoll ist immer geschrieben, wenn eine Datenbank modifiziert wird (Einfügen, Aktualisieren, Löschen). Dies ist keine Option, eine Tatsache, die dazu neigt, Menschen zu irritieren. Ja, es gibt Gewöhnlichkeit mit Masseneinfügungen und Wiederherstellungsmodi, aber es wird immer noch geschrieben.

Ich werde Namen-Drop Isolationsstufen auch hier. Wenn Sie damit fertig werden, wirkt sich dies auf einzelne Befehle aus, aber dies führt trotzdem nicht dazu, dass eine Abfrage mit deklarierter Transaktionsabfolge eine andere als eine "eigenständige" Abfrage ausführt. (Beachten Sie, dass sie sehr mächtig und sehr gefährlich sein können, wenn Transaktionen mit mehreren Anweisungen deklariert werden.) Beachten Sie auch, dass "nolock" nicht für Einfügungen/Aktualisierungen/Löschungen gilt - diese Aktionen erfordern immer Sperren.

Answer 4

Eine mögliche Entschuldigung ist, dass diese einzelne Anweisung dazu führen könnte, dass eine Menge anderer SQL über Trigger läuft, und dass sie gegen etwas Schlechtes darin schützen, obwohl ich erwarten würde, dass jedes DBMS den gesunden Menschenverstand hat Verwenden Sie implizite Transaktionen auf die gleiche Weise bereits.

Die andere Sache, die ich denken kann, ist, dass einige APIs Autocommit deaktivieren können, und der Code nur für den Fall geschrieben wird, dass jemand das tut.

Answer 5

Für mich bedeutet das Umbrechen einer einzelnen Anweisung in einer Transaktion, dass ich sie zurückrollen kann, wenn ich beispielsweise eine WHERE-Klausel bei der Ausführung einer manuellen, einmaligen UPDATE-Anweisung vergesse. Es hat mich ein paar Mal gerettet.

z.B.

-------------------------------------------------------------- 
CREATE TABLE T1(CPK INT IDENTITY(1,1) NOT NULL, Col1 int, Col2 char(3)); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 
INSERT INTO T1 VALUES (101, 'abc'); 

SELECT * FROM T1 


-------------------------------------------------------------- 
/* MISTAKE SCENARIO  (run each row individually) */ 
-------------------------------------------------------------- 
BEGIN TRAN YOUR_TRANS_NAME_1; /* open a trans named YOUR_TRANS_NAME_1 */ 
    UPDATE T1 SET COL2 = NULL; /* run some update statement */ 
    SELECT * FROM T1;  /* OOPS ... forgot the where clause */ 
ROLLBACK TRAN YOUR_TRANS_NAME_1; /* since it did bad things, roll it back */ 
    SELECT * FROM T1;  /* tans rolled back, data restored. */ 



-------------------------------------------------------------- 
/* NO MISTAKES SCENARIO (run each row individually) */ 
-------------------------------------------------------------- 

BEGIN TRAN YOUR_TRANS_NAME_2; 
    UPDATE T1 SET COL2 = 'CBA' WHERE CPK = 4; /* run some update statement */ 
    SELECT * FROM T1;    /* did it correctly this time */ 

COMMIT TRAN YOUR_TRANS_NAME_2   /* commit (close) the trans */ 

-------------------------------------------------------------- 

DROP TABLE T1 

--------------------------------------------------------------