Blockierungen beim SQLServer

[Belvasis]

Hallo zusammen,

ich hoffe irgendjemand hier hat eine Idee für mich, denn mein Problem bringt mich quasi zur Verzweiflung.
Ich habe seit einige Zeit das Problem, daß der SQLServer Prozesse derart blockiert, daß kein weiterarbeiten für die jeweiligen Clients mehr nöglich ist. Normalerweise erkennt der SQLServer deadlocks selbst und löst die Konflikte auf, so sagt es die Dokumentation. Nun das tut er leider nicht. Zum anderen werden heir Prozesse blockiert, die miteinander gar nichts zu tun haben und somit auch keinen Deadlock verursachen können. Der SQLGuard2000 sagt folgendes:

BLOCKING Statement : Parameter : 0 - SQL :
SELECT BAUSTEINTEXT_RTF FROM TEXTBAUSTEIN WHERE KUERZEL = 'PGang,'

BLOCKED Statement : Parameter : 0 - SQL :
SELECT VIEW_NOTIFY.* FROM VIEW_NOTIFY WHERE (VIEW_NOTIFY.NO_WHEN >= '25.12.2006') AND (VIEW_NOTIFY.NO_WHEN <= '03.01.2007') AND (VIEW_NOTIFY.USERID <> 33) ORDER BY AKTUELL DESC

Die View VIEW_NOTIFY verweist nicht auf die Tabelle TEXTBAUSTEIN. Das heisst, zwei einfache parallele SELECT - Statements werden blockiert und ich habe einfach keine Ahnung warum...
Hat schon einmal jemand diese Problem gehabt?

Danke und Gruss

 

[Mercenary]

HiHo!

Hat schon einmal jemand diese Problem gehabt?

