Jump to content

Lock durch lesenden ODBC Zugriff?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

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ß

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...