2Gespiegelte Datenbanken die nur ein IP haben

[REDNose]

HI,

folgendes Senario....2Pc´s mit Server 2003 und SQLServer Enterprise Edition..

auf beiden pc´s ist die selbe daten bank gespiegel ich möchte die pc´s so mit einander verbinden das die datenbanken sich gegen seiteig helfen (lastenaufteilung)

UND von außen gibt es aber nur eine IP die direkt beide anspricht...ich hab gehört das es funktioniert man muss jeweils 2 neztwerkkarten oder so in die pc´s bauen, direkt verbindung zwischen den pc´s und dann raus an das switch etc..

habt ihr eine idee....?

[geloescht_JesterDay]

HI,

folgendes Senario....2Pc´s mit Server 2003 und SQLServer Enterprise Edition..

auf beiden pc´s ist die selbe daten bank gespiegel ich möchte die pc´s so mit einander verbinden das die datenbanken sich gegen seiteig helfen (lastenaufteilung)

[...]

habt ihr eine idee....?

du sagst es ja schon... lastenaufteilung...

-> http://www.elektronik-kompendium.de/sites/net/0904131.htm

[REDNose]

ja geht das aber auch mit der datenbank.....?

[ksg9-sebastian]

Soweit ich mir das angesehen hab hat das nix mit der Datenbank zu tun.

Das ist ein Gerät/Software, welche die Verbindung zu Rechner A oder eben Rechner B weiterleitet, je nach Last der Rechner..

Mit der Software hat das nix zu tun.

ABER: Wozu willst du sowas ? Es ist nicht ratsam, zweit Datenbanken mit dem gleichen Inhalt paralell zu betreiben, die kriegst du die Inhalte wieder synchronisiert ?

Ist doch ziemlich bescheiden, wenn ein Admin aus Datenbank A, Tabelle B nen Datensatz löscht, und der dann nach der nächsten Spiegelung plötzlich wieder da ist.

Besser den Rechner upgraden...

[REDNose]

wenn aber 500 leute auf eine datenbank zugreifen würde es schneller gehen wenn die zwei oder mehr sql server sich die last teilen würden...oder...?

[Amstelchen]

ich nehme mal stark, der OP will so etwas wie die sql server replikation verwenden.

Es ist nicht ratsam, zweit Datenbanken mit dem gleichen Inhalt paralell zu betreiben, die kriegst du die Inhalte wieder synchronisiert ?

das stimmt so nicht. es ist ja sinn der sache, inhalte auf mehrere standorten zu verteilen (zu replizieren), um die last einer einzelnen datenbank zu reduzieren. das sind z.b. clusterdatenbanken mit eben zwei bis mehreren dutzend nodes. mysql kann das grundsätzlich schon mal, sql server, oracle RAC, etc.

Besser den Rechner upgraden...

hä? was hat das jetzt mit der originalen aufgabenstellung zu tun?

jedenfalls, ich wüsste jetzt keine kostenlosen informationsquellen, wo replikation für sql server beschrieben wäre; eine usenet-group (microsoft.public.sqlserver.replication) existiert aber jedenfalls zur thematik.

s'Amstel

[ksg9-sebastian]

weiterlesen hilft...

das stimmt so nicht. es ist ja sinn der sache, inhalte auf mehrere standorten zu verteilen (zu replizieren), um die last einer einzelnen datenbank zu reduzieren

jo, aber das ganze muss gut durchdacht und realisiert sein, und nicht nur zwei Rechner, welche sich "irgendwie" die Last teilen.

Mich würde aber trotzdem interessieren, wie du die Replizierung sauber hinbekommst. Einfach mal am Abend Daten sichern ist ein _bisschen_ schlecht.

Wg. Cluster:

Da steckt ja auch ein bisschen mehr dahinter. Und _meistens_ wird durch Cluster die Ausfallsicherheit garantiert, und keine Lastenaufteilung.

[REDNose]

ich hab mir ein paar infos über clustering besorgt.....und werde es mal in angriff nehmen.....

das ziel ist einfach....ein programm was auf eine datenbank zu greift wird von mehreren 100 personen gleichzeitig genutzt....dabei ist meiner meinung nach EIN server überfordert....also (lastenteilung bzw. clustering)

[perdian]

das ziel ist einfach....ein programm was auf eine datenbank zu greift wird von mehreren 100 personen gleichzeitig genutzt....dabei ist meiner meinung nach EIN server überfordert....also (lastenteilung bzw. clustering)

