Hardware für SQL 2005

[unknownuser 10]

Hallo !

 

Wir suchen Spezifikationen seitens MS für die Hardwarebeschaffung zwecks Installation eines SQL 2005 Servers.

 

Unser Kunde hat seit Jahren Performance Probleme mit Axapata. Nun soll neue Hardware angeschafft werden, bei der man ein Hardware Problem grundsätzlich ausschließen kann.

Das leidige Thema: Software Firma sagt "liegt an der Hardware, die ist zu schwach", Administration sagt "kann nicht sein, Software ist erst seit letztem Update so langsam". So in etwa... Ihr kennt das ja höchstwahrscheinlich ;)

 

Jetzt steht der Umstieg auf Windows 2003 64Bit & SQL 2005 ( min. Standard ) bevor. 70 User derzeit.

 

Unsere Empfehlung ist im wesentlichen etwa folgende:

 

HP Proliant ML 3XX, CPU Intel QuadCore ab 2,5GHz

3 x RAID 1 bzw. RAID 1+0 ( 1 x BS, 1xDB, 1xProtokolle & Logs )

Speicher soviel wie möglich ( ab 8GB aufwärts )

 

Gibt es irgendwo von MS da genaueres? Bisher nur allgemein gültige Aussagen gefunden. Grundsätzliche Angaben zum strukurellen Aufbau?

 

Wir sind uns sicher, dass es mit der Hardware wie oben aufgeführt, kaum Probleme geben kann. Kunde möchte nur dieses Hin & Her vermeiden und endlich vernünftige Performance haben.

 

Bin für jeden Tipp dankbar!

 

Gruß & Danke

Dirk

[Tom_L3 10]

Hi,

 

schreib mal was zu der Datenbank selbst... Größe DB+Protokolle, Art Nutzung... wieviel Budget hast du zur Verfügung? MS wird dir hier nicht wirklich helfen können... klar ist - je mehr Speicher desto besser - sehr guten SAS-Controller mit viel Cache und 15kU Platten wenn das im Geld drin ist... aber - du kannst die dollste Hardware haben - wenn die Software Schrott ist, dann hilft dir das nicht weiter...

 

Ähnlicher Thread: http://www.mcseboard.de/windows-forum-ms-backoffice-31/kaufberatung-sql-server-136286.html

 

Grüße

Tom

[NilsK 2.791]

Gibt es irgendwo von MS da genaueres? Bisher nur allgemein gültige Aussagen gefunden. Grundsätzliche Angaben zum strukurellen Aufbau?

 

mehr als allgemeine bzw. prinzipielle Angaben wirst du auch nicht finden. Dazu unterscheiden sich Datenbanken und insbesondere die Applikationen darüber zu sehr.

 

Mit eurem Vorschlag liegt ihr jedenfalls für eine ERP-Applikation in der Größenordnung nicht falsch. RAM ist derzeit günstig, also kann man auch 16 GB nehmen, schadet nicht.

Erfahrungsgemäß sind es bei derartigen Anwendungen eher die Applikationen, die den Flaschenhals darstellen - schlecht aufgebaute Queries, Transaktionen, die auf Usereingaben warten usw. Gegen manche dieser Dinge kann man durch geschickte Indizierung was machen - dabei hilft z.B. der Optimierungsassistent im SSMS (Admintool).

 

Gruß, Nils

[unknownuser 10]

Vielen Dank für die Antworten,

 

aber das Problem ist nicht, die Planung des Servers unsererseits ( da haben wir Erfahrung genug ), sondern nur die Darstellung gegenüber dem Kunden. Uns vertraut der schon, aber bei der Software ist er sich halt nicht sicher.

 

Wunschvorstellung des Kunden wäre eine dritte verlässliche Meinung seitens MS, auf die er sich berufen kann, wenn die Software dann später doch nicht so schnell läuft wie erhofft, um den Software Anbieter keine "Fluchtmöglichkeit" zu lassen.

 

Klar sind da schon 15k Platten mit schnellen Controller und viel Cache verplant. Und klar, Speicher ist ja auch mit min. 8GB vorgeplant, wobei die Bestückung so gewählt ist, dass jederzeit weitere 8GB dazukommen können.

