Isolation Level "read uncommitted" für eine Connection setzen

[hroch]

Hallo,

ich habe 2 Anwendungen, die auf einer gemeinsamen DB SQL-Server 2005 arbeiten. Bisher arbeiten beide Anwendungen ohne Transaktionen. Jetzt möchte ich Transaktionen an einer Stelle einführen. Nach dem Absetzen von "BEGIN TRANSAKTION" über das Transaction-Objekt sollen jedoch über alle anderen Connecions keine Einschränkungen bei SELECT-Statements durch Sperren auftreten. Wie stelle ich das ein ?

Ich weiss, dass
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

bei einer Transaktion das ermöglicht. Nur muss ich dann ja für jedes SELECT eine Transaktion öffnen. Kann ich das "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;" nicht auch in dem Connection-String irgendwie unterbringen ?

Florian Hroch

[Ralf Jansen]

Global kannst du soweit ich weiß nur die Versionierung anschalten. Das hätte in etwa denn selben Effekt.

ALTER DATABASE MeineLiebeDatenbank SET READ_COMMITTED_SNAPSHOT ON;

Dadurch würden dir auch Dirty Reads erspart bleiben. Versionierung kostet aber natürlich Performance. Müßtest du mal ausprobieren ob du damit leben kannst.

Wenn du wirklich nur uncommited Reads haben möchte würde ich das immer per TableHint machen. Also z.B.

SELECT Column FROM Table WITH(NOLOCK)

[hroch]

Das mit dem TableHint gefäll mir - VIELEN DANK !

Auch wenn ich das nicht wirklich komplett überblicken kann. GIbt es auch Situationen, in denen so ein SELECT dann nicht funktioniert oder irgendwelche anderen Nachteile ?

[Ralf Jansen]

Auch wenn ich das nicht wirklich komplett überblicken kann. GIbt es auch Situationen, in denen so ein SELECT dann nicht funktioniert oder irgendwelche anderen Nachteile ?

Der Nachteil sind Dirty Reads. Eine Anwendung B kann Datenänderungen von Anwendung A sehen die vielleicht von A gar nicht commitet werden sondern zu einem späteren Zeitpunkt per Rollback zurückgenommen werden. Darum insbesondere der Hinweis auf das Versioning in meinem letzten Post. Mit echten Versionierung siehst du immer die zuletzt commitete gültige Version einer Row in einer Tabelle und nicht irgendwelche zweifelhaften uncommitete Daten.

Unter ADO.NET wo man Änderungen nicht direkt in der Datenbank vornimmt sondern erst in einem diconnected Dataset vorhält um später üblicherweise in einem Rutsch die Datenbank upzudaten ist dieses Problem aber minimiert. Ob das für dich problematisch ist kannst du aber nur selbst entscheiden.