Ein Server bei meheren hundert gleichzeitigen Usern als überlastet zu bezeichnen ist pauschal falsch. Was machen diese mehreren hundert User denn gleichzeitig? Kommen wirklich ständig Zugriffe auf die Datenbank, oder findet die Verarbeitung zum Großteil auf der Clientseite statt (auf Eingaben warten, Daten validieren, etc.) und nur ab und an wird auf die Datenbank geschrieben?

User als Bezugspunkte zu nehmen ist nie wirklich passend, weil du nie wirklich weisst, was ein User macht bzw. wie intensiv die Datenbankauslastung durch den einzelnen User ist. Bei relativ kurzen und schnell auszuführenden Datenbankanfragen kann ein Rechner sogar mehrere tausend User gleichzeitig bedienen, ohne dass du merkenswert an Performance verlierst. Führen allerdings die User ständig intensive Berechnungen durch (z.B. Statistikauswertungen über einen großen Datenbestand) dann wird es schon recht schnell recht resourcenintensiv.

Die Kenngröße sind also die Zugriffe auf die Datenbank - nicht die Anzahl der User, die diese Anfragen durchführt.

[Honkytonk]

Im Grunde genommen kann ich perdi nur zustimmen. Die Last auf dem Server geht von den User-Aktionen aus, nicht von den Connections. Wenn ein SQL-Server schon bei mehreren hundert User ins Schwimmen kommt, würde ich zunächst die Datenbank genauer untersuchen.

Ein einfacher Trace auf die einzelnen Batches / Anfragen an das System bringt es in der Vielzahl von Fällen und zeigt Schwachstellen im Datenbankdesign auf. (Fehlende Indizes, falsche Ausführungspläne etc.) Hilfreich ist es zudem auf Tabellen mit vielen Bewegungsdaten den Index regelmäßig zu defragmentieren. (Geht sowohl wenn die DB offline oder online ist)

Ein weiterer Schwachpunkt eines Systems kann das Storage auf dem die Datenbankfiles sein. Langsame Platten können den Server bei IO-lastigen Aktionen auch in die Knie zwingen.

Replikation kann eine feine Sache sein, wird dich aber in diesem Falle nicht besonders weiter bringen, da du nicht Publisher und Subscriber im Kreise sein solltest / sein darfst. Dies löst ähnlich wie bei Excel Zirkelbezüge aus. Nach den Erfahrungen, die ich damit in dem letzten Jahr gemacht habe, würde ich vermutlich immer versuchen darum herum zu kommen. Sie kann teilweise anfällig wie ein Zwei-Takt-Mofa sein, ein Datensatz kann sie mitunter zum Stillstand bringen. Außerdem wirst du bei Schemaveränderungen von publizierten Tabellen die Replikation wieder neu aufsetzen müssen. Außerdem stellt eine Replikation ganz neue Anforderungen an das Desaster Recovery Modell.

Was mit Replikation unter dem SQL Server 2000 gut machbar ist ist das Trennen einer Datenbank zwischen Produktions- und Auskunftssystem. Wenn du ein Programm hast in dem ein Hauptteil der Datenbank-Last aus Abfragen resultiert, kannst du diese Tabellen auf einen anderen Server replizieren lassen und die Abfragen dorthin ausrichten. Die Quell-Datenbank, die mit den Transaktionen beschäftigt ist, wird dadurch um einiges entlastet.

Interessant werden könnte in dieser Thematik der demnächst herauskommende SQL Server 2005 mit Mirroring. Leider hat Microsoft dieses Feature nicht bis zum eigentlichen Release fertig bekommen, so dass es erst nächstes Jahr mit einem Servicepack erscheinen soll.

Gruß,

Repl-Honky

[hades]

Ein einfacher Trace auf die einzelnen Batches / Anfragen an das System bringt es in der Vielzahl von Fällen und zeigt Schwachstellen im Datenbankdesign auf. (Fehlende Indizes, falsche Ausführungspläne etc.) Hilfreich ist es zudem auf Tabellen mit vielen Bewegungsdaten den Index regelmäßig zu defragmentieren. (Geht sowohl wenn die DB offline oder online ist)

Ergaenzend dazu die dazugehoerigen Tools des MS SQL Server 2000:

SQL Profiler, SQL Query Analyzer und der Indexoptimierungsassistent

Ein weiterer Schwachpunkt eines Systems kann das Storage auf dem die Datenbankfiles sein. Langsame Platten können den Server bei IO-lastigen Aktionen auch in die Knie zwingen.

