AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken MSSQL Server mit 100 Clients
Thema durchsuchen
Ansicht
Themen-Optionen

MSSQL Server mit 100 Clients

Ein Thema von egentur · begonnen am 29. Apr 2018 · letzter Beitrag vom 10. Jun 2018
Antwort Antwort
Seite 1 von 3  1 23      
egentur

Registriert seit: 27. Sep 2006
Ort: Freising
60 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#1

MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 12:00
Datenbank: MSSQL • Version: 2012 • Zugriff über: AnyDAC
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 !
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.475 Beiträge
 
Delphi 12 Athens
 
#2

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 12:08
Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ?
Was meinst du denn mit Blockieren?
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
egentur

Registriert seit: 27. Sep 2006
Ort: Freising
60 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#3

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 12:21
Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ?
Was meinst du denn mit Blockieren?
Wenn verschiedene Clients den gleichen Datensatz bearbeiten wollen z.B.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#4

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 12:34
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.475 Beiträge
 
Delphi 12 Athens
 
#5

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 13:10
Wenn verschiedene Clients den gleichen Datensatz bearbeiten wollen z.B.
AnyDAC/FireDAC lassen die gleichzeitige Bearbeitung eines Datensatzes erst einmal zu. Beim Zurückschreiben wird aber geprüft, ob sich der Datensatz zwischenzeitlich geändert hat. Falls ja gibt es einen Event, den du entsprechend behandeln musst. Notfalls bekommt der User die Änderungen angezeigt und muss selbst entscheiden wie damit umzugehen ist.

Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.202 Beiträge
 
Delphi 10.4 Sydney
 
#6

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 13:11
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.
Solche alten MS SQL ohne solche Fähigkeiten braut man heutzutage nicht mehr berücksichtigen.
Ich denke alle Version < 2008 wird man praktisch nichts mehr "in the Wild" antreffen. Wir sperren mittlerweile alles < 2005 aktiv aus (Meldung Programmstart).
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.202 Beiträge
 
Delphi 10.4 Sydney
 
#7

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 13:13
Ein Sperren des Datensatzes zur Bearbeitung würde ich persönlich nicht realisieren. Das bringt mehr Probleme als es löst.
Es wird immer auf dem Anwendungsfall ankommen.
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#8

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 13:30
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.
Solche alten MS SQL ohne solche Fähigkeiten braut man heutzutage nicht mehr berücksichtigen.
Ich denke alle Version < 2008 wird man praktisch nichts mehr "in the Wild" antreffen. Wir sperren mittlerweile alles < 2005 aktiv aus (Meldung Programmstart).
Gut hier ist es ja 2012. Hab neulich noch eine Seite gesehen (MS), die das Sperrverhalten für die Versionen 2005-2012 zusammengefasst beschrieb.
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.475 Beiträge
 
Delphi 12 Athens
 
#9

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 13:38
Es wird immer auf dem Anwendungsfall ankommen.
Sicher.

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".
Genauso wird der zweite Benutzer vielleicht knatschig, weil er seine Mini-Änderung eine Stunde lang nicht unterbringen kann. Wenn dieser andere Client eine Applikation ist, die nur ein eh automatisch verwaltetes Statusfeld aktualisieren will, kann das schon erhebliche Auswirkungen auf den Betriebsablauf haben.

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.

Ein Mergen der Änderungen wird für die meisten Nutzer zu komplex sein um Sie praktikabel zu Nutzen.
Da stimme ich dir zu. Aus meiner Erfahrung sind aber in der Regel nur nicht-relevante Felder betroffen, da die Sachbearbeiter meistens nicht-überlappende Daten ändern. Hier kann man durch anwendungsspezifisches Setzen der ProviderFlags für jedes Feld schon einen Großteil der Kollisionen vermeiden. Das erfordert natürlich ein umfassendes Wissen über die Beziehungen der einzelne Felder untereinander. In der Praxis kommen dann echte Kollisionen kaum noch vor.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von timog
timog

Registriert seit: 26. Sep 2006
Ort: Landkreis Oldenburg (Oldb)
117 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#10

AW: MSSQL Server mit 100 Clients

  Alt 29. Apr 2018, 14:58
Hier kann man durch anwendungsspezifisches Setzen der ProviderFlags für jedes Feld schon einen Großteil der Kollisionen vermeiden.
Stichwort ProviderFlags bei FireDAC (wie ist das bei AnyDAC?): 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.
Timo
Real Programmers are surprised when the odometers in their cars don't turn from 99999 to 9999A.

Geändert von timog (29. Apr 2018 um 15:03 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23      

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:46 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz