MSSQL Server mit 100 Clients

[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?

[jobo]

Zitat von egentur:

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.

Das ist jetzt aus Sicht MSSQL Server > Oracle Client DB?
Oder umgekehrt?

Wichtig bei diesen Problemen ist tatsächlich, wie es im Detail abläuft (Verfahren wie beschrieben z.B. "suchen,löschen, neuschreiben") und die Technik dafür (Siehe meine Fragen zuvor).
Wenn es tatsächlich auf Lock Escalation Effekte hinausläuft, ist natürlich auch die Frage, welche Datenmengen / Stückzahlen übertragen werden von den (bereits bekannten) 100 Clients.

Zurück zum Zitat:
Delete ist verhältnismäßig sehr teuer. Moderne DB können entsprechend konfiguriert werden, dass gewisse Aktionen quasi bevorzugt werden. Das ist in Standardkonfigurationen NICHT "delete". Hier spielen dann auch Fragen wie Anzahl von Indizes, Ref constraints und Cascade Constraints Regeln z.B. "on delete cascade" eine Rolle.
Kurz, man will vielleicht kein Delete sondern eher ein Update.
Oder nicht mal ein Update, sondern nur ein Insert mit nachführung eines "Aktiv" oder "Last" Flag.

Grundsätzlich bei Messwertaufnahme geht es ja in Richtung Big Data. Da wird nicht unbedingt filigran gearbeitet, sondern stumpf geschrieben. "Schau mal, ob es das schon gibt und dann lösch das und trag es schick neu ein." ist je nach Lastsituation / Ausstatung nicht das, was man sich erlauben kann.

Eigentlich wird primär darauf geachtet, keine Daten zu verlieren. Im nächsten Schritt wird dann in einem separaten System gefiltert, aggregiert, ..

[p80286]

Ich verstehe die Vorgehensweise nicht.
Ein Messwert (oder mehrere) wird zu einem Zeitpunkt erfasst und in einer lokalen Datenbank gespeichert. Irgendwann verbindet sich die lokale Datenbank mit der zentralen Datenbank und
löscht den/einen Datensatz und fügt ihn danach in die zentrale Datenbank ein.

Da jeder Datensatz durch die Meßstation und den Zeitpunkt charakterisiert ist, dürfte ein beliebiger Datensatz, der noch nicht übertragen wurde, nicht in der zentralen Datenbank vorhanden sein. Warum also sollte ich den Datensatz löschen wollen?
Will ich z.B. nur die Daten der letzten 24 Stunden auf dem zentralen Server haben, dann kann man unabhängig vom Client bei Gelegenheit die überflüssigen Datensätze löschen.

Gruß
k-H