Benötige Hardware Empfehlung für Datenbankserver
Hallo zusammen,
für unseren erst kürzlich gekauften Datenbankserver benötigen einen deutlich schnelleren Ersatz.
Warum?
Die Erfahrung hat gezeigt das der Rechner welcher folgende Hardwarekonfiguration hat:
Prozessor : Ein Intel Xeon W3520(2,66GHz,4,8GT/s,8MB)-Speicher läuft mit 1066MHz
Arbeitsspeicher : 6GB(6x1GB)1066MHz DDR3 ECC-UDIMM
Festplatten: 2xSAS 140GB 10000prm auf Raid 0
nicht wirklich schneller die Daten verarbeitet als unser Notebook welches die Hardwarekonfiguration besitzt:
Prozessor : Intel Core 2 Duo T9800(2,93GHz,1066MHz,6MB)
Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel
Festplatte : 250GB (7200 1/min)
Meine Versuche waren bisher sehr ernünchternd.
Die Computer haben sich bei der Verarbeitung der SQL Befehle kaum unterschieden. (2,5 Tage!!!)
Der Einsatz von unterschiedlichen Betriebsystemen XP, Vista, Windows7 (32/64bit) bis Windows Server2003 r2 (32/64bit)
als auch unterschiedliche SQL Server Versionen 2005 (32/64bit) haben zu keiner Leistungssteigerung geführt.
Ganz im Gegenteil: Letztlich war die Verarbeitung mit Windows XP pro am schnellsten !!!???
Also bin ich bei XP mit SQL Server 2005 geblieben.
Verarbeitet wird eine Datenbank mehreren Tabellen die jeweils ca. 10-23GB groß sind.
Zur Zeit gibt es nur 2 Tabellen, es sollen jedoch gegen Ende ca. 10-15 Tabellen in der Größenordnung vorhanden sein.
Die Datenbankinhalte sind ausschließlich Zahlen und Buchstaben.
Habt Ihr vielleicht eine hilfreichende Empfehlung bei der Hardware? Da steckt jetzt schon sehr viel Zeit drin und das Ding will nicht schneller arbeiten.
Das ist wirklich ärgerlich!
Über Antworten würde ich mich sehr freuen.
Gruß SG
für unseren erst kürzlich gekauften Datenbankserver benötigen einen deutlich schnelleren Ersatz.
Warum?
Die Erfahrung hat gezeigt das der Rechner welcher folgende Hardwarekonfiguration hat:
Prozessor : Ein Intel Xeon W3520(2,66GHz,4,8GT/s,8MB)-Speicher läuft mit 1066MHz
Arbeitsspeicher : 6GB(6x1GB)1066MHz DDR3 ECC-UDIMM
Festplatten: 2xSAS 140GB 10000prm auf Raid 0
nicht wirklich schneller die Daten verarbeitet als unser Notebook welches die Hardwarekonfiguration besitzt:
Prozessor : Intel Core 2 Duo T9800(2,93GHz,1066MHz,6MB)
Memory : 4096MB (2x2048) 800MHz DDR2 Dual Channel
Festplatte : 250GB (7200 1/min)
Meine Versuche waren bisher sehr ernünchternd.
Die Computer haben sich bei der Verarbeitung der SQL Befehle kaum unterschieden. (2,5 Tage!!!)
Der Einsatz von unterschiedlichen Betriebsystemen XP, Vista, Windows7 (32/64bit) bis Windows Server2003 r2 (32/64bit)
als auch unterschiedliche SQL Server Versionen 2005 (32/64bit) haben zu keiner Leistungssteigerung geführt.
Ganz im Gegenteil: Letztlich war die Verarbeitung mit Windows XP pro am schnellsten !!!???
Also bin ich bei XP mit SQL Server 2005 geblieben.
Verarbeitet wird eine Datenbank mehreren Tabellen die jeweils ca. 10-23GB groß sind.
Zur Zeit gibt es nur 2 Tabellen, es sollen jedoch gegen Ende ca. 10-15 Tabellen in der Größenordnung vorhanden sein.
Die Datenbankinhalte sind ausschließlich Zahlen und Buchstaben.
Habt Ihr vielleicht eine hilfreichende Empfehlung bei der Hardware? Da steckt jetzt schon sehr viel Zeit drin und das Ding will nicht schneller arbeiten.
Das ist wirklich ärgerlich!
Über Antworten würde ich mich sehr freuen.
Gruß SG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 126831
Url: https://administrator.de/forum/benoetige-hardware-empfehlung-fuer-datenbankserver-126831.html
Ausgedruckt am: 23.12.2024 um 17:12 Uhr
38 Kommentare
Neuester Kommentar
Servus,
grob überschlagen - kommt ein "typischer TiMobeil" Beitrag heraus.
Lösungsansatz, der mit der Überschrift der Frage nicht in einklang zu bringen ist - das Problem jedoch besser lösen kann
Du mußt die Tabellen partitionieren - sonst wird das nix.
Ob nun vertikal oder horizontal, sei dahin gestellt und wäre abhängig davon, ob tatsächlich immer alle Einträge (Spalten) eines Treffers benötigt werden - oder ob es nur ein paar wenige (von vielen Treffern) sind.
Ein Server, der 23 GB hat, wär "schweineteuer" und auch nur solange "schnell" - wie "nur" eine DB/Tabelle drauf läuft.
Gruß
edit yupp - daher (raid 0) kommt wohl auch der "nur" kleine Unterschied - trotz 2 Gig mehr ramses und 2.8k mehr rpm.
grob überschlagen - kommt ein "typischer TiMobeil" Beitrag heraus.
Lösungsansatz, der mit der Überschrift der Frage nicht in einklang zu bringen ist - das Problem jedoch besser lösen kann
Verarbeitet wird eine Datenbank mehreren Tabellen die jeweils ca. 10-23GB groß sind.
Du mußt die Tabellen partitionieren - sonst wird das nix.
Ob nun vertikal oder horizontal, sei dahin gestellt und wäre abhängig davon, ob tatsächlich immer alle Einträge (Spalten) eines Treffers benötigt werden - oder ob es nur ein paar wenige (von vielen Treffern) sind.
Ein Server, der 23 GB hat, wär "schweineteuer" und auch nur solange "schnell" - wie "nur" eine DB/Tabelle drauf läuft.
Gruß
edit yupp - daher (raid 0) kommt wohl auch der "nur" kleine Unterschied - trotz 2 Gig mehr ramses und 2.8k mehr rpm.
Hi !
"Sie wissen nichts und ich weiss auch nichts! Herr Lüg!"
(Herbert Wehner SPD-Fraktionsvorsitzender in einem Interview mit Ernst Dieter Lueg)
Will sagen: Von hier aus gesehen, weiss ich nix! Mit den paar Angaben ist eine Hilfe nicht möglich! Die schlechte Gesamtperformance der Anlage könnte auch an schlampigen Abfragen oder am Netzwerk liegen. Da gibt es zig Gründe für, es muss nicht an der Serverhardware liegen. Eine Hilfe, basieren auf den Aussagen von jemanden der einen Server mit RAID 0 betreibt, ist nicht wirklich möglich...Sorry!
Wäre nicht Formatieren der bessere Ausdruck? :-P
mrtux
"Sie wissen nichts und ich weiss auch nichts! Herr Lüg!"
(Herbert Wehner SPD-Fraktionsvorsitzender in einem Interview mit Ernst Dieter Lueg)
Will sagen: Von hier aus gesehen, weiss ich nix! Mit den paar Angaben ist eine Hilfe nicht möglich! Die schlechte Gesamtperformance der Anlage könnte auch an schlampigen Abfragen oder am Netzwerk liegen. Da gibt es zig Gründe für, es muss nicht an der Serverhardware liegen. Eine Hilfe, basieren auf den Aussagen von jemanden der einen Server mit RAID 0 betreibt, ist nicht wirklich möglich...Sorry!
Zitat von @60730:
Du mußt die Tabellen partitionieren - sonst wird das nix.
Du mußt die Tabellen partitionieren - sonst wird das nix.
Wäre nicht Formatieren der bessere Ausdruck? :-P
mrtux
Was ist am Raid 0 nur so falsch? Es geht nur um die Verarbeitung, die
Datensicherheit ist überhaupt nicht relevant und kann komplett
außer Acht gelassen werden.
Datensicherheit ist überhaupt nicht relevant und kann komplett
außer Acht gelassen werden.
... die Frage an sich kann außer acht gelassen werden. Man sollte wirklich Ahnung haben, wenn man sich solch eine Aufgabe aufhalst.
Gruß, Arch Stanton
Hab ich ja "versucht"
Der da?
Performance-Messungen unter Einsatz eines echten First Person Shooters für DirectX 9.0c. Das Spiel basiert auf der Refractor 2 Engine
Tabellengröße >= Ram == lahme DB
Tabellengröße >= Ram == nix lahme DB
schnelle Platten = nix lahme DB
lahme Platten = lahme DB
Xp= wenig Dienste (std.)
W2k^^3^=Xp= viele Dienste (std.)
hab ich versucht, aber es ist in der Tat ein komplexes Thema...
Entweder die Server teilen (Clustern) - oder die Tabellen - oder damit "leben" - oder Rechenpower mieten z.B Amazon S3 (obwohl, bis 23 GB über die Leitung geflogen sind...)
Die Tabellen partitionieren im SQL Server 2005? Wie geht das?
in kleine Häppchen "teilen" - hätt ich ja auch schreiben können.Raid 0 wurde deswegen gewählt, weil hier die Verarbeitung am schnellsten ist.
Aus dem Fenster würd ich mich nicht legen..Der da?
Performance-Messungen unter Einsatz eines echten First Person Shooters für DirectX 9.0c. Das Spiel basiert auf der Refractor 2 Engine
Frage: Wenn ich nur eine Tabelle verarbeiten würde und ein 24GB
großer Arbeisspeicher eingebaut wäre, würde die Verarbeitung nur im Arbeitsspeicher erfolgen?
kommt auf einen Versuch an...Oder anders, schnippel an einer kopie einer Tabelle mal 6 GB (den Ram des vorhandenen Systems) raus und lass die DB laufen...großer Arbeisspeicher eingebaut wäre, würde die Verarbeitung nur im Arbeitsspeicher erfolgen?
Den Text habe ich leider nicht verstanden:
edit yupp - daher (raid 0) kommt wohl auch der "nur" kleine Unterschied - trotz 2 Gig mehr ramses und 2.8k mehr rpm.
edit yupp - daher (raid 0) kommt wohl auch der "nur" kleine Unterschied - trotz 2 Gig mehr ramses und 2.8k mehr rpm.
Tabellengröße >= Ram == lahme DB
Tabellengröße >= Ram == nix lahme DB
schnelle Platten = nix lahme DB
lahme Platten = lahme DB
Xp= wenig Dienste (std.)
W2k^^3^=Xp= viele Dienste (std.)
Bitte um kurze Antwort.
Danke
Danke
hab ich versucht, aber es ist in der Tat ein komplexes Thema...
Entweder die Server teilen (Clustern) - oder die Tabellen - oder damit "leben" - oder Rechenpower mieten z.B Amazon S3 (obwohl, bis 23 GB über die Leitung geflogen sind...)
Ich das dein Ernst? Sehr witzig!
ääh ja das war mein Ernst und nein "witzig" war ich eben woanders.
Ich hab in der Tat des öfteren schon mal eine Platte in einem Päckchen nach S3 geschickt, dort einlesen lassen und 2 Monate Server benutzt, die wir solange "aufgestockt" haben, bis wir die richtige hausnummer für unseren DB Cluster gefunden hatten.
Von daher denke ich du meintest diese Zeile und nicht die mit dem teilen.
.. der meinte das man das Betriebssystem auf eine Separate Partition schieben kann
Kann ja - bringt nix.OS= eigene Platte - so machts sinn. (Aber das ist feinpolitur im Mü Bereich)
Eine auf einen Schlag alleslösende Hardware wäre schön. "teuer"
Gruß
Hi,
also Raid0 eine Platte weg alles weg. z.B. Raid 5 eine Platte weg neue rein wenn Hotswap sogar im Betrieb und fertig. Spareplatten übernehmen das Automatisch. Wer ein Raid 0 an einem scharfen Server Einrichtet sollte Maurer werden.
Und du hast den Plattenplatz selbst bei Raid 0 ganz schön Geizig Ausgelegt 15 Tabellen mit je 23GB macht 345GB + sagen wir mal 25GB OS macht 370GB und du hast nur 280GB im Raid 0 Zur Verfügung.
also Raid0 eine Platte weg alles weg. z.B. Raid 5 eine Platte weg neue rein wenn Hotswap sogar im Betrieb und fertig. Spareplatten übernehmen das Automatisch. Wer ein Raid 0 an einem scharfen Server Einrichtet sollte Maurer werden.
Und du hast den Plattenplatz selbst bei Raid 0 ganz schön Geizig Ausgelegt 15 Tabellen mit je 23GB macht 345GB + sagen wir mal 25GB OS macht 370GB und du hast nur 280GB im Raid 0 Zur Verfügung.
Hallo,
mensch Leute. Der "Schaschlik" hat vorhin ganz klar geschrieben, dass der RAID-Sicherheitsfaktor ausser Acht gelassen werden kann. Somit benötigt er, denke ich, keine Aufklärung darüber welches RAID in welcher Form ausfallsicher ist.
Ihm steht nur die Performance im Vordergrund. Vermutlich sind es alles nur (Testdatenbankabbilder von Kunden) ...
Aber wie auch schon gesagt wurde, sind diese Performancethemen immer schon eine schwierige Sache gewesen. Meist lässt sich das auch nicht mit mehr CPU und mehr RAM in den Griff bekommen.
Wird beachtet, dass wenn wie oben beschrieben Windows Server-Betriebssysteme mit 3 2Bit zum Einsatz kommen, dass max 4GB Ram adressierbar sind? Hinzu kommt, dass der Schalter "/3GB" in der boot.ini zu setzen ist. - Wird bei einem eingesetzten 64 Bit System auch der SQL Server 2005 für 64 Bit genutzt?
Wenn man allerdings auf der Stelle "tanzt", dann würde eine Performance-Analyse durch einen externen Dienstleister ggf. noch Sinn machen. Oft sind Softwarekonfigurationen der Grund die Abfragezeiten ins unermässliche Ansteigen lassen.
Hab hier mal von folgender Firma gehört. Analyse kann vor Ort erfolgen oder man hängt eine Box ins Netz, die alles mitprotokolliert. Die Firma analysiert die Daten und gibt Informationen darüber, was wie zu ändern ist.
Deren dafür genutzte Software ist kostenlose, es wird lediglich die Dienstleistung verkauft.
Ne Anfrage kann sicher nicht schaden, immer noch besser als ständig "auf gut Glück" neue Hardware zu kaufen und/oder sich wochenlang die Zähne auszubeissen...
http://www.puw-netzwerk.de/de/net_analysis/
Gruß
SoloTalent
mensch Leute. Der "Schaschlik" hat vorhin ganz klar geschrieben, dass der RAID-Sicherheitsfaktor ausser Acht gelassen werden kann. Somit benötigt er, denke ich, keine Aufklärung darüber welches RAID in welcher Form ausfallsicher ist.
Ihm steht nur die Performance im Vordergrund. Vermutlich sind es alles nur (Testdatenbankabbilder von Kunden) ...
Aber wie auch schon gesagt wurde, sind diese Performancethemen immer schon eine schwierige Sache gewesen. Meist lässt sich das auch nicht mit mehr CPU und mehr RAM in den Griff bekommen.
Wird beachtet, dass wenn wie oben beschrieben Windows Server-Betriebssysteme mit 3 2Bit zum Einsatz kommen, dass max 4GB Ram adressierbar sind? Hinzu kommt, dass der Schalter "/3GB" in der boot.ini zu setzen ist. - Wird bei einem eingesetzten 64 Bit System auch der SQL Server 2005 für 64 Bit genutzt?
Wenn man allerdings auf der Stelle "tanzt", dann würde eine Performance-Analyse durch einen externen Dienstleister ggf. noch Sinn machen. Oft sind Softwarekonfigurationen der Grund die Abfragezeiten ins unermässliche Ansteigen lassen.
Hab hier mal von folgender Firma gehört. Analyse kann vor Ort erfolgen oder man hängt eine Box ins Netz, die alles mitprotokolliert. Die Firma analysiert die Daten und gibt Informationen darüber, was wie zu ändern ist.
Deren dafür genutzte Software ist kostenlose, es wird lediglich die Dienstleistung verkauft.
Ne Anfrage kann sicher nicht schaden, immer noch besser als ständig "auf gut Glück" neue Hardware zu kaufen und/oder sich wochenlang die Zähne auszubeissen...
http://www.puw-netzwerk.de/de/net_analysis/
Gruß
SoloTalent
Moin,
ok, ich hab das hier jetzt mal nicht alles durchgelesen - frage mich aber langsam ob mittlerweile jeder der weiss wie Windows geschrieben wird an Datenbanken ran darf...
Fangen wir mal mit dem Raid0 an (ja, ich habe gelesen das hier nur auf performance geachtet wird): Trotzdem Bullshit! Lass das Ding mal absemmeln und prüfe nach wie lange du für ein restore brauchst. Soviel zum Thema Performance - soviel Zeit kannst du gar nicht rausholen! Hier wäre dann nen raid 5 schon deutlich besser... Ganz davon abgesehen ist es bei einer DB zimlich unsinnig einen RAID zu wählen der für schnellen Datentransfer optimiert ist. Was meinst du - wie oft liest du bei einer DB wirklich eine 200 MB-Datei komplett ein? Bei deinem Raid muss aber das System auch wenn du nur 2 kB einliest beide Festplatten an die richtige Stelle bringen -> um dann von einer Festplatte die ganzen 2 kB zu lesen... Und wenn dir Sicherheit wirklich so am Ar... vorbei geht dann würde ich hier auf eine Solid-State-Disk setzen -> die hat keine lange Seek-Time und dürfte da noch am meisten bringen.
Dann zur Datenstruktur: Du kannst hier nur versuchen alles soweit wie möglich auf Zahlen umzubiegen. Ich weiss ja nicht was du für SQL-Statements aufbaust die so 1,5 Tage o. länger benötigen - aber das sieht mir sehr nach Vergleichs-Statements aus. Und ein Vergleich zweier Integer-Werte geht um ein vielfaches länger als ein Vergleich zweier Textwerte (d.h. 1=1 ist DEUTLICH schneller als "A=A"). Je nachdem was du genau machst lohnt es sich auch oftmals die Werte vorher in eine Temp. Tbl. zu packen die nur im Speicher existiert. Zugriffszeit auf den RAM ist normal so um den Faktor 1000 schneller als auf deine Festplatte (egal welches Raid-System du nutzt).
Je nachdem ob du zwingend mit MS-SQL arbeiten musst kannst du auch versuchen unter Linux mit MySQL zu arbeiten. XP ist jedoch in keinem Fall ein akzeptables System für eine Datenbank (hier benötigst du ein System was zwingend eine gute Speicherverwaltung mitbringt...). Ganz davon abgesehen das dir ein 32-Bit-Betriebssystem wenig hilft wenn du mehr als ca. 3,5 GB RAM nutzt...
Und zum schluss: Normal macht man sich VOR dem Kauf von Hardware schlau welche Dinge man benötigt (ob dort THG nun die beste quelle ist möchte ich mal absichtlich dahingestellt sein lassen!). Und grade bei Datenbanken muss man auf einiges an Rand-Parametern achten - dir werden die 12 / 24 GB RAM nichts bringen wenn das Layout der Datenbank "für'n moars" ist.
Gruß
Mike
ok, ich hab das hier jetzt mal nicht alles durchgelesen - frage mich aber langsam ob mittlerweile jeder der weiss wie Windows geschrieben wird an Datenbanken ran darf...
Fangen wir mal mit dem Raid0 an (ja, ich habe gelesen das hier nur auf performance geachtet wird): Trotzdem Bullshit! Lass das Ding mal absemmeln und prüfe nach wie lange du für ein restore brauchst. Soviel zum Thema Performance - soviel Zeit kannst du gar nicht rausholen! Hier wäre dann nen raid 5 schon deutlich besser... Ganz davon abgesehen ist es bei einer DB zimlich unsinnig einen RAID zu wählen der für schnellen Datentransfer optimiert ist. Was meinst du - wie oft liest du bei einer DB wirklich eine 200 MB-Datei komplett ein? Bei deinem Raid muss aber das System auch wenn du nur 2 kB einliest beide Festplatten an die richtige Stelle bringen -> um dann von einer Festplatte die ganzen 2 kB zu lesen... Und wenn dir Sicherheit wirklich so am Ar... vorbei geht dann würde ich hier auf eine Solid-State-Disk setzen -> die hat keine lange Seek-Time und dürfte da noch am meisten bringen.
Dann zur Datenstruktur: Du kannst hier nur versuchen alles soweit wie möglich auf Zahlen umzubiegen. Ich weiss ja nicht was du für SQL-Statements aufbaust die so 1,5 Tage o. länger benötigen - aber das sieht mir sehr nach Vergleichs-Statements aus. Und ein Vergleich zweier Integer-Werte geht um ein vielfaches länger als ein Vergleich zweier Textwerte (d.h. 1=1 ist DEUTLICH schneller als "A=A"). Je nachdem was du genau machst lohnt es sich auch oftmals die Werte vorher in eine Temp. Tbl. zu packen die nur im Speicher existiert. Zugriffszeit auf den RAM ist normal so um den Faktor 1000 schneller als auf deine Festplatte (egal welches Raid-System du nutzt).
Je nachdem ob du zwingend mit MS-SQL arbeiten musst kannst du auch versuchen unter Linux mit MySQL zu arbeiten. XP ist jedoch in keinem Fall ein akzeptables System für eine Datenbank (hier benötigst du ein System was zwingend eine gute Speicherverwaltung mitbringt...). Ganz davon abgesehen das dir ein 32-Bit-Betriebssystem wenig hilft wenn du mehr als ca. 3,5 GB RAM nutzt...
Und zum schluss: Normal macht man sich VOR dem Kauf von Hardware schlau welche Dinge man benötigt (ob dort THG nun die beste quelle ist möchte ich mal absichtlich dahingestellt sein lassen!). Und grade bei Datenbanken muss man auf einiges an Rand-Parametern achten - dir werden die 12 / 24 GB RAM nichts bringen wenn das Layout der Datenbank "für'n moars" ist.
Gruß
Mike
Moin Schaschlik,
keine Sorge - von mir wirst du keine Hardware-Empfehlungen befürchten müssen - da bin ich absoluter Laie.
Aber, wenn du momentan auf dem Trip bist, du könntest Tuning und Optimierung mit Tipps aus Tankstellen-PC-Zeitschriften erreichen
Hey, das kann doch wohl nicht ernst gemeint sein, oder?
Ich will nicht zu Straftaten aufrufen, aber es soll schon bei uns in Bremen schon Spezialisten gegeben haben, die samt Firmenwagen in einer Weserbiegung verscharrt wurden..
Selbst wenn die Abfragen schlecht wären müssten Sie bei einer performanteren Hardware schneller laufen, oder irre ich mich?
--> DB-Tuning setzt immer an der DB an... Hardware kann so oder so nur max 15% rausholen bei "normalen" Technologiesprüngen.
Wechselt die DB-Spezialisten und nicht die Rechner aus.
Im Zweifelsfall: Auch mich kann man/frau mieten. Bin billiger als 'ne Cray...
Grüße
Biber
keine Sorge - von mir wirst du keine Hardware-Empfehlungen befürchten müssen - da bin ich absoluter Laie.
Aber, wenn du momentan auf dem Trip bist, du könntest Tuning und Optimierung mit Tipps aus Tankstellen-PC-Zeitschriften erreichen
..Gibt es einen Forumsbeitrag welcher das deaktivieren unnötiger Dienste behandelt?
Hey, das kann doch wohl nicht ernst gemeint sein, oder?
Ich will mich ja nicht zu einem Spezialisten küren, aber es wurden für die Abfragen Spezialisten eingesetzt.
Wie? Und diese Spezialisten haben dann gesagt:"Sorry, das ist vollkommen normal, dass die Abfrage 2,5 Tage lang rennt.
Aber die Hardware wird ja auch immer schneller -kauf euch mal ein dickeres Blech im Media-Markt..."
Aber die Hardware wird ja auch immer schneller -kauf euch mal ein dickeres Blech im Media-Markt..."
Ich will nicht zu Straftaten aufrufen, aber es soll schon bei uns in Bremen schon Spezialisten gegeben haben, die samt Firmenwagen in einer Weserbiegung verscharrt wurden..
Selbst wenn die Abfragen schlecht wären müssten Sie bei einer performanteren Hardware schneller laufen, oder irre ich mich?
--> DB-Tuning setzt immer an der DB an... Hardware kann so oder so nur max 15% rausholen bei "normalen" Technologiesprüngen.
Wechselt die DB-Spezialisten und nicht die Rechner aus.
Im Zweifelsfall: Auch mich kann man/frau mieten. Bin billiger als 'ne Cray...
Grüße
Biber
Moin,
ich mach jetzt mal den Teebeutel und häng mich hier rein
ein Client-OS wie XP macht erst mal die graphische Ausgabe chic - schiebt also diese Prozesse in den Vordergrund
ein Server-OS pusht Hintergrundprozesse, wie DBs und IIS etc.
egal was Du glaubst zu wissen, wenn ich ein System aufsetze, wo eine DB-Abfrage *länger* dauert, hat sich schon mal das RAID-0 erledigt, immer dran denken, 5 min vor Ende der Abfrage kackt die Platte ab.... - Murphys - Gesetz ....
ansonsten gelten die hier genannten Vorschläge - Trennung OS / Applikation und Daten, Partionierung der beteiligten DBs, halt das vernünftige Design ...
Gruß
24
ich mach jetzt mal den Teebeutel und häng mich hier rein
ein Client-OS wie XP macht erst mal die graphische Ausgabe chic - schiebt also diese Prozesse in den Vordergrund
ein Server-OS pusht Hintergrundprozesse, wie DBs und IIS etc.
egal was Du glaubst zu wissen, wenn ich ein System aufsetze, wo eine DB-Abfrage *länger* dauert, hat sich schon mal das RAID-0 erledigt, immer dran denken, 5 min vor Ende der Abfrage kackt die Platte ab.... - Murphys - Gesetz ....
ansonsten gelten die hier genannten Vorschläge - Trennung OS / Applikation und Daten, Partionierung der beteiligten DBs, halt das vernünftige Design ...
Gruß
24
Moin,
würde mich mal intressieren was das für eine Datenbank ist. Denn: Eine Datenbank nutze ich immer dann wenn ich immer aktuelle Daten benötige - und da ist es nicht unbedingt unkritisch wenn mir die des Nachts mal abraucht... Aber gut - es ist deine Datenbank, soll mir egal sein. Das dir der Raid 0 in diesem Falle nichts bringen wird habe ich oben ja auch unabhängig von der Sicherheit noch beschrieben...
Du wirst keine 64-Bit-Applikation auf einem 32-Bit OS zum laufen bekommen. DIes hat stark mit den System-Aufrufen usw. zu tun (u. a. damit das die Anwendung eigentlich immer nur eine abstrakte Hardware sieht usw...). Dies kannst du mir glauben - oder dich über Betriebssysteme informieren. Mein Tipp: Andrew S. Tanenbaum - Moderne Betriebssysteme... (ggf. auch noch H&P - Computer Architecture).
Stimmt, stellt man die Frage nach der besten Datenbank in ein Forum bekommt man 10 Antworten. Frage mal nach dem besten Betriebssystem - danach schnapp dir nen Stahlhelm & nen Schützengraben und genieße die Show... (Wahlweise geh in nen Autoforum und frage ob nen GTI besser als nen BMW u.ä. ist...). Fakt ist: Die BESTE Datenbank hängt davon ab was du genau machen willst und wie gut deine Kenntnisse sind. So würde ich mir z.B. eher keine Oracle-DB installieren - da meine Kenntnisse damit recht gering sind. Gib mir nen MS-SQL oder (noch lieber) MySQL und ich bin glücklich...
Ich weiss nicht was du vor dem Kauf der Hardware gemacht hast. ABER: Wenn ich mir einen Datenbank-Server kaufe (und die sind meist nicht ganz günstig) dann rede ich vorher mit dem Verkäufer und gebe dem ne Übersicht über mein Vorhaben und über die Daten. Dazu bekommt der von mir ne Vorgabe wie "Die Hardware muss in der Lage sein die Statements in x Std abzuarbeiten". Stellt der mir dann was hin und das braucht nicht 5 Stunden sondern 2 Tage - Rückgabe und nen ernsthaftes Gespräch (der Vertriebsmensch könnte dann auch in der vom Biber genannten Weserkurve liegen... aber nicht zu dicht beim Stadion, sonst riechts bei Ebbe so streng!). Aber ok, wenn du deine Infos dir von THG ziehst (welche ja auch auf Datenbank-Server extrem spezialisiert sind - deshalb ja auch die guten Benchmarks...) dann musst du mit dem Resultat leben.
Ich möchte mal ganz offen sein: ENTWEDER du hast nen absolut bescheidenes Systemhaus und solltest das schnell wechseln ODER du hast gemeint das du dir keine Empfehlungen einholst bzw. diese ignorierst. KEIN Mensch mit etwas ahnung würde dir für einen derartigen DB-Server schon allein Platten mit 10.000 U/Min geben - hier wären 15.000 schon pflicht. Dazu würde man dir einen guten Controller mit extra Cache besorgen und einbauen.
Jetzt bleibt dir eigentlich nur eines: Deinen Spezialisten fragen ob man das Problem nicht durch aufsplitten der Tabellen lösen kann - bzw. bei vorherberechneten Ergebnissen (z.B. Statistiken) dafür zu sorgen das nicht jeden Tag bei 0 angefangen wird sondern zwischenstände mit übernommen werden. (D.h. du würdest praktisch nur nen DIFF jeden Tag neu rechnen lassen). Oder du kaufst dir jetzt die neue superschöne-tolle-teure-hardware und bügelst alle 6-12 Monate da wieder richtig geld in den Server rein... Ebenfalls würde ich mit dem Spezialisten nochmal über das gesamte DB Design reden - und gucken was man da so machen kann...
Eine Frage noch am Rande: Wenn du die Querys von einem Spezialisten hast optimieren lassen - was hat er denn zu deiner Hardware gesagt? Eigentlich hätte dem auch schon einiges auffallen müssen...
würde mich mal intressieren was das für eine Datenbank ist. Denn: Eine Datenbank nutze ich immer dann wenn ich immer aktuelle Daten benötige - und da ist es nicht unbedingt unkritisch wenn mir die des Nachts mal abraucht... Aber gut - es ist deine Datenbank, soll mir egal sein. Das dir der Raid 0 in diesem Falle nichts bringen wird habe ich oben ja auch unabhängig von der Sicherheit noch beschrieben...
Du wirst keine 64-Bit-Applikation auf einem 32-Bit OS zum laufen bekommen. DIes hat stark mit den System-Aufrufen usw. zu tun (u. a. damit das die Anwendung eigentlich immer nur eine abstrakte Hardware sieht usw...). Dies kannst du mir glauben - oder dich über Betriebssysteme informieren. Mein Tipp: Andrew S. Tanenbaum - Moderne Betriebssysteme... (ggf. auch noch H&P - Computer Architecture).
Stimmt, stellt man die Frage nach der besten Datenbank in ein Forum bekommt man 10 Antworten. Frage mal nach dem besten Betriebssystem - danach schnapp dir nen Stahlhelm & nen Schützengraben und genieße die Show... (Wahlweise geh in nen Autoforum und frage ob nen GTI besser als nen BMW u.ä. ist...). Fakt ist: Die BESTE Datenbank hängt davon ab was du genau machen willst und wie gut deine Kenntnisse sind. So würde ich mir z.B. eher keine Oracle-DB installieren - da meine Kenntnisse damit recht gering sind. Gib mir nen MS-SQL oder (noch lieber) MySQL und ich bin glücklich...
Ich weiss nicht was du vor dem Kauf der Hardware gemacht hast. ABER: Wenn ich mir einen Datenbank-Server kaufe (und die sind meist nicht ganz günstig) dann rede ich vorher mit dem Verkäufer und gebe dem ne Übersicht über mein Vorhaben und über die Daten. Dazu bekommt der von mir ne Vorgabe wie "Die Hardware muss in der Lage sein die Statements in x Std abzuarbeiten". Stellt der mir dann was hin und das braucht nicht 5 Stunden sondern 2 Tage - Rückgabe und nen ernsthaftes Gespräch (der Vertriebsmensch könnte dann auch in der vom Biber genannten Weserkurve liegen... aber nicht zu dicht beim Stadion, sonst riechts bei Ebbe so streng!). Aber ok, wenn du deine Infos dir von THG ziehst (welche ja auch auf Datenbank-Server extrem spezialisiert sind - deshalb ja auch die guten Benchmarks...) dann musst du mit dem Resultat leben.
Ich möchte mal ganz offen sein: ENTWEDER du hast nen absolut bescheidenes Systemhaus und solltest das schnell wechseln ODER du hast gemeint das du dir keine Empfehlungen einholst bzw. diese ignorierst. KEIN Mensch mit etwas ahnung würde dir für einen derartigen DB-Server schon allein Platten mit 10.000 U/Min geben - hier wären 15.000 schon pflicht. Dazu würde man dir einen guten Controller mit extra Cache besorgen und einbauen.
Jetzt bleibt dir eigentlich nur eines: Deinen Spezialisten fragen ob man das Problem nicht durch aufsplitten der Tabellen lösen kann - bzw. bei vorherberechneten Ergebnissen (z.B. Statistiken) dafür zu sorgen das nicht jeden Tag bei 0 angefangen wird sondern zwischenstände mit übernommen werden. (D.h. du würdest praktisch nur nen DIFF jeden Tag neu rechnen lassen). Oder du kaufst dir jetzt die neue superschöne-tolle-teure-hardware und bügelst alle 6-12 Monate da wieder richtig geld in den Server rein... Ebenfalls würde ich mit dem Spezialisten nochmal über das gesamte DB Design reden - und gucken was man da so machen kann...
Eine Frage noch am Rande: Wenn du die Querys von einem Spezialisten hast optimieren lassen - was hat er denn zu deiner Hardware gesagt? Eigentlich hätte dem auch schon einiges auffallen müssen...
Moin,
eine quelle für Hardware bei Datenbankservern wirst du nicht so einfach finden. Es ist leider nicht so einfach wie bei "Spiele-PCs" -> man nehme nen grafik-lastigen Benchmark, prügel den da durch und schaue sich das Ergebnis an (und wenn wir von treiberoptimierungen usw. mal absehen und davon ausgehen das auch sonst nichts am PC läuft dann hat man zumindest ein grobes Ergebnis). Bei einer Datenbank gibt es ganz andere Messgrößen - die sich nicht ohne weiteres auf jedes beliebige System übertragen lassen:
- Anzahl der gleichzeitigen Zugriffe (ok, könnte man mit nem Stress-Simulator noch hinbekommen).
- Anzahl & größe der Tabellen -> und die darauf erstellten Abfragen. Ich habe z.B. wegen eines Problemes 2 praktisch identische Tabellen. Bei einer kann ich die Werte auf einen ganzzahl-Wert (integer) basieren lassen - bei der anderen geht das nicht da hier ne Art Artikelbezeichnung die einzige überschneidung ist. Führe ich eine identische SQL-Abfrage auf beiden Tabellen aus ist die mit dem Zahlenvergleich nach ca. 15-20 Min durch. Die mit der Artikelbezeichnung genehmigt sich hier locker mal 2-3 STUNDEN! Dieses Problem ist unabhängig von deiner Datenbank (ob MS-SQL, Posgres, MySQL, Oracle,...). Das liegt einfach daran das ich 2 ganzzahl Werte in einem Takt überprüfen kann (cjne -> compare and jump if not equal falls du den ASM-Befehl in der x86-er Welt möchtest)). Ist ganz einfach: wenn (5-5=0) -> überschneidung. wenn (5-5!=0) -> keine überschneidung. Bei Textwerten geht das nicht -> da z.B. A != a und z.B. DiesIstEinSehrLangerText erstmal umgewandelt und dann zeichen für Zeichen verglichen werden muss.
- Verarbeitungsgeschwindigkeit der Hardware (es bringt dir nichts wenn du nen super-schnellen Prozessor hast - aber die Festplatte ne Seek-Time von 50 ms...)
- Ablageort der Tabellen (z.B. liegen die Tabellen im RAM ist das System deutlich schneller)
- Möglichkeit der Cache-Optimierung
- uvm.
JEDER dieser Parameter kann deine Hardware ganz anders auslasten (wenn du z.B. nur riesige Sortierfunktionen hast dann bringt dir keine 10GBit-NIC was... Hast du aber dagegen 10.000 gleichzeitige Verbindung wäre ne 10 MBit-BNC-Karte ggf. etwas schlecht...). Und aus diesem Grund wirst du keinen (aussagekräftigen) Benchmark finden. Leider ist das Thema DB-Administration nicht ganz so einfach (guck doch mal im heise Gehaltscheck nach was nen 08/15-Sys-Admin verdient - und wo der DB-Admin liegt...). Und hier gibt es nunmal das Problem das man in nen Server für nen DBMS unheimlich viel Geld reinstecken kann - und trotzdem ne Krücke hat (was ja praktisch bei dir passiert ist). Oder du stopfst da RICHTIG viel Geld rein (hier reden wir über 5-6-stellige Summen!) - dann hast du ne Kiste die auch universell nutzbar sein sollte. Aber ich glaube in dem Bereich werden die meisten Leute eher nicht gehen (und nen seriöser Verkäufer wird dir eine solche Kiste auch nicht verkaufen ohne vorher mit dir über die DB selbst gesprochen zu haben!).
Von daher ist auch deine Annahme falsch - das zwischen DB-Spezialisten und Hardware-Spezialisten ein riesiges Loch klaffen muss. Ich glaube das ich in beiden Bereichen schon gut mithalten kann (ok, bei Hardware kann ich dir sicher nicht sagen welche GraKa heute die beste Grafik-Leistung bringt oder ob nun NVidea besser ist als irgendwer anders...). Ich kann aber durchaus wenn ich ne DB sehe schon mit einigen Tools rausfinden wo eine Schwachstelle ist bzw. was man da sinnvollerweise dran dreht (wobei man auch da nicht nur die DB selbst anguckt sondern auch noch das gesamte OS dazu...). Das Problem ist nur: Wenn ich jemanden sage was ich dafür im Monat mindestens kosten würde dann wird jeder der nicht grad nen mittelstands- oder großbetrieb führt vermutlich umfallen... Also probieren es die Leute dann so - ok, HF & GL...
eine quelle für Hardware bei Datenbankservern wirst du nicht so einfach finden. Es ist leider nicht so einfach wie bei "Spiele-PCs" -> man nehme nen grafik-lastigen Benchmark, prügel den da durch und schaue sich das Ergebnis an (und wenn wir von treiberoptimierungen usw. mal absehen und davon ausgehen das auch sonst nichts am PC läuft dann hat man zumindest ein grobes Ergebnis). Bei einer Datenbank gibt es ganz andere Messgrößen - die sich nicht ohne weiteres auf jedes beliebige System übertragen lassen:
- Anzahl der gleichzeitigen Zugriffe (ok, könnte man mit nem Stress-Simulator noch hinbekommen).
- Anzahl & größe der Tabellen -> und die darauf erstellten Abfragen. Ich habe z.B. wegen eines Problemes 2 praktisch identische Tabellen. Bei einer kann ich die Werte auf einen ganzzahl-Wert (integer) basieren lassen - bei der anderen geht das nicht da hier ne Art Artikelbezeichnung die einzige überschneidung ist. Führe ich eine identische SQL-Abfrage auf beiden Tabellen aus ist die mit dem Zahlenvergleich nach ca. 15-20 Min durch. Die mit der Artikelbezeichnung genehmigt sich hier locker mal 2-3 STUNDEN! Dieses Problem ist unabhängig von deiner Datenbank (ob MS-SQL, Posgres, MySQL, Oracle,...). Das liegt einfach daran das ich 2 ganzzahl Werte in einem Takt überprüfen kann (cjne -> compare and jump if not equal falls du den ASM-Befehl in der x86-er Welt möchtest)). Ist ganz einfach: wenn (5-5=0) -> überschneidung. wenn (5-5!=0) -> keine überschneidung. Bei Textwerten geht das nicht -> da z.B. A != a und z.B. DiesIstEinSehrLangerText erstmal umgewandelt und dann zeichen für Zeichen verglichen werden muss.
- Verarbeitungsgeschwindigkeit der Hardware (es bringt dir nichts wenn du nen super-schnellen Prozessor hast - aber die Festplatte ne Seek-Time von 50 ms...)
- Ablageort der Tabellen (z.B. liegen die Tabellen im RAM ist das System deutlich schneller)
- Möglichkeit der Cache-Optimierung
- uvm.
JEDER dieser Parameter kann deine Hardware ganz anders auslasten (wenn du z.B. nur riesige Sortierfunktionen hast dann bringt dir keine 10GBit-NIC was... Hast du aber dagegen 10.000 gleichzeitige Verbindung wäre ne 10 MBit-BNC-Karte ggf. etwas schlecht...). Und aus diesem Grund wirst du keinen (aussagekräftigen) Benchmark finden. Leider ist das Thema DB-Administration nicht ganz so einfach (guck doch mal im heise Gehaltscheck nach was nen 08/15-Sys-Admin verdient - und wo der DB-Admin liegt...). Und hier gibt es nunmal das Problem das man in nen Server für nen DBMS unheimlich viel Geld reinstecken kann - und trotzdem ne Krücke hat (was ja praktisch bei dir passiert ist). Oder du stopfst da RICHTIG viel Geld rein (hier reden wir über 5-6-stellige Summen!) - dann hast du ne Kiste die auch universell nutzbar sein sollte. Aber ich glaube in dem Bereich werden die meisten Leute eher nicht gehen (und nen seriöser Verkäufer wird dir eine solche Kiste auch nicht verkaufen ohne vorher mit dir über die DB selbst gesprochen zu haben!).
Von daher ist auch deine Annahme falsch - das zwischen DB-Spezialisten und Hardware-Spezialisten ein riesiges Loch klaffen muss. Ich glaube das ich in beiden Bereichen schon gut mithalten kann (ok, bei Hardware kann ich dir sicher nicht sagen welche GraKa heute die beste Grafik-Leistung bringt oder ob nun NVidea besser ist als irgendwer anders...). Ich kann aber durchaus wenn ich ne DB sehe schon mit einigen Tools rausfinden wo eine Schwachstelle ist bzw. was man da sinnvollerweise dran dreht (wobei man auch da nicht nur die DB selbst anguckt sondern auch noch das gesamte OS dazu...). Das Problem ist nur: Wenn ich jemanden sage was ich dafür im Monat mindestens kosten würde dann wird jeder der nicht grad nen mittelstands- oder großbetrieb führt vermutlich umfallen... Also probieren es die Leute dann so - ok, HF & GL...
Ne Danke, deine Antworten kenn ich schon von früher.
Das hat mir gereicht.
Das hat mir gereicht.
Tja, das akzeptiere ich.
Und will es auch gar nicht in Zweifel ziehen.
Allerdings weise auf die zwei Interpretationsmöglichkeiten hin:
- du hast damals schon auf keine Antworten gehört. die du nicht hören wolltest und hast heute immer noch die gleichen Probleme
- meine Antworten "von früher" taugten nichts. Aber ich habe mich ja vielleicht seitdem weiterentwickelt.
Mach doch bitte mal eine kleine Umfrage hier, wer es in seinem Unternehmen erlebt hat, das unzumutbare Daten(bank)zugriffszeiten durch fettere Hardware gelöst wurden.
So ein Wunschdenken ist doch seit Jahrzehnten ausschließlich als das Standard-Verkaufsargument für SAP-Produkte bekannt. Und bei denen lässt es sich nicht widerlegen, weil die Datenhaltung in einer Black-Box und tabu und ganz furchtbar geheim ist.
Egal, viel Glück trotzdem
Biber
Moin,
tja - ich glaube bei uns würde eine Lösung da ganz einfach sein: Datenbank zu langsam -> Chef kommt zu mir. Ich hole teure Hardware die aber nix taugt -> Einlauf vom Chef... Ich besorge zusatzteile, Datenbank immer noch langsam -> zimliche Schläge vom Chef ;)
Ganz simple Sache: Wenn eine Firma Leute beschäftigt die dafür bezahlt werden sich um die Hardware u. Software zu kümmern dann erwartet der Chef auch das die Leute wissen was sie tun. Aus diesem Grund wird ein Admin ja auch besser bezahlt als die Putzfrau - und die könnte auch hingehen und einfach nur "irgendeine fette Kiste" kaufen ;)
tja - ich glaube bei uns würde eine Lösung da ganz einfach sein: Datenbank zu langsam -> Chef kommt zu mir. Ich hole teure Hardware die aber nix taugt -> Einlauf vom Chef... Ich besorge zusatzteile, Datenbank immer noch langsam -> zimliche Schläge vom Chef ;)
Ganz simple Sache: Wenn eine Firma Leute beschäftigt die dafür bezahlt werden sich um die Hardware u. Software zu kümmern dann erwartet der Chef auch das die Leute wissen was sie tun. Aus diesem Grund wird ein Admin ja auch besser bezahlt als die Putzfrau - und die könnte auch hingehen und einfach nur "irgendeine fette Kiste" kaufen ;)
Hi !
Das möchte ich stark bezweifeln....
mrtux
Das möchte ich stark bezweifeln....
mrtux
Hi !
Du meintest sicherlich Klosett, gell?
mrtux
Du meintest sicherlich Klosett, gell?
mrtux