FireDAC, onDemand, DeadLock

[haentschman]

Moin...

Zitat:

Durch die möglichkeit von SNAPSHOT Verwendung werden alle Selects ohne Locks ausgeführt...

Wie stelle ich das in FireDAC ein?

Zitat:

Aber im Ernst, Select * from ... hast Du nicht verwendet?

...da gibt es reichlich.

Nochmal: Wir reden über 2Mio Zeilen. Ich bin erst seit einem halben Jahr dabei. Es gibt Bereiche die ich noch nichtmal angefaßt habe. Ich muß nun die Kuh vom Eis kriegen. Mit jeder Rechnung steigt der Arbeitsspeicher. Ich kann aber nicht eben mal das bestehende Konzept auseinanderreißen. Daß ich das tun muß ist klar...wie macht das am lebenden Patienten?

Ich bräuchte eine funktionierende Konstellation in Stichpunkten:
1. Server mit Einstellung Blubb
2. Connection mit Einstellung Bla
3. Was ist bei den Querys zu beachten
4. Wie verhalten sich INSERTS die direkt in die Tabelle schreiben
... usw.

[HolgerX]

Hmm..

Zitat von haentschman:

Moin...

Zitat:

Durch die möglichkeit von SNAPSHOT Verwendung werden alle Selects ohne Locks ausgeführt...

Wie stelle ich das in FireDAC ein?

Gar nicht!

Das ist eine Einstellung auf dem SQL-Server!
Dieser regelt dann die Snapshot-Geschichte, da dieser auch die Locks ausführt.

Schau Dir bitte den Link an, dort sind die Transact-SQL Befehle für das setzen des Isolationslevel erklärt. Ich hatte noch per Google andere Info-Quellen gefunden.
Die Konfiguration für SNAPSHOT kann für die gesamte Datenbank global gesetzt werden, es gibt jedoch auch die Möglichkeit dies nur für einen Query zu machen.

Wenn du es global setzt, ist es gleich, wie Du auf den SQL-Server zugreifst und es bedarf keiner Änderungen in deinem Programm.

Alternativ könntest Du auch jeden Select-Query änderen und dort z.B. WITH NOLOCK eintragen

Hier noch einen Link:
https://docs.microsoft.com/de-de/dot...-in-sql-server

[haentschman]

Danke...
...dann wühle ich mich mal durch.

[p80286]

Zitat von haentschman:

Ich bräuchte eine funktionierende Konstellation in Stichpunkten:
1. Server mit Einstellung Blubb
2. Connection mit Einstellung Bla
3. Was ist bei den Querys zu beachten
4. Wie verhalten sich INSERTS die direkt in die Tabelle schreiben
... usw.

Wenigstens hast Du schon mal die richtigen Prioritäten.
wobei ich 2 und 3 tauschen würde. An der Connection drehen ist schon eher Finetuning.
Was ist der Hintergrund von 4?

Das ist eher unter 1 zu erledigen, weil das ist Job der DB.
Was meinst Du mit "die direkt in die Tabelle schreiben"? Das is eigentlich das Standardverhalten!?

Gruß
K-H

[haentschman]

Moin...

Zitat:

Was meinst Du mit "die direkt in die Tabelle schreiben"?

...war komisch ausgedrückt.
Ich meinte:
Im Moment arbeiten die Querys mit DataSet Methoden...INSERT, EDIT usw. Ich bin dazu übergegangen u.a. auch UPDATE, SELECT Statements direkt über SQL abzusetzen. Das kollidiert aber u.U. mit dem Schreiben einer offenen Query mit der "gleichen" Datenmenge.
Die Frage war eher...kommen sich die Querys in Gehege?

[jobo]

"Gehege"
Neulich hatten wir das Thema Lock Escalation by SQLServer, weiß nicht mehr wo. Das Lock Verhalten ist (ohne Anspruch auf Allgemeingültigkeit) bei dem Produkt traditionell nicht so gut, über die Jahre/Versionen aber besser geworden. Rowlevel locking war langezeit auf der Wunschliste, geht jetzt, kann aber trotzdem mal Aussetzen, eben im Falle einer "Escalation". Was man im Betrieb mit hoher Serverlast übersetzen kann.

Es ist also nicht nur eine Frage der Anwendung und deren Zugriffstechnik. Ich mag das Produkt nicht, deswegen kann ich nicht wirklich konkrete Tipps geben. Würde aber mal testen, ob das Verhalten Last abhängig ist. Z.B. morgens um 8-10 schlecht, 17 uhr und später eben besser. Oder tritt es mit einer einzigen, aktiven Anwendung auf (Die Anwendung sperrt sich tatsächlich selbst)

Auch gern problematisch und ggF. auch bei fettem Code systematisch und relativ zügig zu bereinigen (Trotzdem Fleißarbeit). Commit-Durcheinander.
Ich habe mit Delphi immer mit impliziten Transaktionen gearbeitet und alles was explizites Transaktionshandling macht, verboten, rausgeworfen. Ganz früher auch mal anders und sofort graue Haare bekommen (das war auch ein MS SQL Server).

[p80286]

Wenn möglich das Dataset/SQL Mischmasch beenden.
Nachdem ich mir die Ausführungen von Bernhard zu ADO zu Gemüte geführt habe (ist auch schon Jahre her) hab ich ganz schnell auf ein Datamodule mit SQL-Queries umgestellt. Es reicht wenn ein Chaot vor der Tastatur sitzt, da braucht's nicht noch jemanden, der alles besser wußte.
(Daß damit der Speicherverbrauch sank und die Geschwindigkeit anstieg war ein angenehmer Nebeneffekt, aber Du bist dann wirklich für alles verantwortlich)

Gruß
K-H