Hilfe beim debugen eines seltsamen Problems

[fisipjm]

Moin Moin,

ich stehe vor einem Problem / Fehler und weiß nicht wie ich dem ganzen auf die Schliche kommen soll.
Folgendes Problem:

Ich habe ein System beim Kunden: Konstrukt ist Applikationsserver (RAD Server, Dienst und Client) auf einem anderen Server die MSSQL Datenbank (Version 2016).
Ich greife via FireDac auf die Tabellen zu. Um noch ein paar Zusatzfunktionen zu realisieren, hab ich mir um eine Reguläre FDQuery ein Klasse gebastelt, nix wildes.
In der Klasse gibt es eine Insert Funktion die macht im Prinzip nix anderes, als die Tabelle über eine Query aufzurufen in der sowas steht:

Code:

SELECT * FROM TABELLE WHERE 1=0

Damit hab ich dann den Zugriff, danach mach ich dann im Code:

Delphi-Quellcode:

Query.append;
...
Query.fieldbyname('Feld1').value := aValue;
...
Query.post;

So weit so unspektakulär. Das funktioniert auch super. Manchmal kommt es allerdings vor, dass der POST Befehl einfach hängt. Er freezt komplett. Ich hab alles in einem Try Except block, kein Error wird ausgelöst. Der Dienst steht einfach und nix tut sich mehr. Habt ihr einen Vorschlag wie ich das ganze weiter eingrenzen kann? Es steht auch nicht exotisches in den Feldern drin, genau das gleiche wie in den 250 Fällen vorher, wo es funktioniert.

Grüße
PJM

[jaenicke]

Tools wie Eurekalog haben auch eine Erkennung, ob die Anwendung hängen bleibt. Nach einem gewissen Timeout kann dann ein Log geschrieben werden, in dem du erkennen kannst, wo es hängt und evtl. auch warum.

In der Ereignisanzeige des Systems ist nichts zu sehen?

[fisipjm]

Leider keine Meldung im Eventlog des Applikationsservers. Auf den SQL Server selbst hab ich keinen Zugriff. Fühlt sich bissel an wie eine Session die hängt. Kann man der Query ein Timeout mit geben?

[TigerLilly]

Schau mal, ob es in der Datenbank Deadlocks gibt.
https://www.sentryone.com/de/sql-server/sql-deadlock

[fisipjm]

Zitat:

Zitat von TigerLilly (Beitrag 1504142)

Schau mal, ob es in der Datenbank Deadlocks gibt.
https://www.sentryone.com/de/sql-server/sql-deadlock

TigerLilly... du bist die beste :-D
Ein select statement blockt mir ein Insert :?
Das kann die DB scheinbar nicht "auflösen". Ich hab mir jetzt schon bisschen was angeschaut zu "with (nolock)" und updateoptions.lockmode sowie updateoptions.Lockwait aber werd daraus nicht so wirklich schlau, was für mich der richtige Ansatz ist.
Hat da jemand schon Erfahrungen sammeln können?

[taveuni]

wenn Du den SELECT mit NOLOCK ausführst wird die Tabelle nicht gesperrt. Hat den Nachteil dass natürlich eventuell die Ausgabe des SELECTS nicht 100% stimmt.

[TigerLilly]

Um Datenkonsistenz zu wahren, sperrt der SQL Sevrer Sätze bzw Pages bzw Tables, das nennt sich dann Lock Escalation, weil uU Sätze gesperrt sind, die mit der Transaktion gar nichts zu tun haben. Ich nutze in unseren Programmen bei allen selects "with (nolock)" + hatte noch nie - auch in stark concurrenten Umgebungen Probleme, Aber das waren auch immer Daten, wo viel mehr gelesen als geschrieben wurde.

Manche sagen, with nolock wäre bad practice. Aber - sieh oben - das hängt davon ab.

https://www.sentryone.com/blog/aaron...ock-everywhere
https://www.sqlshack.com/understandi...l-server-2017/
https://stackoverflow.com/questions/...t-bad-practice

[fisipjm]

Zitat:

Zitat von TigerLilly (Beitrag 1504147)

Um Datenkonsistenz zu wahren, sperrt der SQL Sevrer Sätze bzw Pages bzw Tables, das nennt sich dann Lock Escalation, weil uU Sätze gesperrt sind, die mit der Transaktion gar nichts zu tun haben. Ich nutze in unseren Programmen bei allen selects "with (nolock)" + hatte noch nie - auch in stark concurrenten Umgebungen Probleme, Aber das waren auch immer Daten, wo viel mehr gelesen als geschrieben wurde.

Manche sagen, with nolock wäre bad practice. Aber - sieh oben - das hängt davon ab.

https://www.sentryone.com/blog/aaron...ock-everywhere
https://www.sqlshack.com/understandi...l-server-2017/
https://stackoverflow.com/questions/...t-bad-practice

Danke für die Hinweise, da ich innerhalb der Klasse immer über die geleiche Connection gehe, habe ich das ganze jetzt so gelöst:

Delphi-Quellcode:

DataConnection.UpdateOptions.LockMode := lmPessimistic;
    DataConnection.UpdateOptions.LockWait := True;

Das sind 2 Zeilen mehr Code und scheint zu funktionieren. Jedes SQL Statement um ein

Code:

With (NoLock)

zu ergänzen wäre deutlich mehr Aufwand. Scheint aktuell mal zu laufen. merci :thumb:

[Sinspin]

Ich arbeite generell mit NoLock und setzte auf ein eigenes System zum Locken von Datensätzen die bearbeitet werden sollen. Der Nutzer bekommt dann keinen DB Error um die Ohren gehauen wenn ein Record gesperrt ist, sondern eine Vernünftige Meldung und wartet dann einfach mit Posten bis der Lock weg ist.

[TigerLilly]

Das eine hat mit anderen nicht unbedingt etwas zu tun. Beim "with (nolock)" geht es um die Konsistenz beim Lesen. Für Update und Delete gibt es auch entsprechende Hints, die das Locking beeinflussen. Wie gesagt, die Strategie hängt davon ab, was das für ein System isat. Wenn viel mehr gelesen als geschrieben wird, wenn das viele Nutzer*innen sind, tut nolock seine Dienste gut + dann kann man gut mit optimistic locking leben. Heißt: Gehe davon aus, dass der Datzensatz, den du änderst, nicht schon von wem anderen geändert wurde. Wenn viel öfter geschrieben als gelsen wird, ist pessimistic locking angebracht. Sich bei einem MSSQL Server sein eigenes Lockingsystem zu schreiben, erschließt sich mir grad nicht. Warum würde man das machen wollen?
Wie auch immer: Die Locks müssen so kurz wie möglich und so begrenzt wie möglich sein. Sonst eskaliert das zu Blockierungen.

https://www.sqlshack.com/locking-sql-server/
https://stackoverflow.com/questions/...-in-sql-server
https://www.mssqltips.com/sqlservert...server-tables/