Sollte es eine Transaktion für Leseabfragen geben?

Question

Ich habe gelesen, dass einige Entwickler/Basler die Verwendung von Transaktionen bei allen Datenbankaufrufen empfehlen, auch bei reinen Leseaufrufen. Während ich verstehe, Einfügen/Aktualisieren innerhalb einer Transaktion, was ist der Vorteil des Lesens innerhalb einer Transaktion?

Answer 1

So erhalten Sie eine einheitliche Sicht auf die Datenbank. Stellen Sie sich vor, Sie haben zwei Tabellen, die miteinander verknüpft sind, aber aus irgendeinem Grund machen Sie 2 Selects... in pseuodocode:

myRows = query(SELECT * FROM A)
moreRows = query(SELECT * FROM B WHERE a_id IN myRows[id])

Wenn zwischen den beiden Abfragen jemand B ändert, um einige Zeilen zu löschen, werden Sie ein Problem haben.

Answer 2

Ähnlich wie RoBorg sagte, würden Sie SELECTS w/i Transaktionen tun, um das Lesen von Phantomdaten zwischen Anweisungen zu verhindern. BUT Es ist wichtig zu beachten, dass die Standardtransaktionsisolationsebene in SQL Server READ COMMITTED ist, die nur schmutzige Lesevorgänge verhindert; um Phantomdaten zu verhindern, müssen Sie mindestens REPEATABLE READ verwenden. "Verwenden Sie diese Option nur, wenn es notwendig ist."

http://msdn.microsoft.com/en-us/library/ms173763.aspx

Answer 3

Ich habe mir das in den letzten Minuten angeschaut, weil ich mehr darüber wissen sollte. Hier ist, was ich gefunden habe.

Transaktionen sind bei einer Auswahl nützlich, wenn Sie diese Zeile sperren wollen, während eine Person Datensätze liest und nicht möchte, dass sie geändert oder gelesen wird. Führen Sie zum Beispiel diese Abfragen aus:

(im Abfragefenster 1)

BEGIN TRAN SELECT * FROM MYTABLE MIT (ROWLOCK XLOCK) WHERE ID = 1

(im Abfragefenster 2)

SELECT * FROM MYTABLE WHERE ID = 1

(Abfragefenster 2 liefert erst dann Ergebnisse, wenn Sie dies in Fenster 1 ausführen)

COMMIT TRAN

Nützliche Links:

http://msdn.microsoft.com/en-us/library/aa213039.aspx

http://msdn.microsoft.com/en-us/library/aa213026.aspx

http://msdn.microsoft.com/en-us/library/ms190345.aspx

Mein Ziel war es, etwas zu blockieren - und das hat endlich geklappt, nachdem ich die XLOCK eingebaut hatte. Die einfache Verwendung von ROWLOCK hat nicht funktioniert. Ich nehme an, dass es eine gemeinsame Sperre (und die Daten gelesen worden war) aber ich bin immer noch erforschen diese.

Durch Hinzufügen von - WITH (UPDLOCK ROWLOCK) - können Sie die Zeilen für Aktualisierungen auswählen und sperren, was der Gleichzeitigkeit zugute käme.

Seien Sie vorsichtig mit Tabellenhinweisen. Wenn Sie sie wahllos anwenden, wird Ihr System schon bei einer geringen Anzahl von Nutzern in Ihrer Anwendung zum Stillstand kommen. Das ist das Einzige, was ich wusste, bevor ich mich damit befasst habe ;)

Answer 4

Ich würde sagen, dass einer der Hauptzwecke einer Transaktion darin besteht, im Falle von Problemen die Möglichkeit eines Rollbacks zu bieten - was beim einfachen Lesen nicht der Fall ist.

Answer 5

Ich habe festgestellt, dass sich "Transaktionen" auf verschiedenen SQL-Servern sehr unterschiedlich verhalten. In einigen Fällen werden durch das Starten einer Transaktion alle anderen Verbindungen gesperrt, so dass kein SQL ausgeführt werden kann, bis die Transaktion bestätigt oder zurückgenommen wird (MS SQLServer 6.5). Andere haben keine Probleme und sperren nur, wenn eine Änderung vorgenommen wird (Oracle). Die Sperren können sogar so erweitert werden, dass sie nur Ihre Änderungen umfassen - Zellensperren / Zeilensperren / Seitensperren / Tabellensperren.

Normalerweise verwende ich Transaktionen nur, wenn die Datenintegrität zwischen mehreren Einfüge-/Lösch-/Aktualisierungsanweisungen aufrechterhalten werden muss. Trotzdem ziehe ich es vor, dies mit DB-definierten kaskadierenden Löschungen zu implementieren, so dass die Datenbank dies automatisch und atomar erledigt.

Verwenden Sie eine Transaktion, wenn Sie eine Situation vorhersehen können, in der Sie mehrere Änderungen rückgängig machen wollen, aber ansonsten wird die Datenbank ihre atomaren Aktualisierungen ohne den zusätzlichen Code durchführen, um damit umzugehen.