SQL-Server 2005 Konfiguration/Partitionierung

[orca]

Hallo zusammen,
ich weiß, dass das Thema hier nicht unbedingt 100%ig richtig aufgehoben ist, aber in diesem Forum habe ich schon viele gute Tipps erhalten.

Zur Situation: Ich habe mit in meinem NB eine zweite Festplatte eingebaut und wüsste nun gerne wie ich die Datenbankdatein des SQL-Servers am besten auf die beiden Platten "verteile", um eine möglichst optimale Performance zu erreichen.

Eingesetzt wird sowohl das relationale als auch das multidimensionale Modul des SQL Servers. Die relationalen Datenbanken sind aktuell bis zu 30GB und die OLAP Cubes bis ca. 5GB. Der Cube wird aktuell aus der lokalen relationalen DB erstellt.

Aktuelle Konfiguration:
HDD 1: OS, SQL-Server 2005
HDD 2: DATA und LOG Dateien der SQL und OLAP Datenbanken

Es ist wahrscheinlich nicht Optimal Quell- und Zieldatenbank auf einem Laufwerk zu betreiben nehme ich an?! Zudem ist während der Verarbeitung des Cubes eine erhebliche Last der Systemplatte (HDD1) festzustellen - liegt das an der System-Tempdb?

Es wäre schön, wenn ihr mir einige Vorschläge machen könntet, wie ich das das System besser Partionieren könnte.

Gruß
orca

 

[jni]

Ich hab zwar keine Erfahrung mit SQL2005 und OLAP, aber meine Erfahrung mit SQL2000 sagt, daß möglichst viel Speicher das meiste bringt. Wenn du dich da in x GByte großen Tabellen bewegst, sollten schon 3 oder mehr GByte RAM drin sein (was auf dem Notebook wohl schlecht geht) !

Bei SQL2000 ist es sinnvoll, das LogFile und das DatenbankFile auf verschiedene Platten zu legen. Außerdem ist es bei manchen Operationen sinnvoll, daß de TempDB und das DatenbankFile auf verschiedenen Platten liegen (wenn halt große Datenmengen in die TempDb geschaufelt werden). Wenn die Daten vorwiegend von einer DB in die andere geschaufelt werden, sollten die beiden DatenbankFiles natürlich auf verschiedenen Festplatten liegen.

 

[wuggu@work]

Hallo,

wenn du "nur" 2 Festplatten hast, hast du nicht soviele Alternativen was die Verteilung der Datenbankdateien anbelangt. Performancesprünge kannst du jedenfalls nicht mit dieser Konfiguration erwarten. Ich empfehle dir, zuerst einmal die daten für den Cube von den Daten der relationalen Datenbank zu trennen. Da deine Multidimensionalen Daten aktuell einen geringeren Umfang haben als die operationalen würde es ggf. Sinn machen diese mit auf die erste Festplatte zu packen, und die große Datenbank dann auf die zweite Festplatte. Die Trennung von den operationalen Daten und den Daten für den analytischen Teil ist in jedem Fall sinnvoll, das Erstellen von Cubes auf der Basis einer relationalen Datenbank ist aus Sicht der Datenorganisation auch unsinn. Während du bei relationalen Datenbanken jegliche Redundanzen versuchst zu verhindern, machst du bei multidimensionalen Daten genau das Gegenteil, denn je einfacher die Daten zu lesen sind, desto performanter ist das Ganze nachher.

Ich empfehle dir von Ralph Kimball das "Data Warehouse Lifecycle Toolkit", erhältlich bei Amazon.

Zurück zur reinen Hardware - Performance: Im Grunde genommen bist du mit den Größen an Datenbanken die du da hast schon weit über den Punkt gekommen wo der Arbeitsspeicher allein über die Gesamtperformance entscheidet. Wichtig ist die I/O Geschwindigkeit der Storage - Lösung an sich, und die ist bei Notebookfestplatten sowieso nicht besonders hoch. Nicht umsonst setze ich bei dieser Art von Entwicklung immer noch auf einen Rechner mit einem guten SCSI Raid Subsystem mit 15k U/Min Festplatten. Zum Thema Aufteilung habe ich oben schon was gesagt, für eine bessere Beratung brauche ich mehr Angaben was gemacht werden soll und welche Hardware genau zur Verfügung steht.

gruß
w@w
PS: Das Thema gehört wirklich nicht hier herein, aber wenn ich ehrlich bin, wüsste ich auch nicht wo ich es erstellen oder hin verschieben sollte, deswegen lasse ich es mal hier.

 

[orca]

hallo zusammen,
erst einmal danke für die schnellen Tipps...

Zu den Details:

wenn du "nur" 2 Festplatten hast, hast du nicht soviele Alternativen was die Verteilung der Datenbankdateien anbelangt. Performancesprünge kannst du jedenfalls nicht mit dieser Konfiguration erwarten.

Genau genommen hätte ich 3 Festplatten zur Verfügung: die zwei internen (160GB Samsung) und eine Externe 120er Platte. Da die Performance über USB aber nicht so toll erschien, habe ich mich entschlossen die erste (zu kleine) interne zu wechseln und eine zweite Platte für den Wechselschacht anzuschaffen (Dell D/Bay).
Performancezuwäsche erwarte ich mir wenigestens in Bezug auf die bisherige Lösung mit einer langsamen internen Platte .

Ich empfehle dir, zuerst einmal die daten für den Cube von den Daten der relationalen Datenbank zu trennen. Da deine Multidimensionalen Daten aktuell einen geringeren Umfang haben als die operationalen würde es ggf. Sinn machen diese mit auf die erste Festplatte zu packen, und die große Datenbank dann auf die zweite Festplatte.

Das war auch meine Idee. Wird beim aufbereiten des Cube denn noch die TempDb o.ä. genutzt, denn ich hatte wie erwähnt auf der Systemplatte extrem viel Aktivität, obwohl sich ja im ersten Approach alle Daten auf der zweiten Platte befanden?

Die Trennung von den operationalen Daten und den Daten für den analytischen Teil ist in jedem Fall sinnvoll, das Erstellen von Cubes auf der Basis einer relationalen Datenbank ist aus Sicht der Datenorganisation auch unsinn. Während du bei relationalen Datenbanken jegliche Redundanzen versuchst zu verhindern, machst du bei multidimensionalen Daten genau das Gegenteil, denn je einfacher die Daten zu lesen sind, desto performanter ist das Ganze nachher.

Trennung sinnvoll, da die Datenbanken für unterschiedliche Anwendungsfälle genutzt werden. Nur das wir uns nicht falsch verstehen: Das Erstellen der Cubes aus relationalen Daten ist der übliche und sinnvolle Weg, nur werden die Daten dabei wie du sagtest wieder denormalisiert - was inbezug auf die analytische Anwenung auch unproblematisch erscheint...

Ich empfehle dir von Ralph Kimball das "Data Warehouse Lifecycle Toolkit", erhältlich bei Amazon.

Danke - Werde mal einen Blick riskieren

Zurück zur reinen Hardware - Performance: Im Grunde genommen bist du mit den Größen an Datenbanken die du da hast schon weit über den Punkt gekommen wo der Arbeitsspeicher allein über die Gesamtperformance entscheidet. Wichtig ist die I/O Geschwindigkeit der Storage - Lösung an sich, und die ist bei Notebookfestplatten sowieso nicht besonders hoch. Nicht umsonst setze ich bei dieser Art von Entwicklung immer noch auf einen Rechner mit einem guten SCSI Raid Subsystem mit 15k U/Min Festplatten.

I.d.R wird die reale Durchführung auch auf anderen Rechnern beim Kunden durchgeführt. Es kommt aber häufig vor das man Sachen auch lokal probieren will - und da hat mal halt nur sein NB dabei mit dem man Leben muss .

Zum Thema Aufteilung habe ich oben schon was gesagt, für eine bessere Beratung brauche ich mehr Angaben was gemacht werden soll und welche Hardware genau zur Verfügung steht.

Das NB hat einen C2Duo (T7200) mit 2GB Ram und wie erwähnt derzeit zwei 160er Samsung Platten und ggf. eine 120er über USB. Leider hat das NB keinen ExpressCard Steckplatz, sodass eSata leider ausfällt. Eine schnelle externe 3.5" Platte wäre sonst noch "tragbar" gewesen...

Aktuelle Aufgabe ist es einfach gesagt aus der relationalen DB gewisse aggregierte Berichte u.a. mittels SSRS zu erzeugen. Um kurze Antwortzeiten zu garantieren will ich halt für bestimmte, insbesondere dynamische Berichte, SSAS einsetzen, was wohl auch sinnvoll ist...

Gruß
orca

 

[underclocker2k4]

Das NB hat einen C2Duo (T7200) mit 2GB Ram und wie erwähnt derzeit zwei 160er Samsung Platten und ggf. eine 120er über USB. Leider hat das NB keinen ExpressCard Steckplatz, sodass eSata leider ausfällt. Eine schnelle externe 3.5" Platte wäre sonst noch "tragbar" gewesen...

Es gibt durchaus SATA adpater für cardbus(pcmcia).
http://search.ebay.de/search/search.dll?fsop=1&fsoo=1&from=R45&satitle=pcmcia+sata

Zu SQL kann ich leider nix sagen...

EDIT:
Wenn es unbedingt eSATA sein soll:
http://www.hardware-rogge.com/Zubehoer/PCMCIA-Adapter/Delock-PCMCIA-CardBus-zu-2x-eSATA::3550.html

Wobei esata und sata stecker kompatibel ist. Man sollte nur net all zu lange kabel verwenden.

 

[orca]

Es gibt durchaus SATA adpater für cardbus(pcmcia).
http://search.ebay.de/search/search.dll?fsop=1&fsoo=1&from=R45&satitle=pcmcia+sata

Danke. Weißt Du auch wie die Performance des CardBus (PCMCIA) Steckplatzes ist. Hängt denke ich am normalen PCI-Bus oder?! Eigentlich sollte USB 2.0 ja auch reichen, habe auch noch keine richtigen Benchmarks durchgeführt. Die gefühlte Performance beim kopieren einer Datei unter Vista von einer externen 2.5" auf die interne war allerdings ernüchternd (10-15MB/s)...

Gruß
orca

 

[underclocker2k4]

http://www.forumdeluxx.de/forum/showthread.php?t=165050&highlight=pcmcia

Mußte mal kucken ob du was findest. PCMCIA ist ja PCI interface. Also alle komponenten ~133MB/s laut specs.

Die card sind ja nur SATA controller in PCMCIA form.
Einzeln haben die teile dann den vollen speed, den die platte schafft.
Parallel geht dann nur alles zusammen bis 133MB/s PCI halt.