Lock durch lesenden ODBC Zugriff?

[Coldasice 12]

Hallo Leute,

 

mich beschäftigt zur Zeit eine Frage zum lesenden Zugriff auf eine SQL Server 2012 Datenbank in Bezug auf Tabellenlocks.

Wir haben festgestellt das beim Zugriff die komplette Tabelle gelockt wird, obwohl der User nur lesenden Zugriff hat.

Der User hat die Rolle db_datareader zugeordnet, ich hatte nicht damit gerechnet, das dabei Tabellen gesperrt werden.

 

Gibt es einen Weg, diese Sperren zu vermeiden?

 

Gruß

[zahni 554]

Das Problem tritt in  der  Regel  auf, wenn die  Anwendung einen ungeeigneten Isolation Level verwendet:

 

https://msdn.microsoft.com/de-de/library/ms173763.aspx

 

Da kann man i.d.R. nur etwas an der Anwendung machen.

[NilsK 2.934]

Moin,

 

das ist eine Frage des Isolation Levels und der Transaktionssteuerung. Wenn die lesende Transaktion sofort wieder beendet wird, entfernt der SQL Server auch den Lock. Leider halten manche Clients die ganze Zeit eine Transaktion offen. Möglicherweise werdet ihr das nicht ändern können, ohne den Client-Code anzupassen.

 

http://lmbtfy.com/?q=sql+server+locking

 

Gruß, Nils

[Coldasice 12]

Hi Ihr beiden,

 

das habe ich auch schon gelesen und verstanden. Konkret geht es hier um Abfragen die aus Access und/oder Excel kommen.

Nun bin ich auf der Suche, in diesen Anwendungen das Isolation Level auf read uncommitted zu stellen, damit sollte ja dann keine Sperre mehr entstehen.

Gibts hierzu Erfahrung?

 

Das Problem tritt in  der  Regel  auf, wenn die  Anwendung einen ungeeigneten Isolation Level verwendet:

 

https://msdn.microsoft.com/de-de/library/ms173763.aspx

 

Da kann man i.d.R. nur etwas an der Anwendung machen.

 

 

Moin,

 

das ist eine Frage des Isolation Levels und der Transaktionssteuerung. Wenn die lesende Transaktion sofort wieder beendet wird, entfernt der SQL Server auch den Lock. Leider halten manche Clients die ganze Zeit eine Transaktion offen. Möglicherweise werdet ihr das nicht ändern können, ohne den Client-Code anzupassen.

 

http://lmbtfy.com/?q=sql+server+locking

 

Gruß, Nils

[zahni 554]

Probier  mal den Default Isolation Level  auf  1  zu stellen:

 

http://stackoverflow.com/questions/25521915/ms-access-read-uncommitted

 

Achtung: Wenn die  Tabellen  "leben", können die Ergebnisse inkonsistent sein, weil auch nicht festgeschriebene Daten gelesen werden.

[NilsK 2.934]

Moin,

 

ääähhh ... Vorsicht mit sowas! Solche Änderungen darf man nur ausführen, wenn man alle zugreifenden Anwendungen und ihre Vorgehensweisen kennt!

 

Wie zahni schon sagt: Es drohen Inkonsistenzen, die u.U. auch Folgen haben können.

 

Vielleicht findet sich hier was, ich hab nicht genug Zeit, um das eingehender zu lesen:

https://technet.microsoft.com/en-us/library/bb188204(v=sql.90).aspx

 

Gruß, Nils

bearbeitet 8. Dezember 2016 von NilsK

[Dunkelmann 96]

Moin,

 

ich kann mich Nils nur anschließen. Nicht einfach an der DB werkeln ohne das mit dem Softwarelieferanten/Entwicklern abzustimmen.

 

Nebenbei: Office Anwendungen direkt per ODBC auf produktive Datenbanken loszulassen ist schon sehr mutig.

Als ich noch intensiver mit SQL unterwegs war, haben wir für solche Fälle read only views erstellt.

[zahni 554]

Mit den Views habt Ihr prinzipiell recht. Allerdings kann es der Anwendung  egal sein, ob da noch jemand mit Dirty Reads arbeitet. Es müssen hier  nur  die datentechnischen Nachteile bekannt sein.

In unseren Statistik-Anwendungen auf  DB2 arbeiten wir mittlerweile auch nur noch mit Dirty Reads, weil  die  eigentlichen Anwendungen sonst gestört werden.

In DB2 schlägt  sich der Isolation Level bei Views  auch auf Tabellen durch, es sei denn, man benutzt MQTs oder ähnliches.

[NilsK 2.934]

Moin,

 

kann man ja auch machen - aber dann muss man sich beim Anwendungsdesign über die Folgen im Klaren sein. Einfach mal so was umstellen wäre keine gute Idee - vor allem nicht, wenn verschiedene Applikationen auf dieselben Daten zugreifen.

 

Gruß, Nils