Nicht nur langsame Platten koennen I/O-Performanceprobleme bereiten.

Weitere Ursachen koennen das gewaehlte RAID-Level sowie die nicht optimale Nutzung von Dateigruppen sein.

Interessant werden könnte in dieser Thematik der demnächst herauskommende SQL Server 2005 mit Mirroring.

Das Database Mirroring haelt auf einem zweiten DB-Server eine Kopie einer (ausgewaehlten) Datenbank im Wiederherstellungsmodus. Der Zugriff erfolgt immer auf die Primaere DB, die auf den Mirror gespiegelt wird.

Die Umschaltung zwischen der Primaeren DB und des Mirrors erfolgt entweder manuell oder mit Hilfe eines dritten SQL Server 2005 -dem Witness Server- (dieser kann nach MS-Aussagen auch eine SQL 2005 Express Edition sein) automatisch.

AFAIK ist das Database Mirroring in der Final vom SQL Server 2005 mit drin, es soll aber erst Anfang des naechsten Jahres offiziell unterstuetzt werden.

[Honkytonk]

AFAIK ist das Database Mirroring in der Final vom SQL Server 2005 mit drin, es soll aber erst Anfang des naechsten Jahres offiziell unterstuetzt werden.

Stimmt, muss ich dir recht geben. Habe die betreffende Mail leider nur überflogen. Auf der RTM ist es mit drauf.

Es wird so sein, dass das Feature mit extra Steps aktiviert werden muss. Mehr Infos gibts z.B. hier.

[REDNose]

Mehr Infos gibts z.B. hier.

03.11.2005 23:17

So wie ich das versanden hab is das eine datenban spiegelung, also 2 datenbanke die sich gegenseitig abgleichen......gibt normal ein failout,

es wird rtotzdem nur ein server genutzt, eine spiegelung nehme ich nur wenn ich eine hoche ausfallsicherheit brauche. oder.....

mir geht es ja um performence

ein server mit der DB hat alles zu bewältigen ist ja auch nur eine rechenleistung aber bei zwei sollte es ja dann besser werden..

ich werde heute ma ein test netzwerk aufbauen server 2003 enterprise ed

eition (wegen clustering) und sql server 2000.....

Ein einfacher Trace auf die einzelnen Batches / Anfragen an das System bringt es in der Vielzahl von Fällen und zeigt Schwachstellen im Datenbankdesign auf. (Fehlende Indizes, falsche Ausführungspläne etc.) Hilfreich ist es zudem auf Tabellen mit vielen Bewegungsdaten den Index regelmäßig zu defragmentieren. (Geht sowohl wenn die DB offline oder online ist)

ich denke eher weniger, die datenbank is von unseren chef entwicklern geschrieben und getestet und auch schon einige jahre im einsatz.

[Honkytonk]

mir geht es ja um performence

ein server mit der DB hat alles zu bewältigen ist ja auch nur eine rechenleistung aber bei zwei sollte es ja dann besser werden..

ich werde heute ma ein test netzwerk aufbauen server 2003 enterprise ed

eition (wegen clustering) und sql server 2000.....

Bescheidene Frage, die mich an dieser Stelle interessiert: Wie planst du denn den Zugriff auf einen gemeinsamen Datenpool denn nun zu realisieren?

ich denke eher weniger, die datenbank is von unseren chef entwicklern geschrieben und getestet und auch schon einige jahre im einsatz.

Nichts gegen eure "Chef-Entwickler", aber die oben beschriebenen Maßnahmen "Index-Defragmentierung" und "Betrachtung der Ausführungspläne" hängen stark mit Tabellendaten zusammen und kommen in den besten Familien vor. Ist, zumindest bei uns, auch ein Job eines DBA nicht nur primär eines Entwicklers

[REDNose]

Nichts gegen eure "Chef-Entwickler", aber die oben beschriebenen Maßnahmen "Index-Defragmentierung" und "Betrachtung der Ausführungspläne" hängen stark mit Tabellendaten zusammen und kommen in den besten Familien vor. Ist, zumindest bei uns, auch ein Job eines DBA nicht nur primär eines Entwicklers

Ja, nur die DB bewährt sich schon länger.... und sie funktioniert.....

Bescheidene Frage, die mich an dieser Stelle interessiert: Wie planst du denn den Zugriff auf einen gemeinsamen Datenpool denn nun zu realisieren?

für mich is clustering auch neuland, ich stell mir das so vor das einer von den beiden servern die kontrolle übernimmt und den anderen praktisch steuert (ganz grob ausgedrückt).

[Honkytonk]

Ja, nur die DB bewährt sich schon länger.... und sie funktioniert.....

Keine Frage, dass sie funktioniert. Nur: mein Auto funktioniert auch und muss trotzdem ab und zu gewartet werden. Es muss ja schließlich einen Grund geben warum du dir dieses Szenario überlegst.

für mich is clustering auch neuland, ich stell mir das so vor das einer von den beiden servern die kontrolle übernimmt und den anderen praktisch steuert (ganz grob ausgedrückt).

Da bin ich mal gespannt, ob du es hinbekommst. Halt uns darüber doch mal auf dem Laufenden. Habe übrigens gerade doch noch einen Link in unserer internen KB gefunden:

How to Install SQL Server 2000 Clustering

Nachtrag:

Wer suchet der findet.. die KB gibt noch mehr her:

Scalability and high availability of Microsoft SQL Server 2000 (Part 1)

Scalability and high availability of Microsoft SQL Server 2000 (Part 2)

+ Part 3 & 4 über die "Artikel des Autoren"-Suche

[REDNose]

coold anke für die links......

der Widows server 2003 Enterprise musste doch auch das können was der 2000 advaced server kann (auf das clustering bezogen)

[REDNose]

Windows 2000 Cluster Services must have been properly installed and configured.

ist das irgend wo auf der install cd weil im netz kann ich es nicht finden

[REDNose]

Gefunden

http://www.microsoft.com/windows2000/techinfo/planning/server/clustersteps.asp

[geloescht_JesterDay]

also ich bin auch der Meinung, eine DB sollte immernur einfach vorhanden sein. Und 100 Nutzeraktionen sollten keinen DB-Server aus dem Tritt bringen. Und aus eben diesem Grund, sind DB-Server, die mit viel Last zu tun haben, meist wirklich reine DB-Server (also nicht auf dem Rechner, wo der Webserver o.ä. läuft) und auch entsprechend ausgestattet.

Stell dir mal vor: Ein Benutzer will eine Rechnung ändern (z.B.). Er geht ins Programm und ändert sie. Der Load-Balancer verweisst ihd dabei auf den Server dbA. Gleichzeitig will UserB auch etwas an der Rechnung ändern, aber er will etwas anderes hinzufügen, was UserA eben nicht hat (und umgekehrt). Dieser wird aber vom Load-Balancer auf den Server dbB geleitet. Und jetzt? Wie synchonisierst du diese DB wieder? Es muss ja nichtmal nur um hinzufügen gehen, in dem fall wäre es noch möglich. Was wäre, wenn UserA die Rechnungsposition 1 um 50% resuziert, und UserB gleichzeitig (aber auf dem 2.Server) die Rechnungsposition 1 löscht. Welche Änderung hätte jetzt vorrang und wie willst du das dem User erklären, der sich beschwert, dass seine Änderung weg ist?

Eine DB spiegeln ist zu Backupzwecken gut, aber zur Lastverteilung auf jeden Fall Gift.

Und wenn du eine "intelligente" Verwaltung dazwischen schaltest, die genannte Probleme verhindern soll und für eine echtzeit Synchronisierung sorgt (was bringt es dir, wenn ein Datensatz angelegt wird, ein anderer ihn aber nicht sieht, weil er vom Load-Balancer auf den anderen Server geschickt wurde?), wirst du die Server wahrscheinlich mehr belasten, und das Ergebnis wird schlechter sein, als 1 Server allein.

Bei einem unserer Kunden (Europaabteilung eines weltweit tätigen Unternehmens) wurde vor 2-3 Monaten der DB-Server erneuert, zu einem Preis in der oberen Hälfte des 6-stelligen Bereichs. Das ist auch keine Lösung mit vielen verteilten DBs, sondern ein DB-Server, der für große Lasten ausgelegt ist.

Verteilung von Lasten erfolgt mittels eines Load-Balancers, aber bei Datenbanken ist das nur bei "statischen" Daten möglich. (Also Daten, auf die alle nur lesend zugreifen)

Alles andere ist, IMHO, nicht sinnvoll machbar.

[hades]

Ja, nur die DB bewährt sich schon länger.... und sie funktioniert.....

Versuchs trotzdem mal mit der Analyse.

Lange genutzte Indezies koennen durchaus nicht aktuell sein:

Stichworte zur Optimierung sind hier Aktualisierung der Statistik, Index-Rebuild und Index-Defragmentierung.

Auch kommt es vor, dass Stored Procedures zuerst schnell laufen und mit der Zeit langsamer werden koennen.

Hier hilft dann meist eine erneute Kompilierung der Stored Procedure.

[REDNose]

Stell dir mal vor: Ein Benutzer will eine Rechnung ändern (z.B.). Er geht ins Programm und ändert sie. Der Load-Balancer verweisst ihd dabei auf den Server dbA. Gleichzeitig will UserB auch etwas an der Rechnung ändern, aber er will etwas anderes hinzufügen, was UserA eben nicht hat (und umgekehrt). Dieser wird aber vom Load-Balancer auf den Server dbB geleitet. Und jetzt? Wie synchonisierst du diese DB wieder? Es muss ja nichtmal nur um hinzufügen gehen, in dem fall wäre es noch möglich. Was wäre, wenn UserA die Rechnungsposition 1 um 50% resuziert, und UserB gleichzeitig (aber auf dem 2.Server) die Rechnungsposition 1 löscht. Welche Änderung hätte jetzt vorrang und wie willst du das dem User erklären, der sich beschwert, dass seine Änderung weg ist?

1. in einem cluster gibt es nur eine datenbank und wenn einer was an einer darei verändert ist diese gelockt da kann kein anderer was ändern.

2. für das was du meinst gibt es konfliktlösungen....z.B.

1.per timestamp

2.der master gewinnt immer (wer hat mehr rechte)

3. konflikt tabelle (der admin bekommt eine tabelle der konflikte und muss diese durcharbeiten und sagen was korrekt ist.....)

[REDNose]

sorry die aufgaben stellung ist nun nicht mehr so korrekt...

am anfang hab ich an eine spiegelung gedacht.....da war alles noch neuland

aber jetzt hab ich ein wenig gelesen.....Clustering is schon etwas anderes...und hat nur indirekt was mit einer spiegelung zu tun

[geloescht_JesterDay]

1. in einem cluster gibt es nur eine datenbank und wenn einer was an einer darei verändert ist diese gelockt da kann kein anderer was ändern.

2. für das was du meinst gibt es konfliktlösungen....z.B.

1.per timestamp

2.der master gewinnt immer (wer hat mehr rechte)

3. konflikt tabelle (der admin bekommt eine tabelle der konflikte und muss diese durcharbeiten und sagen was korrekt ist.....)

Dann ist das aber ein DB-Server, eben geclustert (hast du ja auch schon gesagt in der nächsten antwort) und zu den Konfliktlösungen:

1. Per timestamp: der zuerst war oder der zuletzt war? Welche davon ist denn die richtige? Oder eine von beiden Änderungen wurde nur gemacht, weil die andere "nicht gemacht" wurde. Wie willst du das lösen? Unmöglich.

2. Dazu muss beim Synchronisieren viel mehr gemacht werden, als nur das Synchronisieren. Und was, wenn die Änderung vom Master falsch war und er den Nicht-Master zur Korrektur beauftragt hat, der aber auf dem zweiten Server gelandet ist? Und wenn die Synchronisierung in Echtzeit erfolgt, was hast du dann gewonnen? Die Änderungen werden dann eben von der Synchro gemacht, nicht vom Benutzer.

3. Wenn es wirklich eine DB ist, die vor Auslastung so in die Knie geht, dass sie verteilt werden muss, will ich nicht der Admin sein, der die Konflikte bearbeiten muss Zum einen werden es wohl ne ganze Menge sein und zum anderen kann er auch nicht immer alles nur durch den Vergleich von 2 Inhalten klären sondern muss dazu evtl. noch den Hintergrund der Änderung kennen etc. Viel Spass bei der Arbeit. Dann lieber ne langsame DB.

[mme]

Wenn die Datenbank sich schon länger bewährt hat, so wurde die vielleicht schon unter einer älteren Datenbankversion entwickelt und war damals vielleicht perfekt und nun mit der neuen Version arbeitet der Optimizer etwas anders und es sollte doch mal überprüft werden??

Ich verstehe nicht das sich hier einige nicht vorstellen können das Clustering bei oltp DBs nicht funktioniert? oder bezieht sich das nur auf eine Spiegelung. Oracle macht das doch nun schon ein paar Jahre..., wo ist das Problem?

Bei Oracle ist die Performancesteigerung bei einem zwei Knoten Cluster zwischen 0,9 und 1,6 fachen von einem Server. Der Faktor 0,9 tritt z.B. dann ein, wenn die Datenbank nicht ganz optimal designt ist...