MSSQL Server mit 100 Clients

[trifid]

Die Frage war:
"Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ?"
Vielleicht hilft eine Diskussion über eine Architktur der Anwendung hier weiter, bevor man den Datenbankserver schlecht redet.

[jobo]

Zitat von trifid:

Vielleicht hilft eine Diskussion über eine Architktur der Anwendung hier weiter, bevor man den Datenbankserver schlecht redet.

Architekturfragen wurden bereits einige angesprochen.
Was meinst Du mit "schlechtreden"?
Eine Architektur lässt sich ohne Betrachtung der Servereigenschaften/-fähigkeiten nur unzureichend diskutieren.
Die Frage wäre m.E. eher, ob der TE zu seiner Frage noch ein paar Details liefert.

[Delphi.Narium]

Eventuell hilft auch erstmal eine grobe fachliche Beschreibung dessen, was realisiert werden soll.

Dann muss man sich das erforderliche Transaktionshandling mal anschauen.

Welche Datenmenge liegt insgesamt vor?
Wieviele Daten werden in welchem Zeitraum verändert?
Wie groß ist überhaupt die Wahrscheinlichkeit, dass bei Änderungen Konflikte auftreten? (Gemeinsam zu bearbeitende Schnittmenge?)

100 Clients, die hauptsächlich lesend auf die Daten zugreifen, dürften kaum das Problem sein.
100 Clients, die permanent alle Daten ändern, wohl schon eher.
Wo dazwischen müssen wir hier konkret die 100 Clients einordnen?

Jeder Client sollte soviel Daten wie nötig zeitgleich vorhalten und so wenig wie möglich.
Alles, was zur Änderung benötigt wird, sollte möglichst kurz auf dem Client vorgehalten werden.

[Hobbycoder]

In einem sehr großen Projekt vom mir habe ich das so gelöst, dass ich in den datenrelevanten Tabellen ein Feld vorgesehen habe, in welchem der aktuelle Username hinterlegt wird, welcher den Datensatz gerade zum Bearbeiten geöffnet hat.

Das hat für mich 3 Vorteile:

1. Bei eventuellem späterem Wechsel auf eine andere DB muss ich im Code wenig ändern und bin auch nicht davon abhängig, wie das in der DB gelöst ist.
2. Da ich den Datensatz eh für die Anzeige lesen muss, zeige ich dem User "vor" dem Bearbeiten an, dass dieser Datensatz nicht bearbeitet werden kann. (Lesen ich aber möglich)
3. Ich zeige ihm an welcher User diesen Datensatz blockiert, dann weiß er an wen er sich wenden muss und läuft nicht fragend von Büro zu Büro.

Um Probleme zu vermeiden wird beim Programmstart und beim Programmende alle Einträge des Users in besagtem Feld gelöscht, also alle Datensätze, die evtl. noch belegt sind, freigegeben.

Und zu guter Letzt gibt es im Programm dann noch eine Funktion einen evtl. fälschlich (durch Programmabsturz / Windows-Absturz / Stromausfall / etc.) belegten Datensatz manuell freizugeben, mit dem Hinweis wer zuletzt speichert hat gewonnen.

Damit fahre ich seit mehr als 10 Jahren in dieser Anwendung sehr gut und ohne Probleme für die User oder die Daten, bei bis zu 50 User und einigen 100.000 Datensätzen.

Ich muss aber dazusagen, dass ich nicht mit DB-Controls wie DBGrid etc. arbeite, sondern ausschließlich mit TObjectList's welche die Daten per Query lesen und schreiben.

[TigerLilly]

1) Selects immer(!) mit WITH NOLOCK
2) Transaktionen möglichst kurz und klein halten
3) Commit niemals dem User überlassen
4) Pro Tabelle einen PK (no na) und ein Feld SERIAL, das bei jeder Änderung durch den User von der Software hochgezählt wird. Beim Update kann man dann die Where Klausel auf den PK und eben dieses Feld beschränken, mit einem Index da drauf geht das auch flott.
5) Record vs Page vs Table Locking und Lock Escalation verstehen
6) Deadlocks verstehen

Das wars. MSSQL Server mit 100 Clients ist seit v2000 kein Problem.

[jobo]

Vielleicht gibt's in dem Whitepaper von Idera ja auch ein paar gute Hinweise (hab's nicht gelesen, ist per Email eingetroffen mit Download link)
[Whitepaper] Tips to troubleshoot blocking & locking in SQL Server
https://www.idera.com/resourcecentra...king-dbartisan

[egentur]

Hallo zusammen,
erst mal Danke für die zahlreichen Tips.
Vielleicht doch nochmal den Aufbau.

Es gibt ca. 100 Messstationen mit jeweils einer lokalen Oracle DB.
Diese müssen auch im Fall eines Serverausfalls autark laufen (messen) können.

Die Messmethoden und Messläufe liegen zentral für alle Stationen auf einem MSSQL 2012 Server.

Ein User erstellt bzw. editiert auf dem zentralen Server seine Methoden und Läufe.
Nach dem Speichern werden diese sofort an den lokalen Client repliziert und kann dort auf der loklen Oracle gefahren(gemessen) werden.

Die gemessenen Daten werden dann wieder nach "oben" auf den zentralen MSSQL Server repliziert.
Eigentlich bearbeitet jeder User "seinen" Bereich der Daten auf den MSSQL Server.

Die Replikation der Daten in beide Richtungen läuft als Windows Service jeweils auf den einzelnen Clients.

Jetzt kommt es öfter vor daß verschiedene Tabellen gelockt sind und dann ein [SQL Server Native Client 11.0][SQL Server] Lock request time out period exceeded] auftritt.

Wenn der ReplikationsDienst einen Datensatz übertragen soll, sucht und löscht er diesen anhand des PK (GUID) und schreibt dann den Datensatz neu in die Ziel DB.

Kann es sein dass das Löschen eines Datensatzes einen Lock für die gesamte Tabelle auslöst und dann andere Clients blockiert ?

Danke für eure Hinweise !

[mkinzler]

Kommt auf das Locking-Verfahren an.

[jobo]

Wie erfolgt denn das Löschen?
Ein SQL Delete? Ein TDataset.delete? Aufruf eine SP?
Explizites Transaktionshandling, implizites?
Ein Datensatz pro Aufruf oder mehrere?
Und wurde ja schon gefragt, explizites Lock?

Und nur mal aus Neugier, warum die Datenbank-Grätsche mit MSSQL und Oracle?

[TigerLilly]

Das Stichwort ist Lock Escalation bzw table hints.

Siehe auch:
https://docs.microsoft.com/en-us/sql...ql-server-2017

Wenn ein Satz gelesen, gelöscht oder aktualisiert wird, kann es sein, dass aus Performancegründen nicht nur der einzelne Satz, sondern eine Page oder gar die ganze Tabelle gelockt wird. Damit kann es sein, dass ein anderer Prozess, der ganz andere Sätze bearbeiten möchte, trotzdem ins Lock läuft.

je mehr User, je mehr Concurrency, desto wahrscheinlicher wird das.