Probleme mit SQL Server in Terminalsitzung mit mehreren Instanzen

[storfi]

Hallo,

ich habe bei einem Anwender, bei dem ca. 20 Benutzer auf einem Win2003-Terminalserver arbeiten, gravierende Probleme mit dem SQL Server 2005 (Delphi5-Projekt mit ADO). Meine Vermutung ist, dass dieses spezifische Problem nur dann auftritt, wenn mindestens ein User in seiner Terminalsitzung das Programm mehrmals gestartet hat. Hat jeder Benutzer nur eine Instanz offen, ist soweit alles in Ordnung.

Nun zum eigentlichen Problem: Es gibt Statistiken mit mehreren Minuten Laufzeit. Dabei wird lesend auf eine Tabelle zugegriffen, was zu einem S-Lock führt. Daher habe ich bewusst den Isolation Level auf "Read Uncommited" gesetzt, damit während der Datenaufbereitung andere Benutzer Datensätze in dieser Tabelle einfügen können. Die neuen Datensätze sollen sowieso nicht in der Statistik berücksichtigt werden.

Während der Datenaufbereitung ist der Terminalserver und der Datenbankserver nicht ausgelastet (CPU, Speicher usw.). Trotzdem friert bei anderen Benutzern der Bildschirm ein, wenn neue Datensätze eingefügt werden sollen. Ist die Statistik fertig, können alle anderen Benutzer wieder arbeiten. Also müsste es sich an dieser Stelle um einen Lock auf die Tabelle handeln. Wie gesagt - das Phänomen tritt nur auf, wenn "irgendein" anderer Terminalserver-User mehrere Instanzen in seiner Terminalsitzung offen hat.

Wer hat Erfahrung mit "Read Uncommited" auf MS-Terminalserver? Gibt es einen Isolation Level, der noch weniger restriktiv ist und möglichst gar keine Sperren mehr setzt?

Vielen Dank und noch schöne Feiertage,

Christian

[generic]

Mit dem TS hat das nicht viel zu tun, sondern der SQL Server lockt es halt Aufgrund der Zugriffe.

Grundsätzlich besteht die Möglichkeit das Locking bei einen SQL abzuschalten.
z.B. select * from tabelle with nolock

[jobo]

Vom Sperrverhalten sollte das "unlock" ja das gleiche Ergebnis liefern, wie der Isolation Level der Connection.
Ich würde dann die SQL Anweisung bevorzugen, weil es direkt an den Server geht und keine Nebeneffekte "unterwegs" in ADO haben kann.

Das Sperrverhalten von msSQL fand ich schon im Jahr 2000 unzweckkmäßig. Dachte da hätte sich mittlerweile was dran getan.

[mkinzler]

MSSQL unterstützt optional ab Version 2005 Versionierung statt Log als Transaktionssteuerung.

[storfi]

Ich setze momentan bei Programmstart über die SQL-Anweisung "SET TRANSACTION ISOLATION LEVEL" explizit auf "READ UNCOMMITED" und war der Meinung, das würde ausreichen. Aber offensichtlich werden andere User parallel mit einem S-LOCK blockiert.

Der Zusatz "WITH NO LOCK" ist ja nur bei SELECT-Anweisungen erlaubt. Daher müsste ich nicht die wenigen INSERTs und UPDATEs ändern, sondern Tausende SELECTs?

Der Hinweis auf die mögliche Versionierung statt Sperren ist für mich sehr interessant. Kann über eine SQL-Anweisung auf "Versionierung" umgestellt werden und wird das im Management Studio einmalig erldigt?

Vielen Dank,
Christian

[mkinzler]

Eine Umstellung des Transaktionssteuerungssystems wird wohl nicht nur für eine Abfrage gehen