Performanceanforderung an SQL 2005
30. April 2007 21:30
Hallo,
wir planen NAV Version 4 einzuführen über welches 55 User abgewickelt werden sollen. Habe schon gehört, dass die native DB sehr schnell ist und man eigentlich jetzt noch mit dieser anfangen könnte. Aber in ca. 1,5 Jahren wird unser Partner die Branchenlösung auf Version 5 anpassen und hier ist dann die SQL DB erforderlich. Daher möchte ich mir die spätere Migration ersparen und gleich mit der SQL beginnen - nur - welche Leistung sollte hier mein Server bringen ? Wie sieht es aus mit :
- QuadCore oder DualCore ?
- 1 Quad oder 2 DualCore Prozessoren ?
- Größe Hauptspeicher : 4 GB mit Windows 2003 Server Standard oder
8 GB mit Windows 2003 Enterprise
- Raid 5 oder Raid 10 ?
Wie sind hier Eure Erfahrungen - was wäre das optimale, damit 55 User arbeiten können ?
Danke
Gruß
wir planen NAV Version 4 einzuführen über welches 55 User abgewickelt werden sollen. Habe schon gehört, dass die native DB sehr schnell ist und man eigentlich jetzt noch mit dieser anfangen könnte. Aber in ca. 1,5 Jahren wird unser Partner die Branchenlösung auf Version 5 anpassen und hier ist dann die SQL DB erforderlich. Daher möchte ich mir die spätere Migration ersparen und gleich mit der SQL beginnen - nur - welche Leistung sollte hier mein Server bringen ? Wie sieht es aus mit :
- QuadCore oder DualCore ?
- 1 Quad oder 2 DualCore Prozessoren ?
- Größe Hauptspeicher : 4 GB mit Windows 2003 Server Standard oder
8 GB mit Windows 2003 Enterprise
- Raid 5 oder Raid 10 ?
Wie sind hier Eure Erfahrungen - was wäre das optimale, damit 55 User arbeiten können ?
Danke
Gruß
1. Mai 2007 09:09
Hi!
Nun, was Konfiguration der Plattform inkl. SQL Server Edition angeht, so hängt dies nicht von der Anzahl der Benutzer ab, sondern vom zu erwartenden Transaktionsvolumen; also wieviele Belege und Positionen erstellt und gebucht werden, etc. - auch die erwartete DB Größe spielt eine Rolle.
Folgende Vorschläge beziehen sich auf ein "gutes mittleres System" - und es sei schon vorweg genommen: die Anforderungen sind schon anspruchsvoller als mit "native" ...
CPU: Mindestens 4 Cores, also 4 Single, 2 Dual oder 1 Quad - hängt hauptsächlich vom L2 Cache ab: 4 Singles mit jeweils einem großen L2 sind einem Quad mit gemeinsamen L2 überlegen ... und: niemals Hyper-Threading.
Wenn möglich, dann 64bit
RAM: Mindestens 8GB - daraus folgt: Windows Server 2003 Enterprise Edition
Disks: Niemals RAID5 - viel zu langsam für DB Server; wenn möglich immer RAID10; allerdings gilt: physikalisches Laufwerk vor logischem Laufwerk. Wesentlich ist hier die Verteilung der einzelnen Daten/Dateien auf den einzelnen LW; hier mal ein minimal Vorschlag:
C:\ RAID 1: OS, Swap, SQL Server (inkl. master, model, msdb)
D:\ RAID 0: tempdb
E:\ RAID 1: NAV Datenbank (mdf)
F:\ RAID 10: NAV Datenbank (ldf)
G:\ RAID 1: Backups & Diverses
(insgesamt min. 12 Spindles)
Wie gesagt: "Minmal-Vorschlag", noch jenseits von optimal:
C:\ RAID 1: OS, Swap
D:\ RAID 1: SQL Server Programme
E:\ RAID 10: master, model, msdb
F:\ RAID 10: tempdb
G:\ RAID 10: NAV DB (mdf)
F:\ RAID 10: NAV DB (ldf)
H:\ RAID 1: Backups & Diverses
(insgesamt min. 22 Spindles)
Je mehr Spindles in einem RAID 10 desto besser, also lieber mehrere kleine Disks, anstatt wenige große.
Hier müssen die einzelen - leistungsfähigen - RAID/Disk Kontroller entsprechend vorhanden sein.
Niemals Write-Caches verwenden.
Ein absolutes MUSS ist hierbei: die tempdb liegt alleine auf einem eigenen Laufwerk, ebenso das Transaction Log der NAV Datenbank. Und mit alleine meine ich auch alleine: auf diesen Laufwerken DARF NIX (!!!) anderes liegen!
Auch was die Auswahl der SQL Server Edition angeht, so sollte man genau prüfen, welche Features man jetzt und in Zukunft nutzen möchte. Man muss bedenken, daß es kein Upgrade von Standard auf Enterprise Edition gibt (in so einem Fall heißt es neu kaufen).
Meine Empfehlung: gleich Enterprise Edition, dann ist das System 100%ig skalierbar und ohne Limitationen ...
P.S.: Nach einer Migration wird das System garantiert langsamer laufen als bisher in native, da hier noch einiges an der Performance zu tunen wäre ... aber das ist ein anderes Thema ... (für Fragen steh ich gerne zur Verfügung)
Gruß,
Jörg
Nun, was Konfiguration der Plattform inkl. SQL Server Edition angeht, so hängt dies nicht von der Anzahl der Benutzer ab, sondern vom zu erwartenden Transaktionsvolumen; also wieviele Belege und Positionen erstellt und gebucht werden, etc. - auch die erwartete DB Größe spielt eine Rolle.
Folgende Vorschläge beziehen sich auf ein "gutes mittleres System" - und es sei schon vorweg genommen: die Anforderungen sind schon anspruchsvoller als mit "native" ...
CPU: Mindestens 4 Cores, also 4 Single, 2 Dual oder 1 Quad - hängt hauptsächlich vom L2 Cache ab: 4 Singles mit jeweils einem großen L2 sind einem Quad mit gemeinsamen L2 überlegen ... und: niemals Hyper-Threading.
Wenn möglich, dann 64bit
RAM: Mindestens 8GB - daraus folgt: Windows Server 2003 Enterprise Edition
Disks: Niemals RAID5 - viel zu langsam für DB Server; wenn möglich immer RAID10; allerdings gilt: physikalisches Laufwerk vor logischem Laufwerk. Wesentlich ist hier die Verteilung der einzelnen Daten/Dateien auf den einzelnen LW; hier mal ein minimal Vorschlag:
C:\ RAID 1: OS, Swap, SQL Server (inkl. master, model, msdb)
D:\ RAID 0: tempdb
E:\ RAID 1: NAV Datenbank (mdf)
F:\ RAID 10: NAV Datenbank (ldf)
G:\ RAID 1: Backups & Diverses
(insgesamt min. 12 Spindles)
Wie gesagt: "Minmal-Vorschlag", noch jenseits von optimal:
C:\ RAID 1: OS, Swap
D:\ RAID 1: SQL Server Programme
E:\ RAID 10: master, model, msdb
F:\ RAID 10: tempdb
G:\ RAID 10: NAV DB (mdf)
F:\ RAID 10: NAV DB (ldf)
H:\ RAID 1: Backups & Diverses
(insgesamt min. 22 Spindles)
Je mehr Spindles in einem RAID 10 desto besser, also lieber mehrere kleine Disks, anstatt wenige große.
Hier müssen die einzelen - leistungsfähigen - RAID/Disk Kontroller entsprechend vorhanden sein.
Niemals Write-Caches verwenden.
Ein absolutes MUSS ist hierbei: die tempdb liegt alleine auf einem eigenen Laufwerk, ebenso das Transaction Log der NAV Datenbank. Und mit alleine meine ich auch alleine: auf diesen Laufwerken DARF NIX (!!!) anderes liegen!
Auch was die Auswahl der SQL Server Edition angeht, so sollte man genau prüfen, welche Features man jetzt und in Zukunft nutzen möchte. Man muss bedenken, daß es kein Upgrade von Standard auf Enterprise Edition gibt (in so einem Fall heißt es neu kaufen).
Meine Empfehlung: gleich Enterprise Edition, dann ist das System 100%ig skalierbar und ohne Limitationen ...
P.S.: Nach einer Migration wird das System garantiert langsamer laufen als bisher in native, da hier noch einiges an der Performance zu tunen wäre ... aber das ist ein anderes Thema ... (für Fragen steh ich gerne zur Verfügung)
Gruß,
Jörg
1. Mai 2007 17:59
Hallo Jörg,
das ist ja eine Auskunft die perferkt ist. Das bringt mich einen riesen Schritt weiter. Es hat sich gezeigt, dass einige noch auf Version 4 fahren und daher keine Erfahrung mit der SQL DB haben.
Ich denke ich werde mit SQL beginnen. Ob es die Enterprise Version wird, entscheidet der Preis. Bisher habe ich nur den Preis für SQL Standard für 1 Prozessor (5.800,00 EUR).
Noch eine Frage : Wenn ich den Server mit QuadCore bestücke (also Vier-Kern) muss ich dann die SQL Datenbank für jeden Kern (also 4mal) lizenzieren - oder wie ist hier die Lizenzierung von Microsoft vorgesehen. Mein Stand ist dass der tatsächliche Prozessor lizenziert wird, also wenn ich 2 Quad oder DualCore in die Maschine stecke, diese auch lizenzieren muss - nicht aber die Kerne (wie beim Quad). Ist das richtig ?
Deinen Vorschlag für die Raid Einrichtung werde ich aufnehmen.
Danke
Gruß
Albe
das ist ja eine Auskunft die perferkt ist. Das bringt mich einen riesen Schritt weiter. Es hat sich gezeigt, dass einige noch auf Version 4 fahren und daher keine Erfahrung mit der SQL DB haben.
Ich denke ich werde mit SQL beginnen. Ob es die Enterprise Version wird, entscheidet der Preis. Bisher habe ich nur den Preis für SQL Standard für 1 Prozessor (5.800,00 EUR).
Noch eine Frage : Wenn ich den Server mit QuadCore bestücke (also Vier-Kern) muss ich dann die SQL Datenbank für jeden Kern (also 4mal) lizenzieren - oder wie ist hier die Lizenzierung von Microsoft vorgesehen. Mein Stand ist dass der tatsächliche Prozessor lizenziert wird, also wenn ich 2 Quad oder DualCore in die Maschine stecke, diese auch lizenzieren muss - nicht aber die Kerne (wie beim Quad). Ist das richtig ?
Deinen Vorschlag für die Raid Einrichtung werde ich aufnehmen.
Danke
Gruß
Albe
1. Mai 2007 20:07
Hier findest Du mehr Infos zum Thema SQL Server Lizenzierung:
http://www.microsoft.com/germany/sql/uebersicht/lizenz.mspx
Wichtig ist hier bei der "Pro Prozessor" Lizenzierung, daß eine Lizenz je physikalischen oder virtuellen Prozessor zu erwerben ist; IMHO also auch bei einem Quad Core 4 Lizenzen fällig sind, ebeso wie bei 2 Dual Core oder 4 Single Core ...
In eurem Fall würde ich mal die "Server/CAL" Lizenzierung gegenrechnen (lassen), könnte billiger sein!
(Am besten den Microsoft Lizenz Dealer eures Vertrauens dazu befragen)
http://www.microsoft.com/germany/sql/uebersicht/lizenz.mspx
Wichtig ist hier bei der "Pro Prozessor" Lizenzierung, daß eine Lizenz je physikalischen oder virtuellen Prozessor zu erwerben ist; IMHO also auch bei einem Quad Core 4 Lizenzen fällig sind, ebeso wie bei 2 Dual Core oder 4 Single Core ...
In eurem Fall würde ich mal die "Server/CAL" Lizenzierung gegenrechnen (lassen), könnte billiger sein!
(Am besten den Microsoft Lizenz Dealer eures Vertrauens dazu befragen)
2. Mai 2007 08:46
Hallo Jörg,
ich habe mal bei Microsoft recherchiert. So wie ich die Lizenzierung auffasse muss pro Prozessor lizenziert werden. D.h. wenn ich
1 CPU mit Intel Xeon Quad-Core (4-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Quad-Core (4-Kern) --> 2 Lizenzen
1 CPU mit Intel Xeon Dual Core (2-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Dual Core (2-Kern) --> 2 Lizenzen
Gruß
Alwin
Microsoft Dokument (deutsch) zur SQL Lizenzierung :
Microsoft SQL Lizenzierung
ich habe mal bei Microsoft recherchiert. So wie ich die Lizenzierung auffasse muss pro Prozessor lizenziert werden. D.h. wenn ich
1 CPU mit Intel Xeon Quad-Core (4-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Quad-Core (4-Kern) --> 2 Lizenzen
1 CPU mit Intel Xeon Dual Core (2-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Dual Core (2-Kern) --> 2 Lizenzen
Gruß
Alwin
Microsoft Dokument (deutsch) zur SQL Lizenzierung :
Microsoft SQL Lizenzierung
2. Mai 2007 09:15
Folgendes steht ja in dem Bericht:
MULTICORE
Multicore-Prozessoren, die aus mehreren ausführenden Prozesseinheiten oder “Kernen” auf einem Chip bestehen, werden als viel versprechender Weg gesehen, die Ver-arbeitungsleistung zu erhöhen. Bei den auf Prozessorbasis lizenzierten Microsoft-Softwareprodukten zählt jeder Prozessor als einzelner Prozessor, unabhängig von der Anzahl der im Prozessor enthaltenen Kerne (Cores).
d.h. lieber 1 Quad-Core als 2 Dual-Core-Prozis von den Kosten her...
MULTICORE
Multicore-Prozessoren, die aus mehreren ausführenden Prozesseinheiten oder “Kernen” auf einem Chip bestehen, werden als viel versprechender Weg gesehen, die Ver-arbeitungsleistung zu erhöhen. Bei den auf Prozessorbasis lizenzierten Microsoft-Softwareprodukten zählt jeder Prozessor als einzelner Prozessor, unabhängig von der Anzahl der im Prozessor enthaltenen Kerne (Cores).
d.h. lieber 1 Quad-Core als 2 Dual-Core-Prozis von den Kosten her...
2. Mai 2007 09:50
1 CPU mit Intel Xeon Quad-Core (4-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Quad-Core (4-Kern) --> 2 Lizenzen
1 CPU mit Intel Xeon Dual Core (2-Kern) --> 1 Lizenz
2 CPU mit Intel Xeon Dual Core (2-Kern) --> 2 Lizenzen
Cool!
Danke für die Info!
2. Mai 2007 10:14
Also - allen Danke für die Info. Es ist ein echtes "Karusell" in welchem einem langsam "schwindelig" wird. SQL Ja/Nein - Performance - Lizenzierung... und und und.
Lese ich dann noch den Bericht von Stryke, dass NAV eigentlich nicht ganz auf SQL ausgelegt ist (man betrachte die Herkunft von NAV) sollte man eigentlich nicht auf der SQL einsteigen........ dann kommt aber Microsoft und unterstützt aber zukünftig nur noch die SQL.......
Mein Gott...........
Aber ich muss nun alles konkretisieren und denke an folg. Lösung für 50 User :
NAV mit Datenbankserver SQL
1 x QuadCore Prozessor
8 GB RAM
12 Kanal Raid mit kleinen Platten (8x 146 GB SAS 15K)
Windows 2003 Server Enterprise
Lizenzierung der SQL auf Basis CPU (Preis SQL 5.950 EUR/CPU)
Eigentlich sollte die Leistungsenpass nicht von der CPU her kommen, sondern aus dem I/O System - daher auch mal der Einstig mit 1x Quad.
Gruß und Dank
Albe
Lese ich dann noch den Bericht von Stryke, dass NAV eigentlich nicht ganz auf SQL ausgelegt ist (man betrachte die Herkunft von NAV) sollte man eigentlich nicht auf der SQL einsteigen........ dann kommt aber Microsoft und unterstützt aber zukünftig nur noch die SQL.......
Mein Gott...........
Aber ich muss nun alles konkretisieren und denke an folg. Lösung für 50 User :
NAV mit Datenbankserver SQL
1 x QuadCore Prozessor
8 GB RAM
12 Kanal Raid mit kleinen Platten (8x 146 GB SAS 15K)
Windows 2003 Server Enterprise
Lizenzierung der SQL auf Basis CPU (Preis SQL 5.950 EUR/CPU)
Eigentlich sollte die Leistungsenpass nicht von der CPU her kommen, sondern aus dem I/O System - daher auch mal der Einstig mit 1x Quad.
Gruß und Dank
Albe
2. Mai 2007 11:32
Also ich denke die Konfiguration ist gut so! Wenn nun vor allem bei der Verteilung der Datenbanken kein Fehler gemacht wird, dann lassen sich bestimmte Performance-Probleme schon von vornherein vermeiden.
Noch zum Thema "NAV & SQL" (ich vermute, Du hast diesbezüglich mein BLOG auf meiner Webseite gelesen):
SQL Server ist definitiv die richtige Wahl! Beinahe alle Probleme die aufgrund des "nativen Designs" auftreten sind lösbar - zwar nicht mit Standard-Mitteln, aber immerhin: LÖSBAR!
Wenn man weiß wie, dann kann man die (Hoch)Leistung des SQL Servers soz. entfesseln und NAV "zum Fliegen" bringen!
Noch zum Thema "NAV & SQL" (ich vermute, Du hast diesbezüglich mein BLOG auf meiner Webseite gelesen):
SQL Server ist definitiv die richtige Wahl! Beinahe alle Probleme die aufgrund des "nativen Designs" auftreten sind lösbar - zwar nicht mit Standard-Mitteln, aber immerhin: LÖSBAR!
Wenn man weiß wie, dann kann man die (Hoch)Leistung des SQL Servers soz. entfesseln und NAV "zum Fliegen" bringen!