none
Datenbankspiegelung für ca. 40 DB's auf 32 Bit Server? RRS feed

  • Frage

  • Liebe ForenUser!

    Mein erster Beitrag hier, vielleicht kann mir ja geholfen werden.
    Steh vor einem mittelgroßen Problem. Habe zum Ziel einen SQL Server 2005 SP2 ausfallsicher zu machen. Ich habe mich diesbezüglich für die Datenbankspiegelung entschieden. Konfiguration ist echt einfach und überschaubar. Habe das Ganze für 3 parallele DB's getestet und funktionierte wunderbar. Nun habe ich (durch Zufall) gelesen, dass die Datenbankspiegelung nur für ca. 10 DB's parallel funktioniert. Auf dem Server haben wir jedoch 42 Datenbanken, welche jetzt nicht wirklich 100% Auslastung haben, jedoch ein Ausfall derer kritisch wäre.
    Server ist ein Windows Server R2 mit 4 GB RAM.

    Vielleicht hat hier jemand Erfahrungswerte, bzw. kann er mir andere Hochverfügbarkeitsszenarien empfehlen.
    Hab auch schon daran gedacht, die zeitkritischen DB's zu spiegeln und für die anderen LogShipping zu implementieren.

    Bin für jeden Tip dankbar!
    Mit besten Grüßen & Danke
    Norbert
    Dienstag, 28. Juli 2009 06:58

Antworten

  • Hallo Norbert,

    erster Schritt für eine verbesserte Ausfallsicherheit wäre das Einspielen des aktuellen Service Pack 3 ,
    sofern das mit SP2 kein Verschreiber war.

    Die Aussage, das ginge nur bis 10 Datenbank wird zwar oft als Limitation genannt,
    aber um eine feste Größe handelt es sich dabei nicht, siehe z. B.:
    http://blogs.msdn.com/mikewat/archive/2007/07/28/database-mirroring-and-log-shipping-which-is-better.aspx
    Vielmehr steigt mit der Anzahl der Datenbanken auch die Anforderung
    an die Netzwerkverbindungen usw., so dass die auch die Hardware mitspielen muß.

    Aber wenn es Dir um Hochverfügbarkeit geht, ist Datenbankspiegelung nicht das Allheilmittel.
    Fragen solltest Du Dich, was Du mit Deinen zwei Servern optimalerweise erreichen kannst.

    Stehen die beiden Server in einem Raum oder hängen an der gleichen Sicherung, sichert Dir
    das Mirroring nur den Ausfall eines Rechners ab. Wenn das Kabel durchschmort, der Rechnerraum
    unter Wasser steht oder was man sonst so an Schreckensszenarien erfinden kann, hilft Dir das nur wenig ;-)

    Was damit gesagt sein soll: Eine Datenbankspiegelung kann eine Sicherungskonzept nicht ersetzen,
    sondern nur ergänzen. Und die Wiederherstellung im Notfall sollte immer funktionieren.

    Wenn Du 42 Datenbanken auf einem Server betreust, so vermute ich, das nicht alle gleich intensiv genutzt werden.
    Und wenn das so wäre, überlege welchen Aufwand ein Failover für alle bedeuten würde, wenn nur  mal eine
    Stunde ein Rechner ausfällt - kriegst Du das Umschalten und spätere Zurücksetzen in der Zeit umgesetzt?
    Auch da wirst Du einen Kompromiss finden müssen, um die wirklich notwendigen Datenbanken am Laufen
    zu halten, und für die anderen eine längere Auszeit einplanen müssen, je nach ihrer Priorität.

    In Hochverfügbarkeitslösungen Übersicht werden die derzeit vier Möglichkeiten genannt,
    die Verfügbarkeit zu verbessern. Einen Failover-Cluster schliesse ich mal aus, da das zusätzliche
    (Geld)mittel erfordert, wenn Du den nicht hast.

    Da Du immer sichern mußt, hat der Protokollversand den Vorteil, dass er es sich für die
    "unwichtigeren" Datenbanken gut integrieren läßt, zum Nachteil das Du manuell eine
    Umschaltung vornehmen mußt, sollte der Ausfall länger andauern.

    Du solltest Dir Hohe Verfügbarkeit: Interoperabilität und Koexistenz durchlesen, um die
    jeweiligen Kombinationsmöglichkeiten, die für Deine Situation am besten sind auszuwählen.
    Der von Christoph genannte Artikel zeigt, wie Du bei geänderter Sachlage eine
    Datenbank von Versand auf Spiegelung (oder umgekehrt) anpassen kannst.

    Prüfen solltest Du auch, ob die Anwendungen die Datenbank nutzen mit Datenbankspiegelung
    klar kommen. Nicht jede reagiert darauf gnädig, vor allem wenn sie älteren Datums ist.
    Verwenden der Datenbankspiegelung beschreibt die Auswirkungen aus Sicht einer Anwendung.
    (Anwendungen, die nicht den Native Client oder SQL .NET Client verwenden, sondern noch mit
    den älteren Treibern aus dem MDAC arbeiten, können das nicht nutzen.)

    Gruß Elmar


    Freitag, 31. Juli 2009 09:03
    Beantworter

Alle Antworten

  • Hallo Christoph!

    Danke, hab mir das mal durchgelesen. Nur ist das nicht ganz das was ich in meinem Fall benötige.
    Hab nur 2 Server und Änderung der Hochverfügbarkeitsszenarien möchte ich auch nicht durchführen.

    Trotzdem irgendwann hilfreich denke ich.

    Vielleicht noch jemand grundlegende Designvorschläge?

    Beste Grüße
    Norbert
    Mittwoch, 29. Juli 2009 15:28
  • Hallo Norbert!

    Kennst du das Dokument?
    http://technet.microsoft.com/en-us/library/cc917680.aspx

    Viele Grüße
    Christoph
    Donnerstag, 30. Juli 2009 07:33
  • Danke!

    Kenn ich bereits. Nur was hat das eigentlich mit meiner Frage zu tun?
    Hier wird doch die DB-Spiegelung im Detail besprochen.

    Beste Grüße
    Norbert
    Donnerstag, 30. Juli 2009 10:55
  • Hallo Norbert,

    erster Schritt für eine verbesserte Ausfallsicherheit wäre das Einspielen des aktuellen Service Pack 3 ,
    sofern das mit SP2 kein Verschreiber war.

    Die Aussage, das ginge nur bis 10 Datenbank wird zwar oft als Limitation genannt,
    aber um eine feste Größe handelt es sich dabei nicht, siehe z. B.:
    http://blogs.msdn.com/mikewat/archive/2007/07/28/database-mirroring-and-log-shipping-which-is-better.aspx
    Vielmehr steigt mit der Anzahl der Datenbanken auch die Anforderung
    an die Netzwerkverbindungen usw., so dass die auch die Hardware mitspielen muß.

    Aber wenn es Dir um Hochverfügbarkeit geht, ist Datenbankspiegelung nicht das Allheilmittel.
    Fragen solltest Du Dich, was Du mit Deinen zwei Servern optimalerweise erreichen kannst.

    Stehen die beiden Server in einem Raum oder hängen an der gleichen Sicherung, sichert Dir
    das Mirroring nur den Ausfall eines Rechners ab. Wenn das Kabel durchschmort, der Rechnerraum
    unter Wasser steht oder was man sonst so an Schreckensszenarien erfinden kann, hilft Dir das nur wenig ;-)

    Was damit gesagt sein soll: Eine Datenbankspiegelung kann eine Sicherungskonzept nicht ersetzen,
    sondern nur ergänzen. Und die Wiederherstellung im Notfall sollte immer funktionieren.

    Wenn Du 42 Datenbanken auf einem Server betreust, so vermute ich, das nicht alle gleich intensiv genutzt werden.
    Und wenn das so wäre, überlege welchen Aufwand ein Failover für alle bedeuten würde, wenn nur  mal eine
    Stunde ein Rechner ausfällt - kriegst Du das Umschalten und spätere Zurücksetzen in der Zeit umgesetzt?
    Auch da wirst Du einen Kompromiss finden müssen, um die wirklich notwendigen Datenbanken am Laufen
    zu halten, und für die anderen eine längere Auszeit einplanen müssen, je nach ihrer Priorität.

    In Hochverfügbarkeitslösungen Übersicht werden die derzeit vier Möglichkeiten genannt,
    die Verfügbarkeit zu verbessern. Einen Failover-Cluster schliesse ich mal aus, da das zusätzliche
    (Geld)mittel erfordert, wenn Du den nicht hast.

    Da Du immer sichern mußt, hat der Protokollversand den Vorteil, dass er es sich für die
    "unwichtigeren" Datenbanken gut integrieren läßt, zum Nachteil das Du manuell eine
    Umschaltung vornehmen mußt, sollte der Ausfall länger andauern.

    Du solltest Dir Hohe Verfügbarkeit: Interoperabilität und Koexistenz durchlesen, um die
    jeweiligen Kombinationsmöglichkeiten, die für Deine Situation am besten sind auszuwählen.
    Der von Christoph genannte Artikel zeigt, wie Du bei geänderter Sachlage eine
    Datenbank von Versand auf Spiegelung (oder umgekehrt) anpassen kannst.

    Prüfen solltest Du auch, ob die Anwendungen die Datenbank nutzen mit Datenbankspiegelung
    klar kommen. Nicht jede reagiert darauf gnädig, vor allem wenn sie älteren Datums ist.
    Verwenden der Datenbankspiegelung beschreibt die Auswirkungen aus Sicht einer Anwendung.
    (Anwendungen, die nicht den Native Client oder SQL .NET Client verwenden, sondern noch mit
    den älteren Treibern aus dem MDAC arbeiten, können das nicht nutzen.)

    Gruß Elmar


    Freitag, 31. Juli 2009 09:03
    Beantworter
  • Hallo Norbert,

    Hat Dir die Antwort geholfen?

    Grüße,
    Robert

    Mittwoch, 26. August 2009 10:43
    Moderator
  • Hallo Norbert,

    Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.

    Grüße,
    Robert

    Dienstag, 1. September 2009 12:54
    Moderator
  • Hallo,

    falls jemand zu diesem Thema in diesem Thread sucht: Hier eine Technical Note von SQL CAT (02/2010):
    http://sqlcat.com/technicalnotes/archive/2010/02/10/mirroring-a-large-number-of-databases-in-a-single-sql-server-instance.aspx

    Viele Grüße
    Christoph
    Mittwoch, 24. Februar 2010 08:40
  • Hi

    Vielen, vielen Dank - die Antwort hat mir auf alle Fälle geholfen!
    Nun zum Szenario: Wir haben eine separate Backup Lösung, somit ist die Spiegelungslösung nur dazu da um die Ausfallzeit kurz zu halten. Ob nun alle DB's mit der Spiegelung klar kommen, kann ich erst nach dem Test sagen. Aber ich schätze du meinst den Eintrag im ConnectionString, orauf ein automatisches Failover möglich wird - von dem gehe ich sowoeso nicht aus. Jedenfalls habe ich die 40 DB's ca. in max. 10 Min wieder online, was den internen Anforderungen genügt. -
    so etwa:

    1.) Speigelungssitzung auflösen
    2.) Script zur Login/User Synchronisation einspielen
    3.) Script zum Enablen aller Jobs
    4.) Server unter neuem Domainnamen wieder starten (das ist eigentlich das aufwendigste bzw. zeitraubendste)

    Hab mir dazu ein Tool in .NET geschrieben, welches das alles über eine GUI macht.

    Schlussendlich ist die Spiegelungssitzung dazu da (bei uns) um schnell auf einen HW Ausfall reagieren zu können, nicht als Backup und nicht als 100 % ige Hochverfügbarkeitslösung - das bleibt wohl nur der Clusterlösung, welche jedoch wieder zusätzliches Know How und Kosten bedingt.

    So nach dem Motto - wenns schon implementiert ist, wieso nicht auch einsetzen...

    Nun aber genug gequatscht, vielen Dank für deine ausführliche Antwort!

    Gruß Norbert
    Freitag, 5. März 2010 08:13