SQL 2005 Datenbankspiegelung/Performance

[Hauch 10]

Tach,

 

also ich soll nun bei uns folgendes realisieren:

 

Momentan vorhanden ist eine VM mit W2K3 und MS SQL Server 2005. Die VM dient als reiner SQL Server. Dort befinden sich z.Z. 6 Datenbanken, die kleinste hat 7 MB, die größte 2 GB. Die größte Datenbank ist von ca. 170 Usern intensiv im Zugriff, die anderen Datenbanken sind nur begrenzt (max. 10 User pro DB) im Zugriff und wirken sich kaum auf die Performance aus. Nun sollen die Datenbanken im Betriebsmodus "Hohe Verfügbarkeit" auf eine andere VM auf einer anderen HW gespiegelt werden. Wie die Datenbankspiegelung funktioniert, ist mir klar. Der 2. Server ist auch soweit eingerichtet. Als Zeuge wird eine Express Instanz auf einer dritten HW eingesetzt.

 

Meine Frage ist nun nach Erfahrungsberichten bezüglich der Performance wenn eine DB im Modus "Hohe Verfügbarkeit" gespiegelt wird. Wirkt sich das ganze spürbar auf die Performance aus? Der VM sind momentan 1024 MB RAM zugeordnet, werde ich aber noch aufstocken. Die VMs liegen auf 10k SAS Platten im Raid 5.

 

Danke schonmal.

 

Grüße hauch

[phoenixcp 10]

Warum greift ihr für die hohe Verfügbarkeit auf keinen Cluster zurück?

 

Die VMs liegen auf 10k SAS Platten im Raid 5.

Sind die Datenbank- bzw.Logpartitionen der Server dort ebenfalls abgelegt oder liegen die (hoffentlich) auf separaten RAID's die als physikalische Datenträger in die VM eingebunden sind?

Der VM sind momentan 1024 MB RAM zugeordnet, werde ich aber noch aufstocken.

Würde ich dringend anraten. Ein SQL Server entwickelt seine höchste Performance, wenn er die KOMPLETTE DB im RAM halten kann. Das würde für deinen Fall also min. eine Verdreifachung des Speichers bedeuten. Der SQL Server würde dann min. 2048 MB RAM fest zugeordnet bekommen, so das noch 1 GB für das System runddrum verfügbar ist. Wenn die DB's weiter wachsen sollen,würde ich auch über eine weitere Aufstockung des RAM auf 4 oder mehr GB (dann natürlich nicht mehr mit ner W2k3 Std realisierbar) proaktiv nachdenken.

 

Off-Topic:

BTW: Ich persönlich würde einen Datenbankserver nie virtualisieren...

[NilsK 2.969]

Moin,

 

die Performance hängt von vielen Faktoren ab. Ich stimme Carstens Einschätzung zu, dass 1 GB RAM für einen SQL Server nicht eben viel ist, wenn er mehrere DBs hostet und dabei auch noch spiegeln soll. Letztlich kann man hier aber nur ins Blaue zielen, wenn man die konkrete Auslastung nicht kennt.

 

Optimierungsmöglichkeiten beim Mirroring betreffen vor allem die Verbindung zwischen den beiden Hosts: Da kann es sinnvoll sein, einen dedizierten Link zu nehmen und alles andere darauf abzuschalten. Wenn man die Enterprise Edition einsetzt, kann man auch mehrere Threads für das Mirroring nutzen (oder so ähnlich; dazu gibt es Whitepapers bei MS, die du relativ einfach auffinden können solltest).

 

Wenn man es ordentlich aufbaut, kann man ein Mirroring-System hoch performant aufbauen. Ob man derartige Optimierungen braucht, kann man ohne Kenntnis des Systems nicht recht sagen.

 

Bei der Abgrenzung Cluster/Mirroring sind diverse Dinge zu beachten, u.a.: Mirroring ist pro DB (nicht pro Server) und setzt einen geeigneten Client voraus - Clustering nicht. Dafür braucht Clustering ein gemeinsames Storage und zwei Enterprise-Windows.

 

Gruß, Nils

[phoenixcp 10]

Bei der Abgrenzung Cluster/Mirroring sind diverse Dinge zu beachten, u.a.: Mirroring ist pro DB (nicht pro Server) und setzt einen geeigneten Client voraus - Clustering nicht. Dafür braucht Clustering ein gemeinsames Storage und zwei Enterprise-Windows.

 

Aber selbst wenn wir den optimalerweise benötigten Speicher in Betracht ziehen, der meiner Meinung nach deutlich über 3 GB liegen dürfte, ist er sowieso recht schnell bei der EE. Von daher stellt sich dann wirklich die Frage eines vernünftigen Clusters, statt der Mirror-Geschichte. Und aus Erfahrung würde ich den Cluster jederzeit dem Mirror vorziehen...

[NilsK 2.969]

Moin,

 

Aber selbst wenn wir den optimalerweise benötigten Speicher in Betracht ziehen, der meiner Meinung nach deutlich über 3 GB liegen dürfte, ist er sowieso recht schnell bei der EE.

 

nö. x64 kann bis 32 GB RAM mit der SE. Das reicht dicke. ;-)

 

Von daher stellt sich dann wirklich die Frage eines vernünftigen Clusters, statt der Mirror-Geschichte.

 

Warum sollte der Mirror nicht vernünftig sein? Das ist eine coole Angelegenheit, und wenn man's richtig macht und die Bedingungen stimmen (v.a. der Client), klappt es auch gut.

 

Und aus Erfahrung würde ich den Cluster jederzeit dem Mirror vorziehen

 

Das ist u.a. eine Kosten- und eine Technikfrage. Es gibt eine ganze Reihe Szenarien, die man mit einem Mirror abbilden kann, mit einem Cluster aber nicht.

 

Aber um pro und contra ging es hier ja nicht. Man hat mich gebeten, hier im Board das Thema nicht zu verlassen ...

 

Gruß, Nils

[phoenixcp 10]

nö. x64 kann bis 32 GB RAM mit der SE. Das reicht dicke. ;-)

Ok, mein faux pas... Es war bisher auch noch kein Detail über die eingesetzte OS-Version ausser 2k3 zu vernehmen... ;)

 

Warum sollte der Mirror nicht vernünftig sein? Das ist eine coole Angelegenheit, und wenn man's richtig macht und die Bedingungen stimmen (v.a. der Client), klappt es auch gut.

Ich wollte damit nicht ausdrücken das ich einen Mirror für unvernünftig halte. Aber gerade durch die Anforderungen gerade den Client (damit steht und fällt das gesamte Konzept), machen es doch genauso zu einer technischen Herausforderung wie ein Cluster. Das es cool ist, ist Ansichtssache, da streit ich mich auch garnicht drüber. Der Coolnessfaktor is da eh nix für mich, das dürfen gerne die Managementetagen aufm Golfplatz auskosten ("ey alder, ich hab SAP im Einsatz, weißte..." ;) ).

Und 100 % ACK, wenn alles stimmt und man weiß was man macht / machen muss, funktioniert auch der Mirror wunderbar.

 

Aber um pro und contra ging es hier ja nicht. Man hat mich gebeten, hier im Board das Thema nicht zu verlassen ...

Ich habe diesen Thread gelesen und meine eigene Meinung dazu, die sich mit deiner in dem bewusste Thread deckt. Aber ich versuche trotzdem aus der Fülle der Möglichkeiten zu schöpfen und auch Alternativen aufzuzeigen. Ob es anderen gefällt oder nicht...

[Hauch 10]

Danke schonmal für eure Anregungen.

 

Warum greift ihr für die hohe Verfügbarkeit auf keinen Cluster zurück?

 

Ich würde spontan sagen zu teuer bzw. oversized, auch wenn Ihr jetzt sagt das hohe Verfügbarkeit nunmal Geld kostet etc. Wir sind eine Kommune und ich hab das nicht zu entscheiden -> Azubi.

 

Die VMs liegen auf 10k SAS Platten im Raid 5.

Sind die Datenbank- bzw.Logpartitionen der Server dort ebenfalls abgelegt oder liegen die (hoffentlich) auf separaten RAID's die als physikalische Datenträger in die VM eingebunden sind?

 

Die sind dort ebenfalls abgelegt. Meinst du damit die Datenbanken z.B. auf ein NAS bzw. SAN zu legen?

 

Optimierungsmöglichkeiten beim Mirroring betreffen vor allem die Verbindung zwischen den beiden Hosts: Da kann es sinnvoll sein, einen dedizierten Link zu nehmen und alles andere darauf abzuschalten.

 

Meinst du damit den VMs eine extra NIC für diesen Zweck zuweisen? (Ich denk da versteh ich was falsch)

 

Bei der Abgrenzung Cluster/Mirroring sind diverse Dinge zu beachten, u.a.: Mirroring ist pro DB (nicht pro Server) und setzt einen geeigneten Client voraus - Clustering nicht.

 

Hier wird der SQL Server Native Client eingesetzt. Ist dafür ja auch vorgesehen.

 

Edit: Wir setzen nur die Standard Versionen ein, alles auf 32 Bit.

[phoenixcp 10]

Ich würde spontan sagen zu teuer bzw. oversized, auch wenn Ihr jetzt sagt das hohe Verfügbarkeit nunmal Geld kostet etc. Wir sind eine Kommune und ich hab das nicht zu entscheiden -> Azubi.

Verständlicher Einwand. Dafür war es ja auch nur eine Frage ;)

 

Meinst du damit die Datenbanken z.B. auf ein NAS bzw. SAN zu legen?

Zum Beispiel. Damit würdest du eine weitere Performancesteigerung gegenüber einer virtualisierten Datenbankpartition erreichen, was sicher in deinem Interesse wäre ;)

[Lian 2.465]

Hallo,

 

folgenden Artikel von Tom Moreau (PhD & SQL MVP) lege ich Dir mal an's Herz ;)

SQL Server: Top Tips for SQL Server Clustering

 

Zum Thema SQL Clustering -auch wenn Ihr Euch noch nicht entschieden habt- empfehle ich folgenden KB Artikel: Clustered SQL Server do's, don'ts, and basic warnings

[NilsK 2.969]

Moin Hauch,

 

euer Konstrukt passt nicht zusammen:

• Performance, VM und 32 Bit beißt sich
  
• Hochverfügbarkeit und VM beißt sich
  
• Hochverfügbarkeit und "nichts ausgeben wollen" beißt sich
  

 

Ihr solltet von vorn beginnen und eure Anforderungen definieren. Wenn ihr die mit eurem Budget nicht umsetzen könnt, überprüft die Anforderungen. Ein schmales Budget sollte nicht zu Bastellösungen verleiten, die euch nur Sicherheit vorgaukeln. Auch mit einem guten Recovery-Konzept kommt ihr sehr weit, und das könnt ihr ohne großen Lizenz- oder Hardware-Invest aufbauen.

 

Gruß, Nils

[Hauch 10]

Hallo Nils,

 

ja ich werde das dann erstmal abklären. Was mich aber noch interessieren würde, ob jemand pauschal sagen kann wie sich die Datenbankspiegelung auf die Performance ausgewirkt hat.

[phoenixcp 10]

Was mich aber noch interessieren würde, ob jemand pauschal sagen kann wie sich die Datenbankspiegelung auf die Performance ausgewirkt hat.

 

Naja, wie weiter oben schon beschrieben, wenn man es richtig macht, kann es für ne Beschleunigung sorgen. Wenn man es falsch macht, kann es auch durchaus sein, das es deutlich langsamer als vorher ist. Die korrekte Konfiguration und Infrastruktur ist hierbei das A und O.

So pauschal kann man das nicht sagen. Auch ein möglicher Beschleunigungsfaktor lässt sich mit den Angaben die wir haben nicht ableiten.

[cernu 10]

Moin Hauch,

 

euer Konstrukt passt nicht zusammen:

• Performance, VM und 32 Bit beißt sich
  
• Hochverfügbarkeit und VM beißt sich
  
• Hochverfügbarkeit und "nichts ausgeben wollen" beißt sich
  

 

Ihr solltet von vorn beginnen und eure Anforderungen definieren. Wenn ihr die mit eurem Budget nicht umsetzen könnt, überprüft die Anforderungen. Ein schmales Budget sollte nicht zu Bastellösungen verleiten, die euch nur Sicherheit vorgaukeln. Auch mit einem guten Recovery-Konzept kommt ihr sehr weit, und das könnt ihr ohne großen Lizenz- oder Hardware-Invest aufbauen.

 

Gruß, Nils

 

Hochverfügbarkeit und VM beißt sich doch nicht.

Die Frage ist was will ich erreichen. Eine Hochverfügbarkeitslösung bezgl. Hardwareausfall erreiche ich mit VM. Innerhalb einer ESX-Clusterfarm mit VMotion und Snapshots VCB etc. kann ich mir die Server auch redundant auslegen und ein DisasterRecovery-Plan sicherstellen der geringste Ausfallzeit mit sich bringt.

 

Unser zweiter SQL-Server dümpelt auch ein wenig rum. Hier ist ein W2k3 SE 32 Bit die Grundlage (keine Frage, nicht beste Lösung)

Dauerhafter Zugriff auf Datenbanken (knapp 100 User). Datenbankvolumen ca. 60 GB. Ich hab dem Server 3 GB RAM gegeben. Gut er rennt nicht wie bekloppt, dennoch ist die Perfomance nicht schlecht.

Was ich empfehlen würde, wäre mal Monitoring betreiben, was wirklich alles da passiert.

Hier helfen schon viel die Mittel aus dem SQL2005, Aktivitätsmonitor, Server Profiler etc.

Die Datenbank immerschön sauber halten, LOGs auf Raid1(wenn überhaupt erforderlich, auch hier messen was passiert) MDBs auf Raid 5 etc. etc.

SQL sowie Exchange haben die Eigenart sich das zu nehmen was am Ram da ist. Ob es immer erforderlich ist, muss im Einzelfall gemessen werden.

Wird nur oft überschätzt .. gerade auch Exchange kann mit deutlich weniger RAM gut laufen, als es oft behauptet wird.

Gruß

Cernu

[NilsK 2.969]

Moin,

 

Hochverfügbarkeit und VM beißt sich doch nicht.

 

muss sich nicht zwingend beißen, beißt sich aber im vorhandenen Konstrukt. Zudem verweise ich auf die Support-Problematik - Hochverfügbarkeit ohne Herstellersupport ist für mich ein No-Go.

 

Gruß, Nils