8
Realistische Hardwareempfehlung für schnelle Performance mit MS SQL-Server 2000
Guten Tag,
auch auf die Gefahr, dass diese Frage bereits vielfach gestellt und beantwortet wurde, ich konnte nichts Hilfreiches finden.
Wir verwenden seit geraumer Zeit einen Server mit folgender Ausstattung:
MAXDATA Platinum-Server mit SCSI-RAID5-Festplattenverbund, Prozessor XEON 2,8GHz 1M FSB800, Arbeitsspeicher DDR333-RAM 1024MB und 1GBit-Netzwerkanbindung an HP Switch Procurve 2524, Betriebssystem MS Windows 2000 Server/Service Pack 4, Datenbank-System MS SQL-Server 2000.
Die Datenbank stammt von einem Anbieter der sich zwar intensiv um die Datenbank und Eingabemasken etc. bemüht aber in Sachen Hardware und Administration lieber schweigt (wie das was werden soll ist mir rätselhaft aber es ist so erwünscht).
Die Datenbank ist soweit ich das einschätzen kann zirka 5GB groß und zirka 5 bis 10 Benutzer greifen darauf zu (Rechnungswesen/Fibu).
Leider kommt es immer wieder zu Performance-Problemen die sich bei den Benutzern durch extrem langsame Verarbeitung von Daten bemerkbar machen. Die können dann z.B. beim Buchen zusehen, wie Datensatz für Datensatz z.B. im 5 Sekundentakt langsam vor sich hinkriechen.
Die exakte Ursache dafür ist unklar. Allerdings besteht der Verdacht, dass das Netzwerk nicht unbedingt ursächlich ist. Denn zum einen wurde dies erst vor geraumer Zeit komplett erneuert und auf 100MBit umgestellt. Zum anderen gab es kürzlich wieder einmal die Auffälligkeit, dass Benutzer in Firma X über Performance-Probleme klagen, während Benutzer in Firma Y der selben Datenbank dies nicht feststellen konnten.
Angaben des Herstellers Microsoft sind ja meistens Mindestwerte die in der Praxis aber auch zu unbefriedigenden Ergebnissen führen können. Deshalb würde mich nun Eure Meinung und Erfahrung bezüglich der Ausstattung eines solchen Servers interessieren. Reicht dies für die Benutzung durch zirka 10 Anwender aus um ohne Performanceverluste arbeiten zu können? Oder zeigt die Praxis, dass z.B. der Arbeitsspeicher mit 1GBit ganz einfach zu klein ist und schnell zu "Verstopfung durch Reservierungsego" führt?
Leider bin ich nun nicht gerade der Datenbank-Vollprofi der zudem kaum Unterstützung erfährt. Schon deshalb wäre ich für eine Rückmeldung und wertvolle Tipps sehr dankbar.
Mit vielen Grüßen und Danke im voraus
Martin
auch auf die Gefahr, dass diese Frage bereits vielfach gestellt und beantwortet wurde, ich konnte nichts Hilfreiches finden.
Wir verwenden seit geraumer Zeit einen Server mit folgender Ausstattung:
MAXDATA Platinum-Server mit SCSI-RAID5-Festplattenverbund, Prozessor XEON 2,8GHz 1M FSB800, Arbeitsspeicher DDR333-RAM 1024MB und 1GBit-Netzwerkanbindung an HP Switch Procurve 2524, Betriebssystem MS Windows 2000 Server/Service Pack 4, Datenbank-System MS SQL-Server 2000.
Die Datenbank stammt von einem Anbieter der sich zwar intensiv um die Datenbank und Eingabemasken etc. bemüht aber in Sachen Hardware und Administration lieber schweigt (wie das was werden soll ist mir rätselhaft aber es ist so erwünscht).
Die Datenbank ist soweit ich das einschätzen kann zirka 5GB groß und zirka 5 bis 10 Benutzer greifen darauf zu (Rechnungswesen/Fibu).
Leider kommt es immer wieder zu Performance-Problemen die sich bei den Benutzern durch extrem langsame Verarbeitung von Daten bemerkbar machen. Die können dann z.B. beim Buchen zusehen, wie Datensatz für Datensatz z.B. im 5 Sekundentakt langsam vor sich hinkriechen.
Die exakte Ursache dafür ist unklar. Allerdings besteht der Verdacht, dass das Netzwerk nicht unbedingt ursächlich ist. Denn zum einen wurde dies erst vor geraumer Zeit komplett erneuert und auf 100MBit umgestellt. Zum anderen gab es kürzlich wieder einmal die Auffälligkeit, dass Benutzer in Firma X über Performance-Probleme klagen, während Benutzer in Firma Y der selben Datenbank dies nicht feststellen konnten.
Angaben des Herstellers Microsoft sind ja meistens Mindestwerte die in der Praxis aber auch zu unbefriedigenden Ergebnissen führen können. Deshalb würde mich nun Eure Meinung und Erfahrung bezüglich der Ausstattung eines solchen Servers interessieren. Reicht dies für die Benutzung durch zirka 10 Anwender aus um ohne Performanceverluste arbeiten zu können? Oder zeigt die Praxis, dass z.B. der Arbeitsspeicher mit 1GBit ganz einfach zu klein ist und schnell zu "Verstopfung durch Reservierungsego" führt?
Leider bin ich nun nicht gerade der Datenbank-Vollprofi der zudem kaum Unterstützung erfährt. Schon deshalb wäre ich für eine Rückmeldung und wertvolle Tipps sehr dankbar.
Mit vielen Grüßen und Danke im voraus
Martin
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 28066
Url: https://administrator.de/contentid/28066
Ausgedruckt am: 26.11.2024 um 14:11 Uhr
8 Kommentare
Neuester Kommentar
Also erstmal zum Vergleich:
Unser SQL: 40 User DB-Grösse 300 MB mit einer PIII 800 1024 MB Maschine problemlos.
Lass mal von MS den SQL Best Practice Analyzer drüberlaufen der gibt schon mal wertvolle Tipps.
Es kann auch an einem "Filter" eines User´s liegen das die Datenbankperformance einbricht .
Beispiel: 300000 Kunden 500 Artikel und ein Dau sucht dauernd mit dem Filter PLZ.
Ich glaub du kannst dir denken das die DB in die Knie geht.
Meist liegt eine Defragmentierung des Plattensystems vor!
Ich hab auch da ein nützliches Doku.
http://links.schweighofer.com/diverses/SQLServer-Performance.pdf
Unser SQL: 40 User DB-Grösse 300 MB mit einer PIII 800 1024 MB Maschine problemlos.
Lass mal von MS den SQL Best Practice Analyzer drüberlaufen der gibt schon mal wertvolle Tipps.
Es kann auch an einem "Filter" eines User´s liegen das die Datenbankperformance einbricht .
Beispiel: 300000 Kunden 500 Artikel und ein Dau sucht dauernd mit dem Filter PLZ.
Ich glaub du kannst dir denken das die DB in die Knie geht.
Meist liegt eine Defragmentierung des Plattensystems vor!
Ich hab auch da ein nützliches Doku.
http://links.schweighofer.com/diverses/SQLServer-Performance.pdf
Also an die Hardware dess Servers mag ich auch erstmal nicht glauben. Wir habe hier zwei P3 mit je 1GHz und 1 GB Speicher. Da laufen über 10 Datenbanken drauf.
Eine macht in letzter Zeit auch ein bischen Zicken. Interessanter Weise, nachdem wir ein neues Realeas der Software eingesetzt haben. Es macht als auch immer was aus, wie die Datenbank unten drunter aufgesetzt ist. Ob die Abfragen gut programmiert sind, etc.
Machen Benutzer x und y denn das Gleiche oder arbeiten sie in verschiedenen Bereichen der Software?
Eine macht in letzter Zeit auch ein bischen Zicken. Interessanter Weise, nachdem wir ein neues Realeas der Software eingesetzt haben. Es macht als auch immer was aus, wie die Datenbank unten drunter aufgesetzt ist. Ob die Abfragen gut programmiert sind, etc.
Machen Benutzer x und y denn das Gleiche oder arbeiten sie in verschiedenen Bereichen der Software?
Hallo Micke,
und Danke für die schnelle Rückmeldung. Leider sind die 300MB und 40 User schlecht vergleichbar mit den 5GB und 10 Usern. Zumal es ja auch auf die Struktur der Datenbank ankommt. Aber dort habe ich Dank magerer Auskunftsbereitschaft des Herstellers ohnehin keinen Einblick. Allerdings ist es heute ja fast normal das ein PC 1GB Arbeitsspeicher hat. Auch deshalb habe ich meine Zweifel, ob das für einen Server sinnvoll ausreicht. Ihr habt offenbar eine gute Datenbank, wenig Daten und schlaue Benutzer. Zu beneiden!
Kann bzw. soll der "Best Practice Analyser" eigentlich installiert werden, wenn die Datenbank in Verwendung ist und was macht dieses Tool? Zeichnet das die Auslastung auf oder wie?
Vielen Dank und Grüße
Martin
und Danke für die schnelle Rückmeldung. Leider sind die 300MB und 40 User schlecht vergleichbar mit den 5GB und 10 Usern. Zumal es ja auch auf die Struktur der Datenbank ankommt. Aber dort habe ich Dank magerer Auskunftsbereitschaft des Herstellers ohnehin keinen Einblick. Allerdings ist es heute ja fast normal das ein PC 1GB Arbeitsspeicher hat. Auch deshalb habe ich meine Zweifel, ob das für einen Server sinnvoll ausreicht. Ihr habt offenbar eine gute Datenbank, wenig Daten und schlaue Benutzer. Zu beneiden!
Kann bzw. soll der "Best Practice Analyser" eigentlich installiert werden, wenn die Datenbank in Verwendung ist und was macht dieses Tool? Zeichnet das die Auslastung auf oder wie?
Vielen Dank und Grüße
Martin
Lass mal den "perfmon" mit geeigneten Countern laufen, um zu sehen, ob irgendwas laeuft wenn die Datenbank Probleme macht.
Die Hardware muesste eigentlich diese paar Gig Datenbank problemlos verkraften.
Vermutlich wirst du mit perfmon nicht mal eine Plattenaktivitaet maerken, da wegen der Datenlokalitaet alles im RAM (Cache) laeuft.
Gibt es eine Statistik, ob mehr die lesenden oder mehr die schreibenden Aktionen Probleme machen?
Die Hardware muesste eigentlich diese paar Gig Datenbank problemlos verkraften.
Vermutlich wirst du mit perfmon nicht mal eine Plattenaktivitaet maerken, da wegen der Datenlokalitaet alles im RAM (Cache) laeuft.
Gibt es eine Statistik, ob mehr die lesenden oder mehr die schreibenden Aktionen Probleme machen?
Hallo,
leider ist die Situation sind die Gegebenheiten nicht so, dass eine einfach Anlayse und Beseitigung der Ursachen möglich ist. Meiner Ansicht nach müsste eigentlich der Hersteller der Datenbank die auf SQL-Server aufsetzt seinen Teil zur Analyse beitragen. Denn gerade die Struktur der Datenbank hat meiner Ansicht nach Einfluss auf Funktion und Geschwindigkeit. Schließlich gibt es gut und schlecht strukturierte Datenbanken. Somit kann ich nur die Vorraussetzungen schaffen, die eine gute Funktion ermöglichen. Alles weitere liegt dann bei den Entwicklern der Datenbank.
Ich werde die Empfehlungen im Hinterkopf behalten und bei Gelegenheit versuchen, damit weitere Recherchen durchzuführen. Wenn jemand weitere Tipps dazu hat, gerne - Danke!
Welche Counter sind mit "perfmom" eigentlich wirklich aussagekräftig und zu empfehlen. Es gibt so Unmengen viele!?
Grüße Martin
leider ist die Situation sind die Gegebenheiten nicht so, dass eine einfach Anlayse und Beseitigung der Ursachen möglich ist. Meiner Ansicht nach müsste eigentlich der Hersteller der Datenbank die auf SQL-Server aufsetzt seinen Teil zur Analyse beitragen. Denn gerade die Struktur der Datenbank hat meiner Ansicht nach Einfluss auf Funktion und Geschwindigkeit. Schließlich gibt es gut und schlecht strukturierte Datenbanken. Somit kann ich nur die Vorraussetzungen schaffen, die eine gute Funktion ermöglichen. Alles weitere liegt dann bei den Entwicklern der Datenbank.
Ich werde die Empfehlungen im Hinterkopf behalten und bei Gelegenheit versuchen, damit weitere Recherchen durchzuführen. Wenn jemand weitere Tipps dazu hat, gerne - Danke!
Welche Counter sind mit "perfmom" eigentlich wirklich aussagekräftig und zu empfehlen. Es gibt so Unmengen viele!?
Grüße Martin
Wir haben ähnliche Probleme wie du beschreibst durch den Perform-Test -> link beseitigen können.
den SQL - BPA kannst du auf der laufenden Maschine installiernen.
Uberprüft ob du genug Speicher hast ob Sec. Updates fehlen, Wie du Auslagerung und ä. einstellen sollst. Gibt Tipps über Tipps.
(Ein MBSA für SQL)
PS.: Wir haben unser Produkt bei Kundschaften laufen die SQL DBs bis 16 Gig. haben. (Aber SQL 2005)
Oder du installierst dir auf einem Client eine SQL 2005 Trial und hängst deinen SQL 2000 Server in der neuen Management Verwaltung dazu.
Dort findest du einen Profiler oder ä. (Ich habs auch erst in einem Vortrag gesehen) mit diesem kannst du Grafisch dargestellt die Zugriffe, Auslastung und weiteres ansehen
Genaueres werden dir wohl SQL 2005 Experten sagen können. (!!!Aufruf!!!)
den SQL - BPA kannst du auf der laufenden Maschine installiernen.
Uberprüft ob du genug Speicher hast ob Sec. Updates fehlen, Wie du Auslagerung und ä. einstellen sollst. Gibt Tipps über Tipps.
(Ein MBSA für SQL)
PS.: Wir haben unser Produkt bei Kundschaften laufen die SQL DBs bis 16 Gig. haben. (Aber SQL 2005)
Oder du installierst dir auf einem Client eine SQL 2005 Trial und hängst deinen SQL 2000 Server in der neuen Management Verwaltung dazu.
Dort findest du einen Profiler oder ä. (Ich habs auch erst in einem Vortrag gesehen) mit diesem kannst du Grafisch dargestellt die Zugriffe, Auslastung und weiteres ansehen
Genaueres werden dir wohl SQL 2005 Experten sagen können. (!!!Aufruf!!!)
Hallo Martin,
um auf Deine Frage (problembeseitigend) antworten zu können wären natürlich mehr Informationen nötig (...). Aus meiner praktischen Erfahrung würde ich einfach mal aus der Hüfte schießen das die vorhandene Hardware mehr als ausreichend ist WENN
1) Die 10 (was SEHR wenige sind ) Benutzer nicht andauernd mit millionen von Datensätzen arbeiten
2) auf dem Server keine anderen rechenintensiven "Anwendungen" laufen
3) das Netzwerk nicht EXTREM anderweitig ausgelastet wird(wie Du ja angedeutet hast)
nicht zutreffen.
Möglicherweise solltest Du auch mal einen Blick in den Code des Frontends werfen.
Aber ich denke Du kennst die Lösung des Problems selbst : TACHELES mit dem "Anbieter der Datenbank(??)" reden.
IMHO muss eine ABSOLUTE Vertrauensbeziehung zwischen Auftraggeber und Datenbankentwickler herschen. So wie Du es angedeutet hast trifft das bei Dir nicht unbedingt zu.
Gruß
Felix (meines Zeichens Datenbank-und Anwendungsentwickler)
um auf Deine Frage (problembeseitigend) antworten zu können wären natürlich mehr Informationen nötig (...). Aus meiner praktischen Erfahrung würde ich einfach mal aus der Hüfte schießen das die vorhandene Hardware mehr als ausreichend ist WENN
1) Die 10 (was SEHR wenige sind ) Benutzer nicht andauernd mit millionen von Datensätzen arbeiten
2) auf dem Server keine anderen rechenintensiven "Anwendungen" laufen
3) das Netzwerk nicht EXTREM anderweitig ausgelastet wird(wie Du ja angedeutet hast)
nicht zutreffen.
Möglicherweise solltest Du auch mal einen Blick in den Code des Frontends werfen.
Aber ich denke Du kennst die Lösung des Problems selbst : TACHELES mit dem "Anbieter der Datenbank(??)" reden.
IMHO muss eine ABSOLUTE Vertrauensbeziehung zwischen Auftraggeber und Datenbankentwickler herschen. So wie Du es angedeutet hast trifft das bei Dir nicht unbedingt zu.
Gruß
Felix (meines Zeichens Datenbank-und Anwendungsentwickler)
Hallo Zusammen,
und Danke nochmal für die Rückmeldungen und Tipps. Damit bestehen nun erste Ansatzpunkte, dass Thema anzugehen. Wenns was Neues gibt, meld' ich mich, denn gemeinsam ist man schlauer.
Grüße
Martin
und Danke nochmal für die Rückmeldungen und Tipps. Damit bestehen nun erste Ansatzpunkte, dass Thema anzugehen. Wenns was Neues gibt, meld' ich mich, denn gemeinsam ist man schlauer.
Grüße
Martin
