MSSQL Server mit 100 Clients

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

[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

[jobo]

Zitat von p80286:

Ich verstehe die Vorgehensweise nicht.

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?

Ich versteh das "Delete" auch nicht. Wenn es um "klassische" Messwertaufnahme geht, halte ich Deinen Einwand für sehr berechtigt. Daher hab ich ja auch vorgeschlagen, darauf zu verzichten.
Ich verstehe es momentan so: Es ist anhand des Ablaufs anscheinend eben keine reine Messwertaufnahme, was es sonst sein könnte, ist mehr oder weniger Spekulation.

Vielleicht ist es der Versuch einer Umsetzung des BDSG neu, Abschnitt "Datensparsamkeit"