Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Coldasice

Lock durch lesenden ODBC Zugriff?

Empfohlene Beiträge

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ß

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von NilsK

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×