SQL Server beschleunigen
Wir wollen unseren SQL Server beschleunigen, mit neuem Rechner, allerdings ist es subjektiv langsamer.
Mahlzeit
Wir haben derzeit einen SQL Server mit Windows Server 2003 und SQL Server 2003 alles auf 32 Bit. Der Rechner selbst beherbergt einen Celeron 2 GHz Quad Prozessor mit derzeit 4 GB RAM. Die Datenbank hat eine beachtliche größe von ca 1,5 GB angenommen und in der Systemauslastung des Rechners sind etwa 2,5 GB des RAM belegt. Dieser läuft zwar recht zügig, aber wir wollen gern noch etwas mehr raus holen. Daher haben wir beschlossen einen neuen Rechner zusammen zu bauen.
Der neue ist ebenfalls ein Quadcore mit 3 GHz, 16 GB RAM. Hier haben wir allerdings ein 64 bit Betriebssysten installiert und auch das neue SQL 2008 mit 64 Bit. Die Datenbank haben wir dann einfach rüber kopiert und dort eingehangen. In der Hoffnung, das 64 Bit Betriebssystem könne mit dem neuen 2008er SQL (ebenfalls als 64 Bit variante) vielleicht doch etwas schneller arbeiten. Leider weit gefehlt.
Subjektiv gesehen ist der Rechner sogar langsamer, wenn überhaupt gleich schnell. Gibts hier noch etwas, was wir beachten müssen um der SQL Datenbank etwas mehr Perfomance heraus zu kitzeln? Kann man noch irgendwo etwas drehen?
mit freundlichen Grüßen
Maddin
Mahlzeit
Wir haben derzeit einen SQL Server mit Windows Server 2003 und SQL Server 2003 alles auf 32 Bit. Der Rechner selbst beherbergt einen Celeron 2 GHz Quad Prozessor mit derzeit 4 GB RAM. Die Datenbank hat eine beachtliche größe von ca 1,5 GB angenommen und in der Systemauslastung des Rechners sind etwa 2,5 GB des RAM belegt. Dieser läuft zwar recht zügig, aber wir wollen gern noch etwas mehr raus holen. Daher haben wir beschlossen einen neuen Rechner zusammen zu bauen.
Der neue ist ebenfalls ein Quadcore mit 3 GHz, 16 GB RAM. Hier haben wir allerdings ein 64 bit Betriebssysten installiert und auch das neue SQL 2008 mit 64 Bit. Die Datenbank haben wir dann einfach rüber kopiert und dort eingehangen. In der Hoffnung, das 64 Bit Betriebssystem könne mit dem neuen 2008er SQL (ebenfalls als 64 Bit variante) vielleicht doch etwas schneller arbeiten. Leider weit gefehlt.
Subjektiv gesehen ist der Rechner sogar langsamer, wenn überhaupt gleich schnell. Gibts hier noch etwas, was wir beachten müssen um der SQL Datenbank etwas mehr Perfomance heraus zu kitzeln? Kann man noch irgendwo etwas drehen?
mit freundlichen Grüßen
Maddin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 141987
Url: https://administrator.de/forum/sql-server-beschleunigen-141987.html
Ausgedruckt am: 25.12.2024 um 16:12 Uhr
21 Kommentare
Neuester Kommentar
Gut das es nur einen SQL-Server gibt... MySQL, PosgresSQL, MS-SQL,...
Und dann würde ich mal sagen das ihr erstmal "Grundlagen des DB-Designs" durchmachen solltet. Die CPU usw. ist bei einem DB-Server sekundär -> wichtig ist dagegen:
- Schnelle Festplatten
- Viel Speicher (und diesen auch für die DB nutzbar machen)
Wenn das erfüllt ist - DANN kann man sich über CPU und Co. unterhalten.
Und was die "Migration" von einer Datenbank zu einer anderen durch bloßes Kopieren der DB-Dateien bedeutet möchte ich hier nicht sagen -> bei den worten würde mir hier der ein oder andere Mod zimlich ins Bein beissen! Ehrlich gesagt wäre DAS die letzte Art wie ich es migrieren würde - vorher würde ich dann schon mittels "Dump" die Daten auslesen und in das andere DBMS einspielen... Aber selbst da gibt es noch schönere Wege für - je nach DB-System...
Und dann würde ich mal sagen das ihr erstmal "Grundlagen des DB-Designs" durchmachen solltet. Die CPU usw. ist bei einem DB-Server sekundär -> wichtig ist dagegen:
- Schnelle Festplatten
- Viel Speicher (und diesen auch für die DB nutzbar machen)
Wenn das erfüllt ist - DANN kann man sich über CPU und Co. unterhalten.
Und was die "Migration" von einer Datenbank zu einer anderen durch bloßes Kopieren der DB-Dateien bedeutet möchte ich hier nicht sagen -> bei den worten würde mir hier der ein oder andere Mod zimlich ins Bein beissen! Ehrlich gesagt wäre DAS die letzte Art wie ich es migrieren würde - vorher würde ich dann schon mittels "Dump" die Daten auslesen und in das andere DBMS einspielen... Aber selbst da gibt es noch schönere Wege für - je nach DB-System...
Hallo,
da eure DB ja nicht so groß ist, denke ich ihr habt den SQL Express 2008, und der nutz von deinen 16GB max. 1GB und nutzt nur einen Kern von eurem Quad.
Da müssst ihr schon einen "richtigen" SQL Server kaufen wenn ihr eure Hardware ausnutzen wollt. (oder auf ein anderes DBMS umsteigen)
da eure DB ja nicht so groß ist, denke ich ihr habt den SQL Express 2008, und der nutz von deinen 16GB max. 1GB und nutzt nur einen Kern von eurem Quad.
Da müssst ihr schon einen "richtigen" SQL Server kaufen wenn ihr eure Hardware ausnutzen wollt. (oder auf ein anderes DBMS umsteigen)
Moin,
der SQL-Administrator bietet doch die Möglichkeit eines Backups (Altsystem) und eines Restores (Neusystem) deswegen werden doch nicht die Daten verändert...
Einfach mal in die Hilfe schauen ^^
Ansonsten kannst Du auch die DB replizieren (von alt zu neu) und dann den Datenfütterer nach einer kurzen Pause auf neu umstellen....
Gruß
24
der SQL-Administrator bietet doch die Möglichkeit eines Backups (Altsystem) und eines Restores (Neusystem) deswegen werden doch nicht die Daten verändert...
Einfach mal in die Hilfe schauen ^^
Ansonsten kannst Du auch die DB replizieren (von alt zu neu) und dann den Datenfütterer nach einer kurzen Pause auf neu umstellen....
Gruß
24
Zitat von @kruemeltee:
Was die Platten anbetrifft ... ich gebe zu, ich hätte etwas präziser sein können. Wir haben hier bei beiden
Systemen IBM e-Server und SCSI Platten mit 10K U/min drin, die sollten eigentlich schnell genug sein.
Was die Platten anbetrifft ... ich gebe zu, ich hätte etwas präziser sein können. Wir haben hier bei beiden
Systemen IBM e-Server und SCSI Platten mit 10K U/min drin, die sollten eigentlich schnell genug sein.
Selbst das ist noch nicht wirklich präziser. Wie viele Platten, wie viele User?
Und was für ein Raidverbund, und was wird Hauptsächlich mit der Datenbank gemacht -> mehr lesender oder schreibender Zugriff.
Schonmal darübernachgedacht einen Index auf die wichtigen Spalten aufzubauen?? Ich komme zwar von Oracle aber ich denke der MS SQL Server sollte das auch beherschen. Bei Oracle hat man durch den Index (sinnvoll eingesetzt) eine Steigerung in der Abfragegeschwindigkeit um den Faktor 15 -20.
Jetzt nicht böse werden aber so wie sich das bisher anhört kannst du deine Datenbank vergessen, denn so wie du das beschreibst wurde das alles mit der heißen Nadel gestrickt von jemandem der doch besser erstmal sich in das Thema Datenbanken einlesen sollte.
Falls du auf Erfahrungen mit Access zurückgreifst vergiss es Access ist keine Datenbank sondern eine etwas bessere Exel Version mehr nicht.
Holt euch im Zweifelsfall einfach etwas Konsulting zum Aufbau, Kostet zwar etwas das wird dann aber auch was.
Schonmal darübernachgedacht einen Index auf die wichtigen Spalten aufzubauen?? Ich komme zwar von Oracle aber ich denke der MS SQL Server sollte das auch beherschen. Bei Oracle hat man durch den Index (sinnvoll eingesetzt) eine Steigerung in der Abfragegeschwindigkeit um den Faktor 15 -20.
Jetzt nicht böse werden aber so wie sich das bisher anhört kannst du deine Datenbank vergessen, denn so wie du das beschreibst wurde das alles mit der heißen Nadel gestrickt von jemandem der doch besser erstmal sich in das Thema Datenbanken einlesen sollte.
Falls du auf Erfahrungen mit Access zurückgreifst vergiss es Access ist keine Datenbank sondern eine etwas bessere Exel Version mehr nicht.
Holt euch im Zweifelsfall einfach etwas Konsulting zum Aufbau, Kostet zwar etwas das wird dann aber auch was.
[OT]
[Quote]
Access ist keine Datenbank sondern eine etwas bessere Exel Version mehr nicht.
[/Quote]
Und selbst DAS würde ich schon bezweifeln! ;)
[/OT]
Ok, im ernst: Es gibt gute Gründe warum nen DB-Admin mehr verdient als der Admin der grad mal nen paar Windows-Büchsen aufsetzt. Diese Gründe sind u.a. darin zu suchen das der DB-Admin nen paar Dinge mehr können sollte. Und zwar hauptsächlich eine DB optimieren / stabil laufen lassen...
[Quote]
Access ist keine Datenbank sondern eine etwas bessere Exel Version mehr nicht.
[/Quote]
Und selbst DAS würde ich schon bezweifeln! ;)
[/OT]
Ok, im ernst: Es gibt gute Gründe warum nen DB-Admin mehr verdient als der Admin der grad mal nen paar Windows-Büchsen aufsetzt. Diese Gründe sind u.a. darin zu suchen das der DB-Admin nen paar Dinge mehr können sollte. Und zwar hauptsächlich eine DB optimieren / stabil laufen lassen...
Nabend Maddin,
wie groß ist denn deine log datei? solltest die ggf. verkleinern.
guckst du hier
SQL 2008 Log File Datei verkleinern
oder
http://msdn.microsoft.com/de-de/library/ms178037.aspx
darüber hinaus kann eine langsame Datenbank ne ganze Menge ursachen haben.
Greetz
wie groß ist denn deine log datei? solltest die ggf. verkleinern.
guckst du hier
SQL 2008 Log File Datei verkleinern
oder
http://msdn.microsoft.com/de-de/library/ms178037.aspx
darüber hinaus kann eine langsame Datenbank ne ganze Menge ursachen haben.
Greetz
Zitat von @kruemeltee:
Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck müsste
ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht darf.
Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze aufs
Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die
Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie geklappt.
Wie währ's mit einer einfachen Datensicherung, das werdet ihr unterm laufenden Betrieb machen? In der Management Konsole einfach die Datenbank wegsichern und auf dem zweiten Server wiederherstellen.Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck müsste
ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht darf.
Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze aufs
Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die
Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie geklappt.
P.S.: bitte nicht den Kopf abschlagen, wenn wieder ein paar "Ungenauigkeiten" vorhanden sind. Daher frage ich ja nach,
denn das ist nun einmal ein Gebiet, auf dem ich mich bisher nicht sonderlich gut auskenne. Eine Idee wäre noch (aber nur von
meinem technischen Verständnis her) wenn ich das Raid etwas "aufbohre", nämlich ein Raid 01 ... also 4
Platten, jeweils zwei im Raid 0 und dieses gespiegelt als Raid 1? Ist aber auch nur eine Idee Platten haben wir noch genug
da!
Bei deinen Angaben würd ich jetzt eher sagen nimm eher 10-12 Platten min. für die Datenbank alleine und dann noch einige für den Rest.
Alternativ 4-6 SSD für die Datenbank
Moin,
ok, 1 Semester Datenbanken und du gehst an so ein System ran? Ich weiss nicht ob ich das mit Mut oder - sorry - dummheit beschreiben soll... Meine Tendenz geht allerdings eher zum letzteren. Grad wenn du dich für das Thema eigentlich nie intressiert hast...
Fangen wir mal ganz simpel an:
[quote]
enn wenn ich mir die tausenden Tabellen anschaue, die da drin sind und die Fülle von SQL Abfragen die an den Server gesendet werden, wenn ich das Programm nur starte (ohne mich einzuloggen oder gar Informationen heraus zu lesen), dann muss das schon heftig sein.
[/quote]
Also ist das für dich schon nen kriterium?
for (int i=0;i<100000;i++) mysql_query("Select 1 from benutzer");
-> Macht auch 100.000 Anfragen... Und ob ein Programm dann gut ist oder nicht siehst du eher daran wie derjenige die Tabellen aufgebaut hat, wie die Abfragen gebaut wurden usw... Nehmen wir nur mal an du hast 3 Tabellen:
[TBL1]
Name (Varchar50)
Vorname (Varchar50)
Geburtsdatum (Date)
[TBL2]
Name (Varchar50)
Vorname (Varchar50)
Fahrzeug (Varchar50)
[TBL3]
Name (Varchar50)
Vorname (Varchar50)
Schulabschluss (Varchar50)
Sieht ja erstmal gut aus -> allerdings wenn du da mal nen paar Tausend einträge hast wirst du sehen das die Text-Vergleiche nicht wirklich schnell sind... Hier gibt es dann elegantere Lösungen:
TBL1]
ID(Integer, AutoIncrement)
Name (Varchar50)
Vorname (Varchar50)
Geburtsdatum (Date)
[TBL2]
PersonenID (Integer)
Fahrzeug (Varchar50)
[TBL3]
PersonenID (Integer)
Schulabschluss (Varchar50)
-> das würde mit Sicherheit um einiges schneller laufen...
Das schonmal zur Datenbank-Theorie "Grundlagen"... Nur weil ein Programm viele Tabellen enthält oder 1000ende Abfragen wirft ist das nichtmal ANSATZWEISE ein Kriterium für gute Programmierung!
[quote2]
Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck müsste ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht darf. Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze aufs Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie geklappt.
[/quote]
Am Wochenende die DB stoppen auf ein Ersatzsystem bringen und erstmal prüfen. GRADE wenn man keine Erfahrung hat sollte man sowas nicht im Betrieb machen. Nehmen wir an dieser Stelle mal an du bist bei einem Lager. Jemand liefert dir 2 KG Gold an - leider exportierst du grad die DB und die Lager-Bestandstabelle ist wegen des Exportes grad gesperrt. Dummerweise hat der Entwickler der Software nicht an sowas gedacht und das Programm wirft auch keinen Fehler aus (bzw. kann nix auswerfen da die Einlagerung durch Handscanner gemeldet wird). Tja - schade eigentlich... Bei dir liegen grad 2 KG Gold rum und keiner weiss mehr woher die kommen und wofür die sind -> aber keine Sorge, wenn das Auftritt komm ich vorbei und entsorge die für euch... Nur wenn das von deinem Gehalt abgezogen wird solltest du besser schnell umziehen...
[quote3]
Mein grundsätzlicher Gedanke war der, daß eine, sagen wir, vergleichbare Maschine mit einer so großen Datenmenge doch theoretisch besser klar kommen sollte, wenn ein 64 Bit Betriebssystem darunter liegt und das Programm selbst auch als 64 Bit Variante läuft. Damit meinte ich jetzt weniger den Vorteil daß ich mehr als 4 GB Arbeitsspeicher nutzen kann sondern evtl. noch andere Vorteile (mir fällt zwar auf anhieb nichts stichfestes ein, ist aber auch schon spät). Ich hätte zumindest erwartet, daß es in etwa gleich schnell läuft.
[/quote3]
Bitte glaube nicht alles was in der Werbung steht... Soll ich dir mal nen großes Geheimnis verraten? Wenn deine Software recht alt ist dann läuft die eh auf 32 Bit - egal was für nen OS darunter liegt. Und selbst wenn du nur den MS-SQL-Server nimmst: Natürlich läuft der mit mehr RAM besser - sofern der das dann auch nutzt. Bei schlechten Abfragen bringt dir das wenig. Hier würde dir eine genaue Analyse der DB mehr helfen...
Was ich aber an der Sache klasse finde: "evtl. noch andere Vorteile (mir fällt zwar nicht stichfestes ein...." -> Hmm, ich weiss nicht ob es was bringt, ich weiss nicht genau wie ich es mache -> aber ich laufe schonmal los und kaufe die Teile?!? Bitte sag mir jetzt das da IRGENDWAS anderes mit gemeint war! Denn wenn du mir sagst das du nur mal so aus Verdacht an nem System drehst welches du nicht wirklich kennst und was mit großer Sicherheit nicht unwichtig ist (bei 40-60 Leuten die daran arbeiten) fall ich hier rückwärts vom Stuhl!
Also mein Tipp: Ich werde dir sicher nicht den Kopf wegen ein paar Ungenauigkeiten abschlagen. Wenn du es aber mit dem Stand was du hier gibst wirklich umsetzt bin ich nicht sicher ob das für deinen Chef oder den Kunden auch gilt... Ich würde dir allerdings empfehlen dich erstmal ein wenig mit Datenbanken, den möglichen Analysemöglichkeiten und der ganzen Theorie dahinter zu beschäftigen bevor du an nen Live-System gehst...
ok, 1 Semester Datenbanken und du gehst an so ein System ran? Ich weiss nicht ob ich das mit Mut oder - sorry - dummheit beschreiben soll... Meine Tendenz geht allerdings eher zum letzteren. Grad wenn du dich für das Thema eigentlich nie intressiert hast...
Fangen wir mal ganz simpel an:
[quote]
enn wenn ich mir die tausenden Tabellen anschaue, die da drin sind und die Fülle von SQL Abfragen die an den Server gesendet werden, wenn ich das Programm nur starte (ohne mich einzuloggen oder gar Informationen heraus zu lesen), dann muss das schon heftig sein.
[/quote]
Also ist das für dich schon nen kriterium?
for (int i=0;i<100000;i++) mysql_query("Select 1 from benutzer");
-> Macht auch 100.000 Anfragen... Und ob ein Programm dann gut ist oder nicht siehst du eher daran wie derjenige die Tabellen aufgebaut hat, wie die Abfragen gebaut wurden usw... Nehmen wir nur mal an du hast 3 Tabellen:
[TBL1]
Name (Varchar50)
Vorname (Varchar50)
Geburtsdatum (Date)
[TBL2]
Name (Varchar50)
Vorname (Varchar50)
Fahrzeug (Varchar50)
[TBL3]
Name (Varchar50)
Vorname (Varchar50)
Schulabschluss (Varchar50)
Sieht ja erstmal gut aus -> allerdings wenn du da mal nen paar Tausend einträge hast wirst du sehen das die Text-Vergleiche nicht wirklich schnell sind... Hier gibt es dann elegantere Lösungen:
TBL1]
ID(Integer, AutoIncrement)
Name (Varchar50)
Vorname (Varchar50)
Geburtsdatum (Date)
[TBL2]
PersonenID (Integer)
Fahrzeug (Varchar50)
[TBL3]
PersonenID (Integer)
Schulabschluss (Varchar50)
-> das würde mit Sicherheit um einiges schneller laufen...
Das schonmal zur Datenbank-Theorie "Grundlagen"... Nur weil ein Programm viele Tabellen enthält oder 1000ende Abfragen wirft ist das nichtmal ANSATZWEISE ein Kriterium für gute Programmierung!
[quote2]
Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck müsste ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht darf. Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze aufs Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie geklappt.
[/quote]
Am Wochenende die DB stoppen auf ein Ersatzsystem bringen und erstmal prüfen. GRADE wenn man keine Erfahrung hat sollte man sowas nicht im Betrieb machen. Nehmen wir an dieser Stelle mal an du bist bei einem Lager. Jemand liefert dir 2 KG Gold an - leider exportierst du grad die DB und die Lager-Bestandstabelle ist wegen des Exportes grad gesperrt. Dummerweise hat der Entwickler der Software nicht an sowas gedacht und das Programm wirft auch keinen Fehler aus (bzw. kann nix auswerfen da die Einlagerung durch Handscanner gemeldet wird). Tja - schade eigentlich... Bei dir liegen grad 2 KG Gold rum und keiner weiss mehr woher die kommen und wofür die sind -> aber keine Sorge, wenn das Auftritt komm ich vorbei und entsorge die für euch... Nur wenn das von deinem Gehalt abgezogen wird solltest du besser schnell umziehen...
[quote3]
Mein grundsätzlicher Gedanke war der, daß eine, sagen wir, vergleichbare Maschine mit einer so großen Datenmenge doch theoretisch besser klar kommen sollte, wenn ein 64 Bit Betriebssystem darunter liegt und das Programm selbst auch als 64 Bit Variante läuft. Damit meinte ich jetzt weniger den Vorteil daß ich mehr als 4 GB Arbeitsspeicher nutzen kann sondern evtl. noch andere Vorteile (mir fällt zwar auf anhieb nichts stichfestes ein, ist aber auch schon spät). Ich hätte zumindest erwartet, daß es in etwa gleich schnell läuft.
[/quote3]
Bitte glaube nicht alles was in der Werbung steht... Soll ich dir mal nen großes Geheimnis verraten? Wenn deine Software recht alt ist dann läuft die eh auf 32 Bit - egal was für nen OS darunter liegt. Und selbst wenn du nur den MS-SQL-Server nimmst: Natürlich läuft der mit mehr RAM besser - sofern der das dann auch nutzt. Bei schlechten Abfragen bringt dir das wenig. Hier würde dir eine genaue Analyse der DB mehr helfen...
Was ich aber an der Sache klasse finde: "evtl. noch andere Vorteile (mir fällt zwar nicht stichfestes ein...." -> Hmm, ich weiss nicht ob es was bringt, ich weiss nicht genau wie ich es mache -> aber ich laufe schonmal los und kaufe die Teile?!? Bitte sag mir jetzt das da IRGENDWAS anderes mit gemeint war! Denn wenn du mir sagst das du nur mal so aus Verdacht an nem System drehst welches du nicht wirklich kennst und was mit großer Sicherheit nicht unwichtig ist (bei 40-60 Leuten die daran arbeiten) fall ich hier rückwärts vom Stuhl!
Also mein Tipp: Ich werde dir sicher nicht den Kopf wegen ein paar Ungenauigkeiten abschlagen. Wenn du es aber mit dem Stand was du hier gibst wirklich umsetzt bin ich nicht sicher ob das für deinen Chef oder den Kunden auch gilt... Ich würde dir allerdings empfehlen dich erstmal ein wenig mit Datenbanken, den möglichen Analysemöglichkeiten und der ganzen Theorie dahinter zu beschäftigen bevor du an nen Live-System gehst...
Die Abfragen gehen über das Netz??? Wie genau sieht denn die IT Infrastuktur aus bei dir?? -> DB Server wie viele, wie angebunden (NIC Anzahl, Gigabit, Noname NIC oder was gutes), wie sind die Clients angebunden, was hängt ander DB noch mit dran.
Da der Umstieg auf bessere Hardware garnichts gebracht hat liegt die Vermutung nahe das dein Flaschenhals nicht im DB Server liegt.
Da der Umstieg auf bessere Hardware garnichts gebracht hat liegt die Vermutung nahe das dein Flaschenhals nicht im DB Server liegt.
Moin,
[quote]
Ich sitze lediglich an der Hardware und versuche ihn zu unterstützen.
[/quote]
Das hört sich auf jeden Fall schonmal besser an. Das Problem an der Sache: Nur die Hardware bringt dir nichts. Das ist - bildlich gesprochen - als wenn du nen Motor von nem Trabant nimmst und da nen Ferrari umzubaust. Ich bin mir zimlich sicher das die Konstruktion auch gut aussehen würde - sie würde auch funktionieren. Nur "schnell" würde die vermutlich nicht werden...
Also muss dein Kollege erstmal gucken wo denn die Säge überhaupt klemmt. Dann kann man gucken wie man das Problem angeht.
[quote]
Auch hier hast Du wieder wahr, allerdings ging es erst einmal nur um das Testen, ob denn der neue Rechner sich wirklich dafür eignet. Wenn (aus welchen Gründen auch immer) das neue System genau so schnell sein sollte wie das alte, dann brauchen wir das auch nicht umzustellen.
[/quote]
Hier kommt jetzt ein Problem welches ebenfalls speziell für Datenbanken ist. Deshalb auch mein Beispiel oben mit den Tabellen. Du hast da von mir aus 1.000.000 Einträge drin. Jetzt hast du das System kopiert - und dann? Solange du alleine darauf arbeitest hast du kaum Last auf dem System -> d.h. das Teil würde ggf. immernoch rennen wie hölle. Kommen jetzt aber 40-60 User darauf dann geht die Performance extrem nach Unten -> die Vergleiche kosten zuviel Zeit und die Leute sind gleichzeitig am Arbeiten... Um ehrlich zu sein -> ich bin mir SICHER das euer System nicht so stupide ist wie mein erstes Beispiel das angedeutet hätte - da dann das System nicht arbeiten würde! Du kannst aber auch nicht einfach beide Systeme gleichzeitig nutzen -> da du vermutlich keine Option für nen Cluster hast und du somit sicherstellen musst das die schreibenen Zugriffe immer auf derselben DB laufen (bei nem Cluster könntest du mit beiden DBs gleichzeitig arbeiten da das Cluster-Mgmt dafür sorgt das die Daten abgeglichen werden).
Auch hier bleiben also nur 2 Optionen:
a) Ihr setzt euch erstmal hin und macht ne Analyse wo die Säge klemmt. DANN könnt ihr hingehen und euch um das beheben kümmern.
b) Ihr baut am WE den DB-Server ganz hart um und bringt den in Betrieb. Dann lasst ihr den laufen und guckt im Betrieb wie die Performance ist. (Jeder Datenbank-Admin wird euch steinigen wenn ihr dem sagt das ihr das so gemacht habt - aber ihr seid sicher weder die ersten noch die letzten die dieses Vorgehen praktizieren)
Allerdings riskierst du eben bei Option b auch das du ne Menge Geld in Rauch aufgehen lässt. Denn was machst du wenn du am Ende rausfindest das ein Parameter den Fehler verursacht hat (bei MySQL z.B. das Speicherlimit auf 2 MB statt auf 2 GB gesetzt...)? Sofern du die Einstellungen 1:1 auf den neuen Server übernimmst wird die Kiste natürlich auch lahm ohne Ende sein - und wenn du das richtig einstellst dann wäre auch die alte Kiste ne Rennziege...
Was das 64-Bit-OS angeht: Die frage ist viel mehr: Welche VORTEILE bringt das OS für dich? Hast du mehr als 3,5 GB RAM? (Je nach Größe der DB wäre ein Nein auf diese Antwort allerdings auch gleich ein Ansatzpunkt um das gleich in einem Go zu ändern). Welchen sonstigen Vorteil bringt das? Und: Ist das System vom Hersteller der Software auch freigegeben? Ich muss hier ehrlich sagen das ich es bei MS-SQL nicht genau weiss -> aber was ist wenn die (mal wieder) ein Wenig am SQL-Standard gedreht haben? Und die Version 2010 vom SQL-Server (was auch immer die aktuelle Version ist) macht leider einen Befehl nur ein klein wenig anders als die Version 2000 (was auch immer ihr für eine habt)? D.h. erstmal muss hier der Software-Entwickler ein grünes Licht geben und den SQL-Server freigegeben haben. Alles andere wäre leichtsinnig -> da die Fehler ggf. im Detail liegen...
[quote]
gut, sicherlich hast Du auch hier wieder Recht, allerdings kann ich, selbst wenn ich feststellen sollte, daß die Anfragen und das Design der Datenbank total überholt sind, immer noch nichts daran ändern
[/quote]
Ich meinte damit NICHT das du die Anfragen ansehen sollst. Ein DB-Analysetool sagt dir eine ganze Menge mehr als nur wie die Querys aussehen. Z.B. wieviele Cache-Hits du im Betrieb erzielst. Ist die Rate hier extrem gering (und das Verhältnis wirklich 70/30 für Lesenden Zugriff) dann kann man sich darüber gedanken machen wie man das Optimiert. Sieht man z.B. gleichzeitig das der Speicher für die DB immer bei 100% ausgenutzt ist dann ist da ein guter Moment über eine simple Speichererweiterung nachzudenken. Siehst du z.B. das die Anzahl der gleichzeitigen Verbindungen immer am Limit liegt dann kann man darüber nachdenken diese zu erhöhen -> der Server kann noch so schnell sein - wenn die Anwendung immer erst auf ne freie Verbindung warten muss dann hilft das wenig! Siehst du z.B. das der Traffic der DB immer am Limit ist dann wechselt man einfach die 100er NIC gegen ne GBit-Karte aus -> auch hier bringt dir ein schnellerer Server mit ner 100er NIC wenig... Dies wären alles Maßnahmen die für recht schmales Geld (selbst 100 Euro für ne gute GBit-NIC ist glaub ich nicht sooo viel) mehr bringen können als nen ganzer Server. Und natürlich gibt es da noch eine ganze menge mehr Optionen!
Erst wenn man das wirklich mal durchgegangen ist dann kann man ne gute Entscheidung treffen ob man jetzt was ändert und an welcher Schraube man dreht. Alles andere ist - meines Erachtens - einfach nur Geld verbrennen. Wenn du für die Hardware zuständig bist -> was würdest du sagen wenn dein Bekannter bei dir ankommt und sagt das er nen Dual-CPU mit je 4 Cores als Rechner haben will - aber da dann nur 512 MB RAM reinbügelt. Natürlich als OS dann Win-7. Würdest du ihm den Rechner so zusammenbauen oder lieber auf eine CPU verzichten dafür aber 2 GB (o. mehr) RAM einbauen?
[quote]
Ich sitze lediglich an der Hardware und versuche ihn zu unterstützen.
[/quote]
Das hört sich auf jeden Fall schonmal besser an. Das Problem an der Sache: Nur die Hardware bringt dir nichts. Das ist - bildlich gesprochen - als wenn du nen Motor von nem Trabant nimmst und da nen Ferrari umzubaust. Ich bin mir zimlich sicher das die Konstruktion auch gut aussehen würde - sie würde auch funktionieren. Nur "schnell" würde die vermutlich nicht werden...
Also muss dein Kollege erstmal gucken wo denn die Säge überhaupt klemmt. Dann kann man gucken wie man das Problem angeht.
[quote]
Auch hier hast Du wieder wahr, allerdings ging es erst einmal nur um das Testen, ob denn der neue Rechner sich wirklich dafür eignet. Wenn (aus welchen Gründen auch immer) das neue System genau so schnell sein sollte wie das alte, dann brauchen wir das auch nicht umzustellen.
[/quote]
Hier kommt jetzt ein Problem welches ebenfalls speziell für Datenbanken ist. Deshalb auch mein Beispiel oben mit den Tabellen. Du hast da von mir aus 1.000.000 Einträge drin. Jetzt hast du das System kopiert - und dann? Solange du alleine darauf arbeitest hast du kaum Last auf dem System -> d.h. das Teil würde ggf. immernoch rennen wie hölle. Kommen jetzt aber 40-60 User darauf dann geht die Performance extrem nach Unten -> die Vergleiche kosten zuviel Zeit und die Leute sind gleichzeitig am Arbeiten... Um ehrlich zu sein -> ich bin mir SICHER das euer System nicht so stupide ist wie mein erstes Beispiel das angedeutet hätte - da dann das System nicht arbeiten würde! Du kannst aber auch nicht einfach beide Systeme gleichzeitig nutzen -> da du vermutlich keine Option für nen Cluster hast und du somit sicherstellen musst das die schreibenen Zugriffe immer auf derselben DB laufen (bei nem Cluster könntest du mit beiden DBs gleichzeitig arbeiten da das Cluster-Mgmt dafür sorgt das die Daten abgeglichen werden).
Auch hier bleiben also nur 2 Optionen:
a) Ihr setzt euch erstmal hin und macht ne Analyse wo die Säge klemmt. DANN könnt ihr hingehen und euch um das beheben kümmern.
b) Ihr baut am WE den DB-Server ganz hart um und bringt den in Betrieb. Dann lasst ihr den laufen und guckt im Betrieb wie die Performance ist. (Jeder Datenbank-Admin wird euch steinigen wenn ihr dem sagt das ihr das so gemacht habt - aber ihr seid sicher weder die ersten noch die letzten die dieses Vorgehen praktizieren)
Allerdings riskierst du eben bei Option b auch das du ne Menge Geld in Rauch aufgehen lässt. Denn was machst du wenn du am Ende rausfindest das ein Parameter den Fehler verursacht hat (bei MySQL z.B. das Speicherlimit auf 2 MB statt auf 2 GB gesetzt...)? Sofern du die Einstellungen 1:1 auf den neuen Server übernimmst wird die Kiste natürlich auch lahm ohne Ende sein - und wenn du das richtig einstellst dann wäre auch die alte Kiste ne Rennziege...
Was das 64-Bit-OS angeht: Die frage ist viel mehr: Welche VORTEILE bringt das OS für dich? Hast du mehr als 3,5 GB RAM? (Je nach Größe der DB wäre ein Nein auf diese Antwort allerdings auch gleich ein Ansatzpunkt um das gleich in einem Go zu ändern). Welchen sonstigen Vorteil bringt das? Und: Ist das System vom Hersteller der Software auch freigegeben? Ich muss hier ehrlich sagen das ich es bei MS-SQL nicht genau weiss -> aber was ist wenn die (mal wieder) ein Wenig am SQL-Standard gedreht haben? Und die Version 2010 vom SQL-Server (was auch immer die aktuelle Version ist) macht leider einen Befehl nur ein klein wenig anders als die Version 2000 (was auch immer ihr für eine habt)? D.h. erstmal muss hier der Software-Entwickler ein grünes Licht geben und den SQL-Server freigegeben haben. Alles andere wäre leichtsinnig -> da die Fehler ggf. im Detail liegen...
[quote]
gut, sicherlich hast Du auch hier wieder Recht, allerdings kann ich, selbst wenn ich feststellen sollte, daß die Anfragen und das Design der Datenbank total überholt sind, immer noch nichts daran ändern
[/quote]
Ich meinte damit NICHT das du die Anfragen ansehen sollst. Ein DB-Analysetool sagt dir eine ganze Menge mehr als nur wie die Querys aussehen. Z.B. wieviele Cache-Hits du im Betrieb erzielst. Ist die Rate hier extrem gering (und das Verhältnis wirklich 70/30 für Lesenden Zugriff) dann kann man sich darüber gedanken machen wie man das Optimiert. Sieht man z.B. gleichzeitig das der Speicher für die DB immer bei 100% ausgenutzt ist dann ist da ein guter Moment über eine simple Speichererweiterung nachzudenken. Siehst du z.B. das die Anzahl der gleichzeitigen Verbindungen immer am Limit liegt dann kann man darüber nachdenken diese zu erhöhen -> der Server kann noch so schnell sein - wenn die Anwendung immer erst auf ne freie Verbindung warten muss dann hilft das wenig! Siehst du z.B. das der Traffic der DB immer am Limit ist dann wechselt man einfach die 100er NIC gegen ne GBit-Karte aus -> auch hier bringt dir ein schnellerer Server mit ner 100er NIC wenig... Dies wären alles Maßnahmen die für recht schmales Geld (selbst 100 Euro für ne gute GBit-NIC ist glaub ich nicht sooo viel) mehr bringen können als nen ganzer Server. Und natürlich gibt es da noch eine ganze menge mehr Optionen!
Erst wenn man das wirklich mal durchgegangen ist dann kann man ne gute Entscheidung treffen ob man jetzt was ändert und an welcher Schraube man dreht. Alles andere ist - meines Erachtens - einfach nur Geld verbrennen. Wenn du für die Hardware zuständig bist -> was würdest du sagen wenn dein Bekannter bei dir ankommt und sagt das er nen Dual-CPU mit je 4 Cores als Rechner haben will - aber da dann nur 512 MB RAM reinbügelt. Natürlich als OS dann Win-7. Würdest du ihm den Rechner so zusammenbauen oder lieber auf eine CPU verzichten dafür aber 2 GB (o. mehr) RAM einbauen?
Zitat von @wiesi200:
> Zitat von @kruemeltee:
> ----
> Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck
müsste
> ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht
darf.
> Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze
aufs
> Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die
> Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie
geklappt.
>
Wie währ's mit einer einfachen Datensicherung, das werdet ihr unterm laufenden Betrieb machen? In der Management Konsole
einfach die Datenbank wegsichern und auf dem zweiten Server wiederherstellen.
>
> Zitat von @kruemeltee:
> ----
> Das Problem Nr. 1 ist, ich kann die Datenbank leider nur schlecht "exportieren" ... für diesen Zweck
müsste
> ich über das Management Studio den Server stoppen und die Datenbank aushängen, was ich leider nicht kann und nicht
darf.
> Die Datenbank muss also mehr oder weniger im laufenden Betrieb "kopiert" werden (anderen Falls muss ich das ganze
aufs
> Wochenende verschieben und da sollte ich schon wissen, ob es klappt oder nicht). Zwar gibt es in der Management Konsole die
> Möglichkeit, die Datenbank im laufenden Betrieb zu "exportieren", aber leider hat das bei uns noch nie
geklappt.
>
Wie währ's mit einer einfachen Datensicherung, das werdet ihr unterm laufenden Betrieb machen? In der Management Konsole
einfach die Datenbank wegsichern und auf dem zweiten Server wiederherstellen.
>
Um die Sache etwas zu präzisieren, eine DB-Sicherung kann im laufenden Betrieb gemacht werden und ist sehr einfach zu bewerkstelligen.
Im Managementstudio mit der rechten Maustaste auf die zu sichernde DB klicken -> Tasks -> Sichern
Indem folgenden Dialog können die Einstellungen i. d. R. unverändert bleiben. Sichrungstyp muss auf vollständig stehen. Mit <ok> bestätigen und die Sicherung beginnt.
mfg