sehr große DB, optimale Serverhardware gesucht?

[caartman 10]

Hallo Forum,

 

ich muss einem Kunden einen neuen SQL-Server anbieten, da ich mit SQL nur wenig Erfahrungen vorweisen kann, möchte ich dazu auch Eure Meinung einholen.

 

Es handelt sich um eine aktuell 35 GB große Datenbank. Sie läuft auf einem 2003er Server mit SQL 2000 Standard. Hardware ist ein FSC Primergy mit 5-6 SCA HDDs im RAID5.

 

Die Datenbankperformance lässt wie man sich denken kann zu wünschen übrig. (Vermutlich vor allem wegen dem RAID5)

 

Was die HDDs im neuen Server angeht habe ich mir folgendes überlegt:

- 2x 10k SAS im RAID1 für OS

- 4x 15k SAS im RAID10 für SQL-Datenbank

- 4x 15k SAS im RAID10 für SQL-Transaktionslogs (evtl. reicht hier auch RAID1?)

 

Ist das empfehlenswert? Hat jemand Ehrfahrungswerte für mich? Bessere Vorschläge?

 

Beim RAM habe ich an 16 GB gedacht, profitiert der SQL von mehr RAM? Gibt es eine Grenze?

 

Ich wollte einen Server 2008 Standard (R2) 64bit + SQL2008 Standard nehmen.

 

Ist es Sinnvoll 2x QuadCore Xeon einzusetzen oder reicht beim SQL eine CPU? (Abgesehen von der Lizenzierung)

 

Muss ich noch etwas beachten woran ich nicht gedacht habe?

 

 

Vielen Dank im Voraus

 

 

PS:

Ich benötige keine konkreten Hardwarevorschläge/Angebote, lediglich das optimale Design der Hardwareausstattung interessiert mich.

[LukasB 10]

Also bei "sehr grosse DB" und "35GB" muss ich dann doch ein bisschen schmunzeln ;)

 

Grundsätzlich wirst du mit 1x QC, 16GB RAM und 8 SAS Disks ziemlich weit kommen, vorallem wenn man schaut was du heute für Hardware hast.

 

Letztendlich benötigst du für optimale Performance aber auch die richtigen Indizes auf der Datenbank, und korrekt formulierte Abfragen.

 

Falls es sich um eine Eigenentwicklung handelt, würde ich als erstes mal sicherstellen das es sich nicht um ein simples Problem wie einen fehlenden Index handelt. Auch bei einer Fremdentwicklung kann es Sinn machen, erstmal die DB anzuschauen bevor man mit Hardware nach dem Problem schmeisst. Wobei das dann meist schwerer ist.

 

Letztendlich ist es hier sehr schwer dir konkrete Angaben zu machen - eine 35GB grosse ERP-DB auf welchen 5000 User OLTP machen muss anders sized werden als eine 35GB Archivierungs-DB auf welche täglich 3 Abfragen gemacht werden, welche aufgrund fehlender Indizes und komisch formulierten SQL Queries 3 Stunden dauern - nur um mal zwei Extrembeispiele zu nennen.

 

Grundsätzlich tönt RAID10 richtig, auch wenn ich mir ziemlich sicher bin das die Hardware die du hast bei einer richtig konfigurierten (Indizes, Query) DB und geschätzten 10-30 Usern Overkill ist.

[caartman 10]

Vielen Dank für Deine Einschätzung. Ich will noch kurz umreißen wie die Benutzung aussieht:

 

Es handelt sich um ein ERP-System mit dem ca. 35 User arbeiten und auch ein OnlineShop der darauf zugreift. (Allerdings macht dieser "nur" alle 15 Minuten einen Abgleich der Bestände)

 

Es werden so ca. 800 - 1000 Rechnungen/Tag geschrieben, dazu kommen natürlich noch Dinge wie Angebote, Lieferscheine und natürlich Stammdaten wie Artikel, Kunden, Lieferanten etc. die Abgefragt/Hinzugefügt werden...

 

Es wird also schon relativ intensiv damit gearbeitet. Und da ist es natürlich etwas lästig wenn die DB immer kleine Denkpausen einlegt wenn Kunden am Telefon Auskünfte benötigen.

 

Was die Struktur der DB angeht, da kann und will ich auch gar nicht ran…

[Cybquest 36]

Ich denke, wenn du eine Riesenmaschine anbietest und das Problem dann doch nur Bedingt die Hardware war, sieht das nicht gut aus!

 

Eine Analyse wäre sicher vorab von Vorteil.

Wenn sich da rausstellt, dass z.B. die Schreib- oder Lesewarteschlange auf die Datenträger ständig lang ist, kann man durch Erneuerung des Plattensubsystems bestimmt was erreichen.

Wenn sich jedoch rausstellt, dass das ERP unvorteilhaft programmiert wurde (zu viele Fulltablescans, falsche Optimizer-Hints, fehlende Indizes), hilft neue Serverhardware nur bedingt.

[NilsK 2.795]

Moin,

 

Es wird also schon relativ intensiv damit gearbeitet. Und da ist es natürlich etwas lästig wenn die DB immer kleine Denkpausen einlegt wenn Kunden am Telefon Auskünfte benötigen.

 

das deutet dann aber stark auf nicht optimierte Datenbankabfragen hin - oder auf fehlerhaften Code. Die derzeitige Hardware sollte bei den genannten Größen keine Denkpausen verursachen, wenn die DB richtig aufgebaut ist. (Es sei denn, wir reden über sehr wenig RAM im bestehenden System.)

 

Ein Beispiel: In meiner früheren Firma war Navision 4.0 auf SQL Server im Einsatz. Die Hardware war gemessen an den Anforderungen im oberen Mittelfeld angesiedelt. Trotzdem kam es immer wieder zu Stillstand. Wie sich herausstellte, waren eklatante Programmierfehler Schuld (in der Navision-Anpsasung, nicht in Navision selbst), z.B. Eingabemasken, die ganze Tabellen exklusiv sperrten (sprich: Hatte jemand die Maske offen, konnte niemand anders an die Tabelle ran - ungünstig, wenn derjenige dann Mittag macht oder zum Kunden fährt).

 

Gruß, Nils