|
Datenbank: MSSQL • Version: 2012 • Zugriff über: AnyDAC
MSSQL Server mit 100 Clients
Hallo Zusammen,
Ich habe eine DB (MSSQL 2012, Zugriff über AnyDAC) mit ca. 30 Tabellen. Nun sollen bis zu 100 Clients parallel darauf zugreifen. Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ? Alle Vorschläge willkommen ! |
AW: MSSQL Server mit 100 Clients
Zitat:
|
AW: MSSQL Server mit 100 Clients
Zitat:
|
AW: MSSQL Server mit 100 Clients
Ohne die genannte Version der DB zu kennen (auch nicht die aktuelle):
Es sind die Fähigkeiten der DB zu berücksichtigen und die Vorgänge in der Anwendung. zum ersten: Alte MS SQL Versionen (wahrscheinlich noch älter als die genannte) sind nicht unbedingt geeignet. Wegen fehlendem Rowlevel locking usw.. Je neuer die SQL Server Version, desto besser. zum zweiten: Eine Anwendung/DB, die keine konkurrierenden Inhalte verwaltet, ist viel unproblematischer als eben bei konkurrierenden Inhalten. Bspw. die Angabe "Artikel auf Lager" ist schwieriger zu verwalten, als Sachbearbeitung Antrag auf "Baugenehmigung für Gaubenfenster". Der Bauantrag ist Datentechnisch autark und wird auch mit 100 Clients die ähnliches machen, nicht so problematisch wie der Abverkauf limitierter (realer) Artikel. Wenn 100 Clients sich um den letzten Artikel kloppen, mglw. noch der Preis verhandelt wird, wird es kniffelig (bei jeder DB, dann müssen Abläufe her, die diese Probleme berücksichtigen). so mal grob, je nachdem, was eigentlich genau das Problem ist. |
AW: MSSQL Server mit 100 Clients
Zitat:
Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst. |
AW: MSSQL Server mit 100 Clients
Zitat:
Ich denke alle Version < 2008 wird man praktisch nichts mehr "in the Wild" antreffen. Wir sperren mittlerweile alles < 2005 aktiv aus (Meldung Programmstart). |
AW: MSSQL Server mit 100 Clients
Zitat:
Wenn es normal ist das z.B. 1 Stunde auf einen Datensatz gearbeitet wird, wird man sich keine Freude machen, wenn der User erst nach 1 Stunde mitbekommt das seine Arbeit "für die Katz ist". Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen. |
AW: MSSQL Server mit 100 Clients
Zitat:
Daraus leite ich ab, dass es innerhalb dieser Versionen weitgehend ähnlich ist und danach (>2012) weitere Verbesserungen kamen. Kann natürlich sein, dass die Seite auch einfach älter war, ich verfolge das nicht aktiv bei MS. "ein Sperren des Datensatzes würde ich nicht.." Sehe ich auch so, (unnötige) Sperren engen das System ein, vermutlich irgendwie exponentiell oder so. Also wäre optimistic locking angesagt. Sprich wenn's mal "knallt" gibt's eine nette Meldung, die Eingaben sind futsch, der User bekommt sofort ne Info und muss nacharbeiten. Hier ist es dann eine Frage des Programmaufwandes, elegant abzufangen und geänderte Werte zu retten usw. Hab mal irgendwo in uralten Dot Net Komponenten die generierten DML Commandos von V Studio gesehen, wo die where clause aus der Nennung sämtlicher Felder bestand. Fand ich sehr witzig, dachte zuerst, der hat den PK nicht gefunden, aber im Grunde ist es ein einfacher clientseitiger Schutzmechnismus für optimistic locking. Grundsätzlich könnte man Sperrprobleme mit sowas wie Kontingenten auf fachlicher Ebene regulieren, sehr einfach und unintelligent, aber ziemlich sicher. Jeder (angemeldete) User bekommt einen Range von Daten, die nur er bearbeiten darf/kann. Das passt sicher nicht für alle Workflows, aber oft reicht es. |
AW: MSSQL Server mit 100 Clients
Zitat:
Zitat:
Richtig spanned wird es dann, wenn zu dem Datensatz noch etliche abhängige Datensätze gehören, die womöglich noch alle mit gesperrt werden müssen. Zitat:
|
AW: MSSQL Server mit 100 Clients
Zitat:
 TUpdateMode (Wiki) im Auge behalten. In den Tokyo FireDACs steht der TUpdateMode z.B. im Standard auf upWhereKeyOnly - ein upWhereAll oder upWhereChanged wäre je nach Anforderung zu überlegen. |
AW: MSSQL Server mit 100 Clients
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. |
AW: MSSQL Server mit 100 Clients
Zitat:
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. |
AW: MSSQL Server mit 100 Clients
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. |
AW: MSSQL Server mit 100 Clients
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. |
AW: MSSQL Server mit 100 Clients
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. |
AW: MSSQL Server mit 100 Clients
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 |
AW: MSSQL Server mit 100 Clients
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 ! |
AW: MSSQL Server mit 100 Clients
Kommt auf das Locking-Verfahren an.
|
AW: MSSQL Server mit 100 Clients
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? |
AW: MSSQL Server mit 100 Clients
Das Stichwort ist Lock Escalation bzw table hints.
Siehe auch: https://docs.microsoft.com/en-us/sql...ql-server-2017Wenn 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. |
AW: MSSQL Server mit 100 Clients
Zitat:
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, .. |
AW: MSSQL Server mit 100 Clients
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 |
AW: MSSQL Server mit 100 Clients
Zitat:
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" ;) |
AW: MSSQL Server mit 100 Clients
Zitat:
So kann man den Mehrbenutzerzugriff auch realisieren. Wenn natürlich mehrere User das gleiche Feld bearbeiten (z.B. Preis) und auch noch was unterschiedliches reinschreiben, dann ist das natürlich Sinnfrei ..... Ansonsten muss man das aus vom Datenbankaufbau berücksichtigen: z.B. Bemerkungen, hier könnten gleichzeitig mehrer Benutzer was reinschreiben wollen, dann muss man den aufbau z.B. über eine 1zun Beziehung machen ...... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 10:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz