Moin.
Zitat:
Zitat von BigBoymann  Danke Joshua,
Also du wärst der Ansicht, dass ein Speicherupgrade sehr viel mehr bringen würde?Wir könnten theoretisch auf 128GB aufrüsten, müsste mal schauen was das auf die Rechnung bringt.[...] |
Es wäre der erste Schritt - natürlich soll und muss man auch die Auslatung der Platten in punkto Speicherkapazität im Auge behalten genau wie die Auslastung des RAIDs in punkto Durchsatz/Performance.
Zitat:
|
[...]1.) es sind mehrere Files, da DATEV mit rd. 30 Programmen arbeitet sind es je Programm eine Datenbank, die größte Datenbank hat jedoch doch rund 32GB, ist natürlich auch die am häufigsten benutzte[...]
|
Ich meinte mehrere Files/Filegroups _pro Datenbank_ - Standardeinstellung bei SQL beim Anlegen einer Datenbank ist eine Filegroup mit genau einem File pro Datenbank. Wenn die also 32GB groß ist, dann hast du _ein_ 32GB großes File. Man kann diese 32GB aber auf mehrere Files verteilen, verhält sich in punkto Performance ähnlich einem RAID: schnelleres Lesen/Schreiben, weil ja mehrere Dateien zur Verfügung stehen.
Optimalerweise legt man natürlich jedes File auf ein eigenes Laufwerk/eigenes RAID-System (siehst du die Dollarzeichen?!?)....
Zitat:
|
[...]2.) Datenbanken und Logfiles sind getrennt, je auf einem RAID 1 von 15k Platten, der Exchange und Windows teilt sich ein Raid, hier sind die Logfiles eingestellt, die Datenbanken samt DATEV Software sind auf einem anderen RAID[...]
|
Immerhin - und diese RAID-Systeme laufen auch über verschiedene Controller?
Zitat:
|
[...]3.) Was meinst du mit Speicherbegrenzung?[...]
|
Man kann dem SQL-Server mitteilen, wieviel RAM er sich nehmen darf - tut man das nicht (per default ist kein Limit eingestellt), nimmt er sich nach und nach eben alles, was irgendwie da ist.
Da der Exchange (also die store.exe) genau das gleiche Verhalten an den Tag legt, kannst du dir jetzt ausrechnen, das dein System auch deshalb unperformant ist/wird, weil sich Exchange und SQL darum streiten, wer jetzt noch ein bisschen RAM haben darf.
Beim SQL kann man wie gesagt ein Memory-Limit setzen, beim Exchange hingegen geht das nicht - daher trennt man solche Systeme tatsächlich physisch voneinander, insbesondere dann, wenn man an die Grenzen eines SBS-Szenarios gelangt.
Zitat:
|
[...]von dem Rest verstehe ich leider nicht viel.[...]
|
SQL-Datenbanken schreiben in der default-Einstellung Transaction-Logs mit, anhand derer man sehr granular Daten wiederherstellen kann - also z.B. Backup von gestern Abend, 23.00h Uhr, und dann anhand der Logs alle Transaktionen bis 03.50h hinterher. Ob das für DATEV-DBs benötigt wird, kann ich nicht sagen, das solltest du mal euren DATEV-Berater fragen.
Diese Transactions-Logs benötgen natürlich auch nen Haufen Speicherplatz, zumal sie nur nach einer Vollsicherung selbst abgeschnitten werden können - auch ähnlich wie bei Exchange. Google nach "SQL Transaction Logs" liefert dir sicherlich ausreichend Erklärung.
Zitat:
|
[...]Ich hatte zwar generell schon einmal angeregt, dass man einige "ältere" Datenbank mal ausgliedert und diese aus dem SQL ausgliedert[...]
|
Wird dir nicht viel bringen, RAM fressen beim SQL-Server nur die Datenbanken, auf/in denen auch was passiert, also Daten gelesen und geschrieben werden. Aber generell ist die Archivierung von "Alt-Daten" immer eine gute Sache, zumal man damit prima Plattenplatz freiräumen kann.
Cheers,
Joshua