Permanente Locks ohne Sysadmin

[Rya]

Hallo!

Folgendes Problem:

Bisher haben ich für Datenbankzugriffe immer die "sysadmin" Rolle benutzt und es hat alles einwandfrei funktioniert.

Jetzt wollte ich den benötigten Rechte für die Software reduzieren, indem ich nur noch "dbcreator" Rechte brauch + ein paar manuell zugewiesene Rechte für Lesezugriff auf Systemtabellen. Soweit funktioniert auch alles ganz gut, alle Funktionalitäten können benutzt werden. Nur jetzt scheint öfters das Problem aufzutreten, dass eine Tabelle gesperrt und dann nicht mehr freigegeben wird. Nichtmal nur über die Software, auch wenn man eine Query mit Transactions direkt im Management Studio ausführt, scheint es manchmal zu passieren. Kann dies mit den fehlenden sysadmin Rechten zu tun haben? Muss ich der Rolle eventuell ein Recht wie "Sperren freigeben" zuordnen?

[Ralf Jansen]

Eigentlich nicht. Locks leben nicht länger als die Transaktion (egal ob implizit oder explizit) in dessen Context sie entstanden sind. Wenn du also irgendwo langlebige Locks hast hast du auch langlebige Transaktionen die das eigentliche Problem darstellen.

[defo]

Ich kenn die aktuelle Lage bei MSSQL nicht, weiß nur, dass das Sperrverhalten früher, also vor ganz langer Zeit, nicht wirklich StateOfTheArt war.
Wenn Du jetzt (welche Version?) solche Probleme hast, hast Du eher ein Design- bzw. Implementierungsproblem und wie Ralf Jansen sagte, Transaktionen haben erstmal nichts mit Rechten zu tun.
Ich würde mangels Kenntnis nicht ausschließen, dass sysadmins quasi als Geburtsrecht etwas anders mit langen oder Zombitransaktionen umgehen können und nun Probleme hochkommen, die Du so nicht hättest.
Aber pack lieber das Übel an der Wurzel und durchforste die Anwendung nach aktiven Tablelocks usw.
P.S.: Wie lauten denn die Fehlermeldungen?
Und Thema "..auch Query mit Transactions.."
Da kommst Du gar nicht drumrum, entweder es geschieht implizit oder Du verlangst es explizit. Das ändert nichts am Konzept und den Effekten von Transaktionen. Explizite Angaben führen u.U. häufiger zu langanhaltenden Transaktionen, hier ist dann die Frage, wie filigran der Server die Locks setzt/setzen kann.

[Rya]

Also es kommt keine Fehlermeldung, es ist vielmehr so, dass plötzlich bestimmte Abfrage "unendlich lang" laufen, wenn ich es dann näher untersuche, merk ich, dass nur Abfragen auf eine bestimmte Tabelle ewig laufen und daraus schließe ich, dass dort ein LOCK nicht richtig freigegeben wurde.

Ich glaub bei der Installation (die uns keine Sysadmin Rechte geben will und wo die Probleme auftreten) läuft aber noch einiges anderes schief, weil er auch mehrmals täglich einen "Connection to Database Lost" Fehler bringt.

[Ralf Jansen]

Also es kommt keine Fehlermeldung, es ist vielmehr so, dass plötzlich bestimmte Abfrage "unendlich lang" laufen, wenn ich es dann näher untersuche, merk ich, dass nur Abfragen auf eine bestimmte Tabelle ewig laufen und daraus schließe ich, dass dort ein LOCK nicht richtig freigegeben wurde.

Dann wäre also jetzt die Aufgabe rauszufinden ob zu diesem Zeitpunkt Locks auf dieser Tabelle sind und deine Annahme stimmt, wenn ja warum und ob das nötig ist. Sonst bleibt es irgendwie bei nicht hilfreichen Vermutungen.

[defo]

Also es kommt keine Fehlermeldung, es ist vielmehr so, dass plötzlich bestimmte Abfrage "unendlich lang" laufen, wenn ich es dann näher untersuche, merk ich, dass nur Abfragen auf eine bestimmte Tabelle ewig laufen und daraus schließe ich, dass dort ein LOCK nicht richtig freigegeben wurde..

Lock oder Deadlock, ich weiß nicht, wie/ob MSSQL das unterscheidet.
Unter Oracle ist es bspw. so, dass (nur!)im Falle eines Deadlocks, das System diesen Zustand erkennt und eine der Transaktionen gewaltsam beendet. Das wäre dann eine Lost Connection analog zu dem Szenario bei Euch(Hab ich noch nie persönlich erlebt, soll so sein)
Im Fall eines permanenten Locks auf eine Tabelle kann bzw. sollte das System nicht wissen was los ist und auch nicht eingreifen und dann wohl auch eher nicht eingreifen.
Alles Spekulation: Locks müsste man über System Views anzeigen können. Weiß nicht, wie das bei MS SQL geht, vlt. auch via SPxyLock

[Ralf Jansen]

Unter Oracle ist es bspw. so, dass (nur!)im Falle eines Deadlocks, das System diesen Zustand erkennt und eine der Transaktionen gewaltsam beendet. Das wäre dann eine Lost Connection analog zu dem Szenario bei Euch(Hab ich noch nie persönlich erlebt, soll so sein)

Ist im SQL Server genauso. Die Connection ist aber nicht einfach weg oder hängt ewig man bekommt schon eine ~passende~ Fehlermeldung. Das allseits beliebte "Sie wurden als Deadlockopfer ausgewählt ...".
Wenn hier Locks das Problem sind sind es normale Locks.