Noe das konkrete Problem nicht, aber das wird daran liegen, dass bei mir Tabellen und Spalten i.d.R. keine deutsch lautenden Namen haben das liest sich so holprig zwischen dem englischen Code von daher habe ich noch nicht mit Tabellen wie "TEXTBAUSTEIN" zu tun gehabt und das ganze Hantier mit der Hochstelltaste erst. (Du bringst zwar schon eine Menge Informationen bei, die andere gar nicht erst finden wuerden, aber um eine Problematik enger als auf einen ordinaeren deadlock einzugrenzen reicht's halt doch nicht. )

Ansonsten werden eher (relativ) viele tagtaeglich ein Problem mit deadlocks haben, das ist total normal. Allerdings haben die dazu gehoerigen prozesse auch miteinander zu tun da antizipiere ich eher, dass Dir etwas durch die Lappen gegangen ist oder dieser neumodische "SQLGuard2000" (=> EnterpriseManager in neuen Kleidern?) etwas nicht richtig oder nicht einfach genug darstellt. Ich erinnere mich truebe, dass im Enterprise Manager (von Version 6-7) in manchen Ansichten die jeweils letzten erledigten queries eines Prozesses angezeigt wurden, nicht die aktuell bearbeiteten. Wer dann den sourcecode zu den jeweiligen Anwendungen lesen kann ist klar im Vorteil.

Das mit dem

Normalerweise erkennt der SQLServer deadlocks selbst und löst die Konflikte auf, so sagt es die Dokumentation.

Ist so eine Sache, wer diese Aussage als uneingeschraenkt gueltig annimmt hat noch nie die tieferen Bedeutungen diverser standard-AGB ergruendet, das gilt natuerlich so uneingeschraenkt und 100%ig nicht.
Der Server versucht zwar im Rahmen seiner Moeglichkeiten als dummes Programm und ohne Informationen ueber die Anwendungen deadlocks zu entwirren, das gelingt aber nicht immer und nicht 100%ig und spaetestens an dem Punkt, wo entschieden werden muesste einen der verklemmten Prozesse zu killen ist dann halt doch immer noch der Faktor Mensch gefragt allein fuer die Entscheidung welcher Prozess zu eliminieren ist.
Das automatische Entwirren eines deadlocks kann uebrigens auch schon mal uebel lang dauern ... so mehrere 10 Minuten sind da schon mal moeglich.

Ansonsten ist zu dem MS-SQL Server in der Hinsicht noch interessant, dass (zumindest bei 6.0 bis 7.0) die Standardeinstellungen vorsehen, dass wirklich bei jedem Zugriff gelocked wird und das auch gleich Seitenweise!
Wer also keine so hohe "Sicherheit" braucht muss explizit seinen Abfragen entsprechende Hinweise mitgeben damit ein einfacher Select wie der von Dir genannte nicht gleich dutzende Seiten der betroffenen Tabellen locked.
Grundsaetzlich ist das ein gutes Verhalten wenn es um Anwendungen geht, bei denen die Datenkonsistenz auch bei einfachen Abfragen kritisch ist (z.B. echtzeit Transaktionen wie bei Buchungssystemen ala Flugscheinbuchung, Boersentransaktionen etc.).
Bei anderen Anwendungen kommt dann das von Dir beschriebene Ergebnis raus; Entweder man sorgt im jeweiligen code explizit dafuer, dass diese Einstellungen ueberschrieben werden (dirty read mit dem Zusatz NOLOCK im code z.B.) oder man sucht die entsprechenden Servereinstellungen und passt die an das muss der jeweilige Nutzer dann schon fuer sich entscheiden.

Ciao,
Mercy.

 

[Belvasis]

Blockierungen beim SQL Server

Hallo nochmal,

also durch die Lappen gegangen ist mir nichts. Ich habe auch diverse andere Tools verwendet, um dem Problem bei zu kommen. Neben dem von MS angebotetenen PSSDIAG habe ich auch einfach mal den Profiler zur Hand genommen und eine Ablaufverfolgung gemacht. Im Anschluss hat meine Durchforsten von ca. 380 MB Protokolldatei auch nichts anders zum Vorschein gebracht, als verschiedene einfache SELECT's die sich derart blockieren, daß die Prozesse nicht weiterkommen.
Die Aussage in Bezug auf die Doku nehme ich sicher auch nicht uneingeschränkt als gueltig an, aber bei echten Deadlocks, die durch Prozeduren etc. verursacht werden, klappt es ziemlich reibungslos, daß der SQLServer den Prozess mit den geringsten Kosten erkennt, als Deadlockopfer auswählt und dann killt. Nur bei diesen wirklich simplen Geschichten macht er dies nicht. Mir ist klar, daß er locken mussauch beim SELECT' aber diese locks sollten sich doch beim lesen nicht derart blockieren, daß es nicht mehr weitergeht. Wenn hier viele INSERTS/UPDATES mit Triggern und Prozeduren laufen würden, hätte ich ja durchaus ein Einsehen, aber das ist nicht der Fall.
NOLOCK etc. habe ich auch probiert. Das funktioniert dann zwar aber die Ergebnisse sind leider teilweise Datenmüll, den ich in der Anwendung nicht gebrauchen kann.
Alles in allem bleibt es mir ein unerklärliches Rätsel und ich hoffe irgendjemand weiss Rat...

Gruss

 

[Mercenary]

Wenn Du den Daumen auf der Anwendung hast kannst du die Dampfhammermethode anwenden und die Anfragen serialisieren.
Ansonsten wie erwaehnt die standard Einstellungen des Servers aendern, lock ist lock egal ob innerhalb eines Insert, Update, Delete in stored procs oder sonst wo und wenn eingestellt ist, dass auch beim Lesen gelockt werden soll, dann tut der server das auch brav nur das zu aendern laeuft auch wieder auf einen dirty read hinaus was Du ja wohl schon erfolglos probiert hast (mangels Informationen kann ich mir dazu aber nun nichts weiter einfallen lassen).
Also locken und damit leben, dass sich die Zugriffe in die Quere kommen oder nicht locken und mit einer gewissen Wahrscheinlichkeit nicht ganz konsistente Sachen bekommen. das gilt zumindest im Allgemeinen, den Einzelfall kenn ich ja nun nicht.
Also bleibt wohl nur die Dampfhammermethode; Wenn Du da noch eine Persistenz engine mit unterliegendem Cache aufziehst kann das auch performanter sein als bisher aber cache = Risiko.

So long,
Mercy.

Edith sagt: Jetzt weiss ich auch wieder, warum ich die standard Einstellungen des servers nochmal ansprach ... Wie waer's mit einem standardmaessigen rowlock statt pagelock?