21
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
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 141987
Url: https://administrator.de/contentid/141987
Printed on: April 23, 2024 at 15:04 o'clock
21 Comments
Latest comment
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)
okay, ich habe das feinfüßige "MS" vor dem SQL 2008 bzw. SQL 2003 vergessen ... auf denen läuft also auf der einen Seite Microsoft Windows Server 2003 R2 (32 Bit) mit Microsoft SQL Server 2003 (32 bit) und auf der anderen Seite mit Microsoft 2003 Server x64 und Microsoft SQL Server 2008 x64
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. Die Frage wäre jetzt, wie würdest Du die Datenbank von einem bestehenden MS-SQL Server 2003 32 Bit in ein frisches MS-SQL-Server 2008 64 Bit migrieren?
mit freundlichem Gruß
Maddin
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. Die Frage wäre jetzt, wie würdest Du die Datenbank von einem bestehenden MS-SQL Server 2003 32 Bit in ein frisches MS-SQL-Server 2008 64 Bit migrieren?
mit freundlichem Gruß
Maddin
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...
Also ich will jetzt nicht rummosern, Access ist ein Frontend für eine Datenbank, welches man selbst auch als Datenbank mißbrauchen kann....
und der TO spricht eindeutig von nem MS-SQL-Server, und der ist ne DB....
Gruß
24
und der TO spricht eindeutig von nem MS-SQL-Server, und der ist ne DB....
Gruß
24
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
also ... zwecks den Logdateien werd ich noch einmal schauen, vielen Dank erst einmal für den Hinweis ...
zu der Diskussion ... ich habe genau 1 Semester Datenbanken gehabt und wahnsinnig interessiert hat es mich nicht wirklich. Ich weiß allerdings, daß sich bei diesem Thema schnell die Geister voneinander scheiden ... aber selbst SQL ist nicht gleich SQL wie ich leider selbst hier (und damit meine ich nicht das Forum) erfahren musste.
Was die Struktur anbetrifft, diese können wir leider nicht neu schreiben oder gar bearbeiten. Wir nutzen hier ein komplexes Informationssystem hinter dem eine SQL Datenbank steht. Das System selber wurde für seeehr viel Geld eingekauft, denn davon gibts nicht so sonderlich viele auf dem Markt. Ich vermute aber, daß die Leute die dahinter sitzen schon Ahnung vom Programmieren und Entwerfen von Datenbanken haben, denn 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.
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.
Was den Server und die Ungenauigkeit der Festplatten anbetrifft ... unser IBM e-Server läuft mit 2 Festplatten (10k U/min; je 40 GB) im Raid 1 Verbund. Auf den SQL Server haben im Schnitt 40-60 Leute gleichzeitig Zugriff. Das kommt nur auf die Nutzung des Programms an. Wieviele Anfragen da gleichzeitig auflaufen kann ich nicht sagen, aber es scheint eine Menge zu sein. Ich würde evtl. morgen noch einmal nen trace laufen lassen, aber das kann ich schlecht unter genormten Bedingungen laufen lassen, denn ich glaube daß die Anzahl der Anfragen an den SQL Server auch vom Inhalt des Programms abhängig ist.
Auf die Frage, was hauptsächlich in der Datenbank gemacht wird würde ich behaupten etwa 70% lesen und etwa 30% schreibender Zugriff. Es werden deutlich häufiger bereits enthaltene Daten gelesen als neue hinzugefügt. Was allerdings alles in den Untiefen dieser tausenden Tabellen drin steckt (wer wann was wo angeschaut hat) kann ich natürlich nicht sagen. Demzufolge behaupte ich, daß zu den normalen Fällen des tatsächlichen "Daten hinzufügens" bestimmt noch ettliche Schreibaktionen hinzukommen wo bestimmte Userwerte eingetragen bzw. korrigiert werden.
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.
Den Test (mit dem wir heraus finden wollen, ob das "neue" System tatsächlich schneller läuft als das alte) ist eine komplexe Berechnung durch das Programm jagen zu lassen. Diese dauert zwischen 3 und 4 Stunden auf dem "alten" System. Leider braucht sie hier genau so lange auf dem neuen Rechner und hier hätte ich nun eben erwartet, daß sie etwas schneller laufen sollte. Vielleicht ist dieser Gedanke allerdings auch nur Wunsch-Denken ...
mit freundlichen und nächtlichen Grüßen
Maddin
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!
zu der Diskussion ... ich habe genau 1 Semester Datenbanken gehabt und wahnsinnig interessiert hat es mich nicht wirklich. Ich weiß allerdings, daß sich bei diesem Thema schnell die Geister voneinander scheiden ... aber selbst SQL ist nicht gleich SQL wie ich leider selbst hier (und damit meine ich nicht das Forum) erfahren musste.
Was die Struktur anbetrifft, diese können wir leider nicht neu schreiben oder gar bearbeiten. Wir nutzen hier ein komplexes Informationssystem hinter dem eine SQL Datenbank steht. Das System selber wurde für seeehr viel Geld eingekauft, denn davon gibts nicht so sonderlich viele auf dem Markt. Ich vermute aber, daß die Leute die dahinter sitzen schon Ahnung vom Programmieren und Entwerfen von Datenbanken haben, denn 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.
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.
Was den Server und die Ungenauigkeit der Festplatten anbetrifft ... unser IBM e-Server läuft mit 2 Festplatten (10k U/min; je 40 GB) im Raid 1 Verbund. Auf den SQL Server haben im Schnitt 40-60 Leute gleichzeitig Zugriff. Das kommt nur auf die Nutzung des Programms an. Wieviele Anfragen da gleichzeitig auflaufen kann ich nicht sagen, aber es scheint eine Menge zu sein. Ich würde evtl. morgen noch einmal nen trace laufen lassen, aber das kann ich schlecht unter genormten Bedingungen laufen lassen, denn ich glaube daß die Anzahl der Anfragen an den SQL Server auch vom Inhalt des Programms abhängig ist.
Auf die Frage, was hauptsächlich in der Datenbank gemacht wird würde ich behaupten etwa 70% lesen und etwa 30% schreibender Zugriff. Es werden deutlich häufiger bereits enthaltene Daten gelesen als neue hinzugefügt. Was allerdings alles in den Untiefen dieser tausenden Tabellen drin steckt (wer wann was wo angeschaut hat) kann ich natürlich nicht sagen. Demzufolge behaupte ich, daß zu den normalen Fällen des tatsächlichen "Daten hinzufügens" bestimmt noch ettliche Schreibaktionen hinzukommen wo bestimmte Userwerte eingetragen bzw. korrigiert werden.
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.
Den Test (mit dem wir heraus finden wollen, ob das "neue" System tatsächlich schneller läuft als das alte) ist eine komplexe Berechnung durch das Programm jagen zu lassen. Diese dauert zwischen 3 und 4 Stunden auf dem "alten" System. Leider braucht sie hier genau so lange auf dem neuen Rechner und hier hätte ich nun eben erwartet, daß sie etwas schneller laufen sollte. Vielleicht ist dieser Gedanke allerdings auch nur Wunsch-Denken ...
mit freundlichen und nächtlichen Grüßen
Maddin
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!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 genugda!
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
okay ... nur so aus Interesse (vielleicht baue ich das ja auch zusammen) aber in welchem Raid würdest Du die 10 Platten zusammen werfen?
Gruß Maddin
Gruß Maddin
Raid 10, alles andere hat nicht die Performance
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...
Erst einmal Danke für diese ausführliche Kritik und für Deine Voreingenommenheit 
Ich selbst sitze nicht an der Datenbank, das macht mein Kollege. Ich sitze lediglich an der Hardware und versuche ihn zu unterstützen. Ob Mut oder Dummheit würde ich hier gar nicht zur Diskussion stellen wollen. Aber dennoch finde ich, daß lediglich diese zwei Optionen angeboten werden, trotzdem nicht sonderlich schön! Aber ich versuche ja, Kritikfreudig zu sein.
Auch wenn es nicht so aussieht, aber ein wenig Ahnung habe ich davon schon, vielleicht bei weitem nicht so viel wie Du, allerdings bin ich mir schwer bewusst, daß ich mit einer einzigen Anfrage auf die DB mehr Rechenleistung produzieren kann als mit tausenden von kleinen. Trotzdem danke nochmal für das Beispiel!
Das mag auch sein, allerdings kann keiner hier etwas daran ändern! Egal ob die DB nun gut durchstrukturiert ist und ob die Anfragen auch sinnvoll sind (und der Bewertung dafür entziehe ich mich einfach), wir können aus technischen Gründen (und sogar aus juristischen) daran nichts ändern.
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.
Wenn es nur um 2 KG Gold gehen würde, dann wäre das ganze ja noch nicht mal sooo schlimm. (Und raste jetzt nicht gleich wieder aus, wie denn jemand wie ich mit so hochsensiblen Daten überhaupt in Kontakt geraten kann)
Ich habe seit mehr als 10 Jahren keinen Fernseher mehr, bin also was Werbung anbetrifft total unempfänglich! Und dein Großes Geheimnis ist gar kein solches! Aber wenn ich eine 64 Bit Maschine (Hardware) besitze, dieser ein 64 Bit OS dahinter klemme und dann noch eine 64 Bit Software, dann kann ich davon ausgehen daß hier nichts alt ist und noch auf 32 Bit läuft. Auf welcher Architektur die letztendliche Software läuft spielt in diesem Augenblick sowieso keine Rolle, denn die Anfragen an die Datenbank kommen eh übers Netz ... (oder liege ich hier falsch?)
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.
dann sorge bitte dafür, daß hinter Dir ein weiches und großes Kissen liegt! Zu allem anderen will ich nichts sagen, besonders weil ich nicht genau weiß, wann genau ich Dir auf den Schlips getreten bin.
mit freundlichen Grüßen
Maddin
P.S.: Administratoren, die in ihrem stillem Kämmerchen sitzen, Cola und Chips vernaschen und bei der Anfrage "mein Drucker geht nicht" die Augen verrollen erinnern mich immer wieder schwer an den BOFH
P.P.S.: meine Frage war viel mehr, ob sich bei der Konfiguration des neues Rechners (OS seitig) und vielleicht in der Konfiguration des SQL Servers aufgrund der Architektur- als auch Hardwareunterschiede etwas ändern muss/kann.
Zitat von @maretz:
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...
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...
Ich selbst sitze nicht an der Datenbank, das macht mein Kollege. Ich sitze lediglich an der Hardware und versuche ihn zu unterstützen. Ob Mut oder Dummheit würde ich hier gar nicht zur Diskussion stellen wollen. Aber dennoch finde ich, daß lediglich diese zwei Optionen angeboten werden, trotzdem nicht sonderlich schön! Aber ich versuche ja, Kritikfreudig zu sein.
Zitat von @maretz:
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...
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...
Auch wenn es nicht so aussieht, aber ein wenig Ahnung habe ich davon schon, vielleicht bei weitem nicht so viel wie Du, allerdings bin ich mir schwer bewusst, daß ich mit einer einzigen Anfrage auf die DB mehr Rechenleistung produzieren kann als mit tausenden von kleinen. Trotzdem danke nochmal für das Beispiel!
Zitat von @maretz:
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!
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!
Das mag auch sein, allerdings kann keiner hier etwas daran ändern! Egal ob die DB nun gut durchstrukturiert ist und ob die Anfragen auch sinnvoll sind (und der Bewertung dafür entziehe ich mich einfach), wir können aus technischen Gründen (und sogar aus juristischen) daran nichts ändern.
Zitat von @maretz:
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.
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.
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.
Zitat von @maretz:
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...
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...
Wenn es nur um 2 KG Gold gehen würde, dann wäre das ganze ja noch nicht mal sooo schlimm. (Und raste jetzt nicht gleich wieder aus, wie denn jemand wie ich mit so hochsensiblen Daten überhaupt in Kontakt geraten kann)
Zitat von @maretz:
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.
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.
Ich habe seit mehr als 10 Jahren keinen Fernseher mehr, bin also was Werbung anbetrifft total unempfänglich! Und dein Großes Geheimnis ist gar kein solches! Aber wenn ich eine 64 Bit Maschine (Hardware) besitze, dieser ein 64 Bit OS dahinter klemme und dann noch eine 64 Bit Software, dann kann ich davon ausgehen daß hier nichts alt ist und noch auf 32 Bit läuft. Auf welcher Architektur die letztendliche Software läuft spielt in diesem Augenblick sowieso keine Rolle, denn die Anfragen an die Datenbank kommen eh übers Netz ... (oder liege ich hier falsch?)
Zitat von @maretz:
Bei schlechten Abfragen bringt dir das wenig. Hier würde dir eine genaue Analyse der DB mehr helfen...
Bei schlechten Abfragen bringt dir das wenig. Hier würde dir eine genaue Analyse der DB mehr helfen...
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.
Zitat von @maretz:
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...
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...
dann sorge bitte dafür, daß hinter Dir ein weiches und großes Kissen liegt! Zu allem anderen will ich nichts sagen, besonders weil ich nicht genau weiß, wann genau ich Dir auf den Schlips getreten bin.
mit freundlichen Grüßen
Maddin
P.S.: Administratoren, die in ihrem stillem Kämmerchen sitzen, Cola und Chips vernaschen und bei der Anfrage "mein Drucker geht nicht" die Augen verrollen erinnern mich immer wieder schwer an den BOFH
P.P.S.: meine Frage war viel mehr, ob sich bei der Konfiguration des neues Rechners (OS seitig) und vielleicht in der Konfiguration des SQL Servers aufgrund der Architektur- als auch Hardwareunterschiede etwas ändern muss/kann.
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.
haben wir auch schon vermutet ...
unsere Infrastruktur sieht in etwa wie folgt aus ... wir haben insgesamt 6 Subnetze, jedes mit einer eigenen Firewall getrennt.
Subnetz 1:
2 Terminalserver (Windows 2003 R2)
SQL Server
ca. 50 Clients welche mitunter via RDP auf die beiden Terminalserver zugreifen.
Subnetz 2:
1 Terminalserver (Windows 2003 R2)
ca. 20 Clients (RDP Sitzungen)
Subnetz 3:
1 Terminalserver (Windows 2003 R2)
ca. 15 Clients (RDP Sitzung)
Subnetz 4:
ca 5 Clients (RDP Sitzung auf Terminalserver in Subnetz 1)
die restlichen Subnetze sind etwa ähnlich wie Subnetz 4.
Innerhalb der jeweiligen Subnetze ist alles mit Gigabit verbunden, Switche sind mitunter von D-Link und Level One. Die Subnetze selbst sind mit VPN Tunnel verbunden und mit unterschiedlichsten Internetanbindungen ausgestattet, das ganze bewegt sich zwischen 2 und 10 MBit (synchron).
Daß aus Subnetz 3, welches die Anfragen an den SQL Server stellt, der lediglich mit 2-10 MBit verbunden ist, langsam ist, ist mir auch klar. Wir werden demnächst auch die Struktur gewaltig ändern müssen (Plan liegt schon vor). Ziel ist es zum Schluss, daß alle Terminalserver und der SQL Server in einem Subnetz hängen und komplett via Gigabit verbunden sind. Die Terminal-Sitzungen planen wir dann über die VPN-Tunnel zu senden (in der Hoffnung, daß die Leitungen dafür ausreichend sind und die Bild-Daten, die pro Sitzung übertragen werden nicht immer ein komplettes Bild sonder die sich nur verändernden Pixel überträgt, das testen wir aber noch aus).
Zu unserem Testszenario:
wir haben sowohl den SQL Server mit 32 Bit als auch den mit 64 Bit getestet als dieser im selben Subnetz war (Gigabit Leitung). Der Unterschied war eben nicht wirklich vorhanden, zumindest subjektiv gesehen.
Am DB hängt nichts weiter dran, da läuft nur diese eine Datenbank drauf, und die Terminal-Server schicken Ihre Anfragen an eben diesen.
Gruß Maddin
unsere Infrastruktur sieht in etwa wie folgt aus ... wir haben insgesamt 6 Subnetze, jedes mit einer eigenen Firewall getrennt.
Subnetz 1:
2 Terminalserver (Windows 2003 R2)
SQL Server
ca. 50 Clients welche mitunter via RDP auf die beiden Terminalserver zugreifen.
Subnetz 2:
1 Terminalserver (Windows 2003 R2)
ca. 20 Clients (RDP Sitzungen)
Subnetz 3:
1 Terminalserver (Windows 2003 R2)
ca. 15 Clients (RDP Sitzung)
Subnetz 4:
ca 5 Clients (RDP Sitzung auf Terminalserver in Subnetz 1)
die restlichen Subnetze sind etwa ähnlich wie Subnetz 4.
Innerhalb der jeweiligen Subnetze ist alles mit Gigabit verbunden, Switche sind mitunter von D-Link und Level One. Die Subnetze selbst sind mit VPN Tunnel verbunden und mit unterschiedlichsten Internetanbindungen ausgestattet, das ganze bewegt sich zwischen 2 und 10 MBit (synchron).
Daß aus Subnetz 3, welches die Anfragen an den SQL Server stellt, der lediglich mit 2-10 MBit verbunden ist, langsam ist, ist mir auch klar. Wir werden demnächst auch die Struktur gewaltig ändern müssen (Plan liegt schon vor). Ziel ist es zum Schluss, daß alle Terminalserver und der SQL Server in einem Subnetz hängen und komplett via Gigabit verbunden sind. Die Terminal-Sitzungen planen wir dann über die VPN-Tunnel zu senden (in der Hoffnung, daß die Leitungen dafür ausreichend sind und die Bild-Daten, die pro Sitzung übertragen werden nicht immer ein komplettes Bild sonder die sich nur verändernden Pixel überträgt, das testen wir aber noch aus).
Zu unserem Testszenario:
wir haben sowohl den SQL Server mit 32 Bit als auch den mit 64 Bit getestet als dieser im selben Subnetz war (Gigabit Leitung). Der Unterschied war eben nicht wirklich vorhanden, zumindest subjektiv gesehen.
Am DB hängt nichts weiter dran, da läuft nur diese eine Datenbank drauf, und die Terminal-Server schicken Ihre Anfragen an eben diesen.
Gruß Maddin
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?
Ich denke du hast gerade das Problem selbst geschildert, da muss erstmal die Anbindung besser werden, ggf auch die Terminalserver etwas aufbohren. Kein Wunder das ihr da keine Leistungssteigerung zu verzeichnen habt.
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
Zitat von @maretz:
Würdest du ihm den Rechner so zusammenbauen oder lieber auf eine CPU verzichten dafür aber 2 GB (o. mehr) RAM einbauen?
Würdest du ihm den Rechner so zusammenbauen oder lieber auf eine CPU verzichten dafür aber 2 GB (o. mehr) RAM einbauen?
wahrscheinlich letzteres *gg*
Aber erst einmal vielen Dank für die wirklich hilfreichen Hinweise ... ich werd mit ihm zusammen mal Deinen Post durchgehen und er soll tatsächlich mal eine solche Analyse für die DB fahren ... ich geb gern bescheid, sobald wir etwas raus haben und was für Werte wir ermittelt haben ...
Was die Freigabe für den neuen SQL Server anbetrifft, so haben wir hier grünes Licht. Zumindest MS-SQL 2008 ist freigegeben, wie es mit 2010 aussieht kann ich nicht sagen, allerdings haben wir dafür auch noch keine Lizenz um das Testen zu können.
Was das Netzwerk anbetrifft hab ich schon dafür gesorgt, daß hier überall nur noch 1000 NICs verbaut sind, auch in den Servern sind die Teile schon drin. Wie es tatsächlich mit der Netzwerklast aussieht sollte vielleicht tatsächlich erst einmal überprüft werden. Aber wie schon gesagt ... ich werd ihm mal ein paar Stichpunkte als Aufgaben geben, damit er mir mal ein paar Daten geben kann, wo denn genau jetzt der Flaschenhals ist.
Dennoch vielen Dank
Gruß Maddin
