Gemeinsame Datenbank

[Art_hur]

Hi Leute,

erst einmal allen ein frohes neues Jahr!

Ich habe eine Anwendung geschrieben (MS VB 2010 Express), welche auf eine Datenbank (MS SQLServer 2008 Management Studio) zugreift. So weit so gut - alles funktioniert bestens.
Ziel des Ganzen ist aber, dass das Programm auf mehreren Rechnern läuft (es geht hier um unterschiedliche Filialen einer Firma) - im Moment sind es 3 - und alle auf die gleiche Datenbank zugreifen. In der Datenbank werden aktuelle Aufträge mit verteilten Zuständigkeiten gespeichert.
Die Rechner habe ich via VPN in einem Netzwerk zusammengefasst.

Mein Problem ist, dass mir hier komplett der Ansatz fehlt. Wie kann man das realisieren?
Ich habe bereits versucht, über Netzwerk auf die gleiche Datenbankdatei zuzugreifen: wird mit Fehlermeldung (... Eine Datenbank mit diesem Namen ist bereits vorhanden, die angegebene Datei kann nicht geöffnet werden, oder sie befindet sich in der UNC-Freigabe) abgelehnt, ich habe versucht, die Datenbakdatei nach einer Änderung (und nach Schließen der Verbindung) auf die anderen Rechner zu kopieren: wird mit Fehlermeldung (wird verwendet, kann nicht kopiert werden) abgelehnt ...

Hat jemand eine Idee / einen Tipp?

Besten Dank im Voraus!

Ciao Arthur

[Bernhard Geyer]

Stichwort wäre hier Replikation.
Du hast in den Filialen die kleinen Serverversion welche sich per Replikation mit der Zentrale abgleichen.
Nötig ist in der Zentrale eine größerer Version und auch die Anwendungen müssen Replikationsfähig sein.

[hwoess]

Das Management Studio ist ein Werkzeug für die Verwaltung des SQL-Servers und keine Datenbank.
Wenn man mit einem "richtigen" SQL-Server (SQL Express und aufwärts) arbeitet, kann man, sofern man eine öffentliche IP für den Router mit dem Netz, in dem der SQL Server steht, hat, diesen so konfigurieren, dass man auch von aussen mittels dieser IP-Adresse (und ev. Portnummer) sogar ohne VPN auf den SQL-Server zugreifen kann (natürlich verschlüsselte Verbindung, schon beim Login). Habe das bei vielen meiner Kunden erfolgreich im Einsatz.

bye,
Helmut

[tömmel]

ähmm...
Also das "Management Studio" ist das Verwaltungstool - ich gehe mal frech davon aus, dass er die express edition mit "Management Studio" heruntergeladen und installiert hat...

Allerdings kann ich nicht soweit hellsehen, ob er eine Replikation braucht - wenn die VPN stabil und schnell genug ist, sehe ich das Problem nicht - sind die Rechner doch 'normal' im Netwerk erreichbar.

vielleicht sehe ich aber auch nur das Problem nicht...

[Bernhard Geyer]

Wenn man mit einem "richtigen" SQL-Server (SQL Express und aufwärts) arbeitet, kann man, sofern man eine öffentliche IP für den Router mit dem Netz, in dem der SQL Server steht, hat, diesen so konfigurieren, dass man auch von aussen mittels dieser IP-Adresse (und ev. Portnummer) sogar ohne VPN auf den SQL-Server zugreifen kann (natürlich verschlüsselte Verbindung, schon beim Login). Habe das bei vielen meiner Kunden erfolgreich im Einsatz.

Wenn die Standorte zu weite auseinander sind kannst du dir damit aber sehr leicht ein Performancegrab ins Haus holen. Hatten schon den Fall das eine IT unbedarft den DB-Server im Süddeutschen Raum betreiben wollte und die zugreifende Anwendung in Norddeutschland. Hatten sich dann gewundert das viele Anwendungen erheblich langsamer waren.

[tömmel]

Naja - kommt meiner Meinung nach auch immer auf den konkreten Anwendungsfall und die Problemstruktur an. Das muss man aber bei der Enticklung einer Lösung berücksichtigen. Auch Replikation muss keine Lösung sein. Genau genommen kann man soeine Frage garnicht beantworten wenn man die Aufgabenstellung und Gegebenheiten nicht kennt.

Ich weiss ich krieg da wieder haue - aber das ist so eine Frage, die ich mir stelle, bevor ich eine Anwendung entwickle

[hwoess]

Wenn die Standorte zu weite auseinander sind kannst du dir damit aber sehr leicht ein Performancegrab ins Haus holen

Das liegt normalerweise nicht daran, dass die Standorte zuweit auseinander sind, sondern an zwei zusammenfallenden Problempunkten:
a) der Serverstandort hat eine zu langsame (meistens asynchrone) Internetanbindung, ich sehe da bei meinen kleineren Kunden zB. beim Server manchmal nur 0,7 MBit Upstream, gerade der wird aber gebraucht, wenn externe Standorte zugreifen. Und diesen Upstream müssen sich alle teilen, die gleichzeitig zugreifen, mit jedem weiteren Standort wird es also immer schlimmer!
b) die Applikation wurde so programmiert, dass immer viel mehr Daten vom Server geholt werden als man eigentlich braucht.

Wenn also die Internetleitung die vom Server weg die Daten an die Aussenstellen liefert, zu schwach dimensioniert ist und außerdem die Anwendung zu viele Daten holt, dann kann das mit dem Performancegrab natürlich schnell passieren. Da ist es aber dann egal, ob der Abstand zwischen den Standorten 50 Km oder 5000 Km ist.

Der Vorteil bei einer verteilten Datenbank mit Replikation ist natürlich die Unabhängigkeit von einem Zentralserver, aber dafür muss man sich um die Datenabgleiche kümmern, die auch nicht gerade trivial sind.
Und man hat auch meistens keinen aktuellen Stand der Gesamtdaten. Wenn man damit leben kann ist's okay, wenn nicht, dann geht das mit Replikation sowieso nicht.
Ich sehe das also Konzeptfrage, beide Lösungen haben ihre Vor- und Nachteile.

bye,
Helmut

[Bernhard Geyer]

Das liegt normalerweise nicht daran, dass die Standorte zuweit auseinander sind, sondern an zwei zusammenfallenden Problempunkten:
a) der Serverstandort hat eine zu langsame (meistens asynchrone) Internetanbindung, ich sehe da bei meinen kleineren Kunden zB. beim Server manchmal nur 0,7 MBit Upstream, gerade der wird aber gebraucht, wenn externe Standorte zugreifen. Und diesen Upstream müssen sich alle teilen, die gleichzeitig zugreifen, mit jedem weiteren Standort wird es also immer schlimmer!
b) die Applikation wurde so programmiert, dass immer viel mehr Daten vom Server geholt werden als man eigentlich braucht.

Ist hier nicht der Fall gewesen. Hier waren/sind es einfach das viele Einzelabfragen die nötig sind um alle nötigen Informationen für das Arbeiten zu bekommen.
Und jede Abfrag ist nun mal mit maximal Lichtgeschwindigkeit (im Idealfall) unterwegs. Nun kann man sich ausrechnen um wie viel solche Abfragen langsamer werden wenn Anwendung und DB z. B. 600 km auseinander liegen.
Sicherlich kann man versuchen diese Einzelabfragen über eine Monster-Abfrage zusammenzufassen. Ist aber nicht unerheblicher Aufwand und wenn man 99% Kunden hat welche diese Problem nicht haben wird man wohl sich eher an den SW-Teilen optimierungen vornehmen die 99% der Kunden was bringt :-)

[hwoess]

Wenn ich mal grob 300.000 Km/Sekunde bei der Lichtgeschwindigkeit annehme, dann braucht das Licht ca. 2-tausendstel Sekunden für diese 600 Km. Kann mir keiner sagen, dass man das merkt, wenn eine einzelne Abfrage 2-tausendstel länger braucht. Und wenn ich 100 Abfragen hintereinander brauche, um einen Bildschirm aufzubauen, dann würde das, wäre nur die Distanz der maßgebliche Faktor, gerade mal 2-zehntelsekunden länger dauern als in der Zentrale. Ärgert sich ein Anwender über sowas? Nein, würde ich mal behaupten.
Wenn ich aber in der Firma ein Gigabit-Netz habe (also 1000 MBit) und im Gegensatz dazu dann alle Aussenstellen zusammen gemeinsam über einen 1 MBit-Flaschanhals müssen, braucht man sich nicht zu wundern, dass Applikationen draußen plötzlich einknicken, sobald es zu einer Datenabfrage kommt. Passiert besonders gerne bei "select * from tabelle" - also ohne Feldangaben und where-Klausel.
Meistens erfolgt der Test des Programmierers mit 3 Datensätzen in der Testdatenbank, der Kunde hat aber dann 30.000 Datensätze drinnen und alle wundern sich, warum das Ganze auf einmal unbrauchbar wird :-)

bye,
Helmut

[Ralf Jansen]

Kann mir keiner sagen, dass man das merkt, wenn eine einzelne Abfrage 2-tausendstel länger braucht.

Dein Blick ist ein wenig auch einen bestimmten Anwendungstyp eingegrenzt. Natürlich gibt es auch Anwendungen wo jede Millisekunde zählt insbesondere wenn nicht direkt User beteiligt sind. Blödes Beispiel die in New York ansässigen Hedgefonds haben sich kürzlich gerade für einen dreistelligen Millionenbetrag ein eigenes Überseekabel nach London geleistet. Mit lächerlicher Bandbreite aber höhere Signalausbreitungsgeschwindigkeit als Standard Glasfaser. Und nun haben die anstatt 60ms einen Ping von 55ms. In deren Geschäftsfeld ist jede Millisekunden Milliarden wert. Ist in anderen Bereichen sicher nicht so krass aber auch wichtig.

[tömmel]

ähm... räusper mal abgesehen davon, dass es nicht die Rolle spielt wie weit weg so'n Rechner steht... aber die Lichtgeschwindigkeit für die Luftlinie anzusetzen - das hat schon was vom Milchmädchen.
Da sind Pakete unterwegs - da wird von Server zu Server gecheckt ob alles ankommt usw. da wird keineLichtgeschwindigkeit erreicht....

[hwoess]

Klar, Lichtgeschwindigkeit und Luftlinie sind natürlich ziemlich theoretisch. Aber es sollte ja nur als Beispiel dienen, in welchen Bereichen wir uns bewegen und dass das Problem bei einer Applikation, die beim Öffnen der Kundenstammdatei 3 Minuten steht, nichts mit der Entfernung zu tun hat. Eine Webseite von einem amerikanischen Server kann ja, wenn alles passt, auch fast im Moment des Link-Anklickens da sein, während man auf eine Seite von einem Server aus dem Nachbarbundesland manchmal wartet und wartet und wartet ...

bye,
Helmut

PS: so, genug OffTopic - ziehe mich damit aus diesem Thread zurück (nicht weil ich auf irgendwen sauer bin, ich will's nur nicht zu breit treten)

[Bernhard Geyer]

Wenn ich mal grob 300.000 Km/Sekunde bei der Lichtgeschwindigkeit annehme, dann braucht das Licht ca. 2-tausendstel Sekunden für diese 600 Km. Kann mir keiner sagen, dass man das merkt, wenn eine einzelne Abfrage 2-tausendstel länger braucht. Und wenn ich 100 Abfragen hintereinander brauche, um einen Bildschirm aufzubauen, dann würde das, wäre nur die Distanz der maßgebliche Faktor, gerade mal 2-zehntelsekunden länger dauern als in der Zentrale. Ärgert sich ein Anwender über sowas? Nein, würde ich mal behaupten.

Lichtgeschwindigkeit ist theoretisches Maximum. Wollte eigentlich schreiben das nur bei dieser Geschwindigkeit die Entfernung keine Rolle spielen würde.

Es ist eher so das bei dieser entfernung im WAN die "SQL-Ping"-Zeit von 1 ms auf einmal 20 ms dauert. Dann benötigen die 100 Abfragen schon 2 Sekunden.

Meistens erfolgt der Test des Programmierers mit 3 Datensätzen in der Testdatenbank, der Kunde hat aber dann 30.000 Datensätze drinnen und alle wundern sich, warum das Ganze auf einmal unbrauchbar wird :-)

Solche Fälle hatten wir auch schon. Aber das kann man oft sehr schnell beheben. Das Problem der Ping-Zeiten aber nur sehr Aufwändig.

[SQL-Rookie]

Ich habe eine Anwendung geschrieben (MS VB 2010 Express), welche auf eine Datenbank (MS SQLServer 2008 Management Studio) zugreift. So weit so gut - alles funktioniert bestens.
Ziel des Ganzen ist aber, dass das Programm auf mehreren Rechnern läuft (es geht hier um unterschiedliche Filialen einer Firma) - im Moment sind es 3 - und alle auf die gleiche Datenbank zugreifen. In der Datenbank werden aktuelle Aufträge mit verteilten Zuständigkeiten gespeichert.
Die Rechner habe ich via VPN in einem Netzwerk zusammengefasst.

Mein Problem ist, dass mir hier komplett der Ansatz fehlt. Wie kann man das realisieren?
Ich habe bereits versucht, über Netzwerk auf die gleiche Datenbankdatei zuzugreifen: wird mit Fehlermeldung (... Eine Datenbank mit diesem Namen ist bereits vorhanden, die angegebene Datei kann nicht geöffnet werden, oder sie befindet sich in der UNC-Freigabe) abgelehnt, ich habe versucht, die Datenbakdatei nach einer Änderung (und nach Schließen der Verbindung) auf die anderen Rechner zu kopieren: wird mit Fehlermeldung (wird verwendet, kann nicht kopiert werden) abgelehnt ...

Hat jemand eine Idee / einen Tipp?

Besten Dank im Voraus!

Ciao Arthur

Also, bevor hier noch weiter über Lichtgeschwindigkeit philosophiert wird, mal die Frage an Art_hur, ob deine Frage beantwortet ist.
Ansonsten könnte ich Dir sicherlich weiterhelfen. Ich habe genau so etwas umgesetzt und im Einsatz. Bei mir funktioniert der Zugriff über VPN auf die Datenbank bestens, wobei die Anzahl der Datensätze in der Anwendung auch eher übersichtlich ist. Das liegt aber daran, dass der SQL-Server die Daten vorher selektiert und nur die Daten über das Netz gehen, die auch benötigt werden.

Wenn also noch Fragen sind, einfach melden ...

[Wernfried]

Ihr nehmt hier nicht wirklich die Lichtgeschwindigkeit als Argument für eine langsame oder schnelle Verbindung.

In diesem Fall müsste man eine Funkverbindung nehmen weil 300'000 km/s die Vakuum-Lichtgeschwindigkeit ist. In der Glasfaser (egal welche Art oder welcher Hersteller) beträgt die Geschwidigkeit von Licht "nur" ca. 200'000 km/s -> siehe Brechungsindex.

Gruss