MSSQL Server mit 100 Clients

[egentur]

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 !

[Uwe Raabe]

Zitat:

Zitat von egentur (Beitrag 1400850)

Was ist hier der beste Ansatz, damit gegenseitiges Blockieren u.ä. verhindert wird ?

Was meinst du denn mit Blockieren?

[egentur]

Zitat:

Zitat von Uwe Raabe (Beitrag 1400851)

Zitat:

Zitat von egentur (Beitrag 1400850)

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.

[jobo]

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.

[Uwe Raabe]

Zitat:

Zitat von egentur (Beitrag 1400853)

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.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1400854)

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

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1400855)

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.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1400856)

Zitat:

Zitat von jobo (Beitrag 1400854)

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.

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1400857)

Es wird immer auf dem Anwendungsfall ankommen.

Sicher.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1400857)

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.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1400857)

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.

[timog]

Zitat:

Zitat von Uwe Raabe (Beitrag 1400859)

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.