Man muß halt zwischen Preis/Leistung abwägen.

Datenbank liegt derzeit bei ca. 24GB / Transaktionsprotokolle bei 2GB

Zugriffe auf die DB finden auch nur tagsüber statt, so dass die Sicherung Nachts nicht zeitkritisch ist.

 

 

Danke!

Dirk

[Tom_L3 10]

tja, ich fürchte da wirst du seitens MS nicht wirklich was finden... wie mein Vorredner schon sagte ist das schlichtweg zu sehr von der Software abhängig und von der DB-Struktur...

 

Grüße

Tom

[unknownuser 10]

ich hab's befürchtet...

 

Na, wenigstens sind wir nicht zu **** zum googlen...

 

Hatte halt die Hoffnung etwas zu finden, da sich im Prinzip die Strukturen beim Aufbau von Servern mit SQL ja sehr ähneln.

 

Aber Danke für eure Mühe!

 

Gruß, Dirk

[NilsK 2.791]

da sich im Prinzip die Strukturen beim Aufbau von Servern mit SQL ja sehr ähneln.

 

nein.

 

Nein, wirklich nicht.

 

Ein Kunde von uns hat kürzlich mehrere 10K Euro ausgegeben, um die Leistungsfähigkeit seines SQL-Systems (das von einem mehrfach gespiegelten SAN versorgt wird) zu prüfen. Dabei ist die Applikation selbst schon richtig gut gebaut - aber die Anforderungen sind in diesem speziellen Fall eben sehr hoch.

 

Das kann man beim besten Willen nicht mit einer kleinen KMU-Installation vergleichen.

 

Gruß, Nils

[LukasB 10]

Grundsätzlich muss der Softwarehersteller wissen was für Performanceanforderungen seine Software hat.

 

Wenn der Axapta-Partner eures Kunden nicht weiss wie man SQL Server für das von ihm installierte und betreute Axapta sizen muss, dann kann dieser nicht wirklich taugen.

 

Und ich glaub nicht das "Throw money at the problem until it goes away" der richtige Ansatz ist. Letzendlich ist das aber euer Bier - ihr könnt dem Kunden eine Endlos überdimensionierte Maschine verkaufen, nur weil der Axapta Partner etwas bei einer Erweiterung verhängt hat und deswegen pro angezeigter Buchung x full table scans gemacht werden müssen ;)

 

Als erstes solltest du dir aber sowieso mal die hunderten Performance-Counter die dir SQL Server und Windows zur Verfügung stellen auf der jetzigen produktiven Maschine anschauen. Erkennt du ein Bottleneck? Zuwenig RAM? CPU am Anschlag? Kommen die Disks nicht mehr nach?

[NilsK 2.791]

Moin,

 

Grundsätzlich muss der Softwarehersteller wissen was für Performanceanforderungen seine Software hat.

 

sorry, aber diese Erwartung ist praxisfern. Der Softwarehersteller bietet sein Produkt in der Regel für sehr unterschiedliche Größenordnungen an, und gerade eine ERP-Standardsoftware wird sehr unterschiedlich eingesetzt. Es ist ein Unterschied, ob der Großteil der User ab und an eine Buchung durchführt oder ob es viele Controller gibt, die das System dauernd durch aufwändige Reports stressen - mit derselben Software.

 

Wenn der Axapta-Partner eures Kunden nicht weiss wie man SQL Server für das von ihm installierte und betreute Axapta sizen muss, dann kann dieser nicht wirklich taugen.

 

Auch das ist in dieser Absolutheit praxisfern. Natürlich darf man von dem Dienstleister erwarten, dass er Anhaltspunkte geben kann. Die tatsächliche Nutzung wird er aber ohne Praxistests quasi auf dem Papier nicht vorhersehen können. Im Gegenteil: Derartige Erwartungen von Kunden führen immer wieder dazu, dass den Kunden viel zu große Server aufgeschwatzt werden, damit nur ja der Dienstleister auf der sicheren Seite ist.

 

Andersrum nützt dir ein SQL-Performance-Profi nichts, wenn er die nötigen betriebswirtschaftlichen Kenntnisse für ein angepasstes ERP-System nicht hat.

 

Als erstes solltest du dir aber sowieso mal die hunderten Performance-Counter die dir SQL Server und Windows zur Verfügung stellen auf der jetzigen produktiven Maschine anschauen. Erkennt du ein Bottleneck? Zuwenig RAM? CPU am Anschlag? Kommen die Disks nicht mehr nach?

 

Für eine solche Analyse braucht es detaillierte Spezialkenntnisse, wenn sie verlässlich sein soll.

 

Gruß, Nils

[LukasB 10]

Es ist ein Unterschied, ob der Großteil der User ab und an eine Buchung durchführt oder ob es viele Controller gibt, die das System dauernd durch aufwändige Reports stressen - mit derselben Software.

 

Das ist völlig korrekt. Für ein brauchbares Sizing muss man wissen was man für Nutzungsprofile hat. Sieht man z.b. beim Exchange Storage Calculator schön, wo man angeben kann welche Clients (mit oder ohne Cached Mode, OWA) mit welchen Nutzungsprofilen (wieviele Mails Empfangen / Gesendet) und am Schluss eine grundlegende Schätzung hat, welche in der Praxis meistens relativ gut hinkommt.

 

Ja, bei einer ERP Software ist das wesentlich schwerer zum erstens die passenden Daten zu erheben (was machen die Leute nachher genau mit der Software?) aber auch um festzulegen was alles passiert weil es viel Custom-Zeug gibt (eben z.B. Reports).

 

Nur weil es Schwieriger ist als bei anderen Produkten muss es nicht unmöglich sein.

 

Auch das ist in dieser Absolutheit praxisfern. Natürlich darf man von dem Dienstleister erwarten, dass er Anhaltspunkte geben kann. Die tatsächliche Nutzung wird er aber ohne Praxistests quasi auf dem Papier nicht vorhersehen können. Im Gegenteil: Derartige Erwartungen von Kunden führen immer wieder dazu, dass den Kunden viel zu große Server aufgeschwatzt werden, damit nur ja der Dienstleister auf der sicheren Seite ist.

 

Wenn der spezialisierte Dienstleister das Sizing nicht machen kann, wer soll es dann machen? Der Kunde der noch weniger Ahnung von dem Produkt hat als der beauftragte Dienstleister? Oder man lässt es einfach weg und kauft all halb Jahr eine neue Kiste in der Hoffnung das die Performance irgendwann genügt?

 

Von einem Dienstleister zu erwarten das das Sizing immer 100% korrekt ist, das ist praxisfern. Aber er sollte wenigstens in der Lage sein herauszufinden woran es mangelt, und was nicht berücksichtigt wurde, und wie das Problem zu beheben ist.

 

Für eine solche Analyse braucht es detaillierte Spezialkenntnisse, wenn sie verlässlich sein soll.

 

Deswegen sehe ich das grundsätzlich auch als Aufgabe des Axapta-Dienstleisters. Aber es kann nicht schaden wenn sich der OP die Performance-Werte im Groben mal selber anschaut - vielleicht ist es ja ein offensichtliches Problem.

[NilsK 2.791]

Moin

 

Wenn der spezialisierte Dienstleister das Sizing nicht machen kann, wer soll es dann machen? Der Kunde der noch weniger Ahnung von dem Produkt hat als der beauftragte Dienstleister?

 

der Dienstleister gibt eine Empfehlung aus seiner Erfahrung, die er aber unter Vorbehalt stellt. Wenn der Kunde detailliertere Empfehlungen braucht, wird man eine Simulation machen müssen. Die zahlt im Endeffekt natürlich der Kunde - entweder ausdrücklich oder weil der DL sie in seinen Preis einkalkuliert.

 

Also genau das, was im Originalfall geschehen ist.

 

Gruß, Nils

[unknownuser 10]

Ihr sprecht mir aus der Seele.

 

Das ist ja genau das Problem. Klar können wir dem Kunden völlig überdimenionierte Maschinen setzen, aber das kann es ja nicht sein. Wir sehen das Problem auch tatsächlich innerhalb der Software, da es durchaus heftige Leistungseinbrüche nach Software Updates & Erweiterung gab. Was natürlich von der Software Firma immer wieder auf die Hardware geschoben wurde.

 

Nochmals Danke für die Hinweise & Tipps.

 

Gruß

Dirk