Zum Inhalt wechseln


Foto

Lock durch lesenden ODBC Zugriff?


  • Bitte melde dich an um zu Antworten
8 Antworten in diesem Thema

#1 Coldasice

Coldasice

    Member

  • 167 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:15

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ß



#2 zahni

zahni

    Expert Member

  • 15.923 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:35

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

 

https://msdn.microso...y/ms173763.aspx

 

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#3 NilsK

NilsK

    Expert Member

  • 11.516 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:37

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... server locking

 

Gruß, Nils


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#4 Coldasice

Coldasice

    Member

  • 167 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:42

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.microso...y/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... server locking

 

Gruß, Nils



#5 zahni

zahni

    Expert Member

  • 15.923 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:53

Probier  mal den Default Isolation Level  auf  1  zu stellen:

 

http://stackoverflow...ead-uncommitted

 

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#6 NilsK

NilsK

    Expert Member

  • 11.516 Beiträge

 

Geschrieben 08. Dezember 2016 - 16:55

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.micr...(v=sql.90).aspx

 

Gruß, Nils


Bearbeitet von NilsK, 08. Dezember 2016 - 16:58.

Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#7 Dunkelmann

Dunkelmann

    Expert Member

  • 1.860 Beiträge

 

Geschrieben 08. Dezember 2016 - 18:50

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.


Keep It Small - Keep It Simple


#8 zahni

zahni

    Expert Member

  • 15.923 Beiträge

 

Geschrieben 09. Dezember 2016 - 09:09

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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#9 NilsK

NilsK

    Expert Member

  • 11.516 Beiträge

 

Geschrieben 09. Dezember 2016 - 09:56

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!