Daten in 2 Datenbankdateien gleichmässig verteilen

[N. Walter]

Hallo, ich hab folgendes Problem:

folgendes szenario
eine datenbank ca 2 gb groß mit nur einer datendatei.
nun soll aus performancegründen eine zweite datei erstellt werden und auf einen anderes laufwerk gelegt werden (noch kein problem)

nun das problem:
die erste datei ist 2 GB groß die zweite ist noch leer.

<b>wie bekomme ich es hin, dass die zweite datei automatisch mit der hälfte der ersten datei gefüllt wird?????</b>

SUPERDRINGEND !!!!

thx for all

[Jochen Reichenberg]

Dafür verwendet man normalerweise RAID-Systeme. Vorzugsweise RAID 5, ab 3 HDDs aufwärts. Da muß man dann softwareseitig gar nichts machen. Alles andere würde mehr Kosten verursachen, als die Anschaffung der notwendigen Hardware - denke ich.

Grüße Joche

[Andreas Kosch]

Hallo,

es gibt für dieses Problem mehrere Ansätze. Falls der MS SQL Server 2000 genutzt wird, könnte man folgendes machen:

Alternative 1: Die Tabellen der Datenbank werden auf verschiedene FILEGROUPS verteilt. Für jede FILEGROUP kann man festlegen, auf welchem Laufwerk diese angelegt werden. Wenn die neue (leere) Datenbank verteilt auf die Festplatten angelegt wurde, wird der Enterprise Manager oder der Import-/Export-Assistent genutzt, um die Daten von der originalen Datenbank umzukopieren.

Alternative 2: Die Festplatten werden als RAID 0 oder RAID 10 zusammengeschaltet und dann wird das Komplett-Backup der Datenbank zurückgespielt. Das RAID-System sorgt dann selbst für die Verteilung. Ein RAID5 ist für Datenbanken nicht geeignet, da der Inhalt der Datenbank-/Logdatei aufgrund der Transaktionssteuerung viel zu volatil dafür ist (d.h. RAID5 ist eine drastische Performance-Bremse)

[Jochen Reichenberg]

Hallo Andreas,

da möchte ich dann doch wiedersprechen (hätte nie gedacht, daß das mal passiert ). RAID 0 würde ich keinesfalls verwenden, da keinernelei Sicherheit vorhanden ist -> 1 defekte Platte -> alles weg...

Aber mir ist nicht klar, warum ein RAID 5 für Datenbanken nicht geeignet sein soll, respektive warum das eine Performancebremse sein soll. Unsere informix-DB fühlt sich auf dem RAID 5 offensichtlich sehr wohl und von mangelnder Performance kann ich definitiv auch nicht sprechen...

Wohlgemerkt spreche ich von Hardware RAID 5, nicht Software RAID 5 (das ist definitiv recht langsam). Aber ein entsprechender SCSI Controller mit 32 oder 64 MB Cache, ein paar passende Platten. Natürlich sollte man auch die Anschaffung einer USV in Betracht ziehen...

Grüße Joche

[Andreas Kosch]

Hallo,

&gt;..hätte nie gedacht, daß das mal passiert

ein konstruktives Streitgespräch ist immer erfrischend und belebt Geist und Körper ;-)

Ein RAID0-Array hat die (fast) gleiche Ausfallsicherheit wie eine einzelne Festplatte, ist aber beim Schreiben/Lesen fast doppelt so schnell. Wenn <b>zusätzlich</b> zur besseren Performance auch die Datensicherheit gegenüber einer einzelnen Festplatte gesteigert werden soll, ist RAID10 die beste Wahl (also ein RAID0-Array als RAID1 gespiegelt).

Ein RAID5-Array macht bei statischen File-Servern Sinn, bei denen sich die meisten Dateien im laufenden Betrieb nicht mehr ändern. Im Fall einer SQL-Datenbank wird die Datendatei und die Logdatei allerdings permanent geändert, so dass das RAID5-Array ständig die Prüfsummen neu berechnen und gleichmässig auf die Platten verteilen muss.

Ich habe das Ganze einmal mit einer mittelgroßen DELL-Kiste (2 CPUs, 8 Festplatten mit 2 RAID-Controllern) getestet. Bei sehr häufigen Schreibvorgängen bricht ein RAID5-System stark ein. Hingegen war das 2x4 RAID0-Array nicht zu schlagen.

P.S: RAID5 ist ein "RAID1 für Arme", denn der Vorteil von RAID besteht nur darin, dass Festplatten eingespart werden. In der heutigen Zeit sind die Festplatten-Preise allerdings deutlich moderater, als das früher der Fall war

[Jochen Reichenberg]

Hallo Andreas,

RAID 10 ist unbestritten die schnellstmöglichste Lösung, bei größtmöglicher Sicherheit. Und höchstem Preis. Aber was die Systemperformance angeht: Bei ca 250 € für 'gute' 36 GB SCSI-Platten machen 4 Platten mehr oder weniger schon 1000 Euro. Da bin ich mir dann schon nicht mehr sicher, ob die nicht besser in mehr / schnelleren RAM oder Prozessor(en) investiert werden sollten. Ist noch die Frage, was dann schneller ist. Hast Du damit auch Erfahrungen sammeln können?

Lassen sich die Einbrüche beim Schreiben zwischen RAID 10 und 5 in Prozent angeben?

Grüße und Schönes Wochenende,

Joche

[Andreas Kosch]

Hallo,

&gt;Lassen sich die Einbrüche beim Schreiben zwischen RAID 10 und 5 in Prozent angeben?

ein Bild sagt mehr als tausend Worte. Die folgende Abbildung (zeigt die CPU-Auslastung des mit 2 Prozessoren bestückten Datenbank-Servers) stammt aus einem Last-Test, bei dem eine auf dem Anwendungs-Server installierte COM+ Anwendung den separaten Datenbank-Server unter maximalen Stress gesetzt hat. Das RAID0-System konnte dabei ein Mehrfaches von gleichzeitigen Nutzern vertragen als das RAID5-System. Wie die Grafik zeigt, musste beim RAID5-System die CPU immer wieder auf die "langsame" Festplatte warten, während beim RAID0 der Prozessor ungebremst loslegen konnte.

&gt;.. schnelleren RAM oder Prozessor(en) investiert werden sollten.

Das hilft nicht - denn wie die Abbildungen zeigen, wird bei RAID5 die CPU nicht voll genutzt, weil auf das mechanische Teil (die Festplatte) gewartet werden muss. Der Datenbank-Server ist bereits mit 2 GByte RAM bestückt, aber trotzdem kommt es bei RAID5 zu diesen Einbrüchen

[Jochen Reichenberg]

Hallo Andreas,

das ist dann ja wohl eindeutig!

Muß ich doch glatt mal prüfen, ob unser RAID-Controller RAID 10 beherrscht...

Danke,

Joche

[Andreas Kosch]

Hallo,

&gt;..ob unser RAID-Controller RAID 10 beherrscht...

ich würde zuerst über einen Last-Test prüfen, ob dieses auffällige RAID5-Verhalten auch auf dieser Maschine gilt. Je nach Konfiguration und Festplattenanbindung (FiberChannel, SNA mit Schreibcache etc.) kann sich das im Einzelfall unterscheiden

[Jochen Reichenberg]

Hallo Andreas:

>SNA mit Schreibcache

sagt mir nix (Systems Network Architecture ??).

Tja, wie ich auf dem Ding einen Lasttest durchführen soll, ist mir im Moment noch nicht klar. Es handelt sich um einen Linux-Server - und in Linux bin ich bestenfalls als Anfänger zu bezeichnen. Was ich sagen kann, ist daß es sich um SCSI System handelt, 64 MB on-board Cache, U160 mit 10.000 U/min Platten (was aber m.E. nur die Latenzzeit beeinflußt, aber nicht die Schreib- oder Lesegeschwindigkeit).

In dem Server befindet sich noch ein RAID 1 Array (für das OS). Wäre es einen Versuch wert das Transaktionsfile auf das RAID1-Array zu legen?

Danke nochmals,

Jochen

P.S.: Ich werde auf gar keinen Fall 'einfach drauf losbasteln', sondern in jedem Fall erst Rücksprache mit dem Systemhaus halten, die uns die Maschine so passend für unsere Datenbank verkauft hat. Umbauten werden sowieso nur durch das Systemhaus durchgeführt

[Andreas Kosch]

Hallo,

&gt;...sagt mir nix...

äh, da habe ich auch SNA mit SAN verwechselt: <br>
- NAS = Network Attached Storage <br>
- SAN = Storage Area Network

Eine SAN ist ein Array von Festplatten, das mit den RAID-Controllern als seperates Gehäuse (Einschub) ausgelegt wird. Man kann auf diesem Weg zum Beispiel auch 16 Festplatten als RAID0-Array (oder RAID10) zusammenschalten. Die SAN wird in der Regel über einen Fiber Channel (2 GB Übertragungskapazität) mit dem Datenbank-Server verbunden und enthält auch einen "sicheren" Schreibcache (typischerweise 8 MByte). Durch diese Kombination (viele parallelgeschaltete Festplatten + Fiber Channel + Schreibcache) sind diese Dinger extrem schnell.

&gt;Wäre es einen Versuch wert das Transaktionsfile auf das RAID1-Array zu legen?

Das würde in jedem Fall etwas bringen, denn dann stehen für die Datendatei und die Logdatei verschiedene Festplatten zur Verfügung, die gleichzeitig und unabhängig voneinander adressiert werden können.

&#10

[Jochen Reichenberg]

Hallo Andreas,

das mit dem Transaktionsfile werde ich bei Gelegenheit mal ausprobieren.

Und falls sich Performanceprobleme bei schreibintensiven Arbeiten ergeben, habe ich zumindest schon mal einen potentiellen Übeltäter.

Vielen Dank.

Grüße Joche