RAID 50

[Raistlin]

Wenn eine Platte oder ein Sektor nicht als defekt erkannt wird (bzw. der Inhalt aus irgendeinem Grund inkonsistent ist), spielt der RAID-Level keine Rolle: Gnadenlos wird der Fehler gespiegelt bzw. wird die Parität zum falschen Bereich errechnet und auf alle Platten geschrieben. Der RAID-Verband reagiert nur sinnvoll, wenn ein Fehler der Platten erkannt wurde. Wie gesagt: Das ist unabhängig vom RAID-Level!

Jain. Ich habe mich da vielleicht etwas unglücklich ausgedrückt. Das eigentliche Problem tritt genaugenommen ja erst beim Lesen auf. Bei RAID 1 kann das System mitunter nicht entscheiden, welche Daten korrekt sind, wenn beide Platten unterschiedliche Daten liefern, 50:50 Chance, daß es die richtigen liest. Bei RAID 5 kann das System zumindest erkennen, daß die Daten nicht mehr stimmen, wenn Daten und Parität nicht mehr zusammen passen, wenngleich eine automatische Korrektur in solchen Fällen sicher genau wie im RAID 1 nicht möglich ist, dazu bedarf es dann wohl z.B. RAID 6, 51 oder 55...

 

Es ist also nicht sinnvoll, als gebranntes Kind das eine Feuer dem anderen vorzuziehen. Dieser Fall verdeutlicht eher die Notwendigkeit einer guten Backup-Strategie als die Vor- und Nachteile bestimmter RAID-Level.

Natürlich ersetzt ein RAID kein Backup.

Obwohl ich auch schon Backups hatte, die laut Log völlig korrekt durchgelaufen waren, und auch Daten auf dem Band hatten. Das was sie gesichert hatten, war aber schon nicht mehr zu gebrauchen. Der MS Jet DB von Exchange sei dank.

 

Wie gesagt: Verteile die unterschiedlichen Zugriffsmuster (einmal sequenziell: Logfiles, einmal zufällig verteilt: die eigentliche Datenbank) auf verschiedene Plattenverbände (unabhängig vom RAID-Level).

Kann man sagen, welche Zugriffe häufiger sind? Die Logfiles werden nur bei Änderungen der DB weiter geschrieben, oder? Wann werden sie eigentlich gelesen? Die eigentliche DB wird ja ständig gelesen und gelegentlich beschrieben. Ist die DB damit nicht schon aktiver als die Logfiles? Wäre das ein Grund das OS zu den Logfiles zu packen?

[Godrik]

Bei RAID 5 kann das System zumindest erkennen, daß die Daten nicht mehr stimmen, wenn Daten und Parität nicht mehr zusammen passen.

Beim Lesen wird die Parität nicht geprüft. Beim Schreiben wird eine neue Parität errechnet und geschrieben. Passen also Daten und Parität nicht zueinander, hast Du auch bei RAID5 Pech gehabt und merkst es u.U. erst spät.

 

Kann man sagen, welche Zugriffe häufiger sind? Die Logfiles werden nur bei Änderungen der DB weiter geschrieben, oder? Wann werden sie eigentlich gelesen? Die eigentliche DB wird ja ständig gelesen und gelegentlich beschrieben. Ist die DB damit nicht schon aktiver als die Logfiles? Wäre das ein Grund das OS zu den Logfiles zu packen?

Die Platten für die eigentliche DB haben wesentlich mehr zu tun. Das wäre ein Grund, das OS zu den Log-Dateien zu packen. (Die Logfiles werden nur geschrieben, außer beim Restore)

Andererseits kann ein Schreibvorgang erst dann beendet werden, wenn auch der Log-Eintrag erfolgt ist. Auch wenn der Plattenstapel für die Log-Dateien weniger Positionierzeit braucht, stört hier das Betriebssystem das schöne Hinter-einander-weg-schreiben. Ist das Betriebssystem erst einmal hochgefahren, sollte es jedoch keine häufigen Aktivitäten (im Verhältnis zur Datenbank) zeigen. Daher sollte es nicht so sehr ins Gewicht fallen.

Was sagen eigentlich die Lieferanten/Entwickler der Datenbank? Die müssten doch auch Erfahrungswerte haben.

 

Gute Nacht:tired:

Matthias

[Gork Harkvan]

Ja nachdem wie ihr den zweiten Server (Ersatzsystem) betreibt (ob voll Synchronisiert -was ich eher nicht glaube- oder per Logshipping ) werden die Logs dann gelesen, wenn ihr sie auf den Ersatzserver schiebt.

Dort werden sie dann eingelesen, um den Ersatzserver auf Stand zu bringen.

 

Gelesen wird der Log außerdem, wenn einer der Anwender Bockmist macht und

du die sachen wirder rückgängig machen willst.

 

Ansonsten werden sie nur geschrieben, und da das gleichzeitig wie das Datenbankschreiben passiert, sollten die Logs halt auf einer anderen Platte liegen. Auch wegen Plattenversagen.

 

Wie wärs denn mit Raid5 für die DB und Raid 1 für die Logs?

[Raistlin]

Wie wärs denn mit Raid5 für die DB und Raid 1 für die Logs?

Ich habe nur maximal 8 Platten im System. Momentan liebäugele ich mit 2 RAID 5 zu je 4 Platten, von denen eine jeweils Hotspare wäre.

 

Aber über den Mechanismus, wie die Datenbank auf den Sekundär-Server übetragen wird, habe ich mir noch keine Gedanken gemacht. Ich weiß, daß es zur Not über den Basis-Mechanismus Dump und neu einlesen funktionieren könnte.

 

Aber das ist glücklicherweise ein Software-Problem, während ich nur die Hardware zusammen stellen muß.

[daraubasbua]

...

 

Kann man sagen, welche Zugriffe häufiger sind? Die Logfiles werden nur bei Änderungen der DB weiter geschrieben, oder? Wann werden sie eigentlich gelesen? Die eigentliche DB wird ja ständig gelesen und gelegentlich beschrieben. Ist die DB damit nicht schon aktiver als die Logfiles? Wäre das ein Grund das OS zu den Logfiles zu packen?

 

Oracle schreibt JEDE Änderung zunächst enmal ins Logfile (Auch die Rollback/Undo information aus Gründen der Datenkonsistenz) - von expliziten NOLOGGING Operationen mal abgesehen. Also steht im Logfile auch mehr drinn.

 

Sowohl die Logfile als auch die Datenfile I/O sind allerdings gepuffert (die Grösse bestimmst du im Parameterfile der Instanz). Logfiles werden allerdings zyklisch (wieder-) verwendet, d.h. wenn Du N Gruppen hast (sie können noch zusätzlich gespiegelt werden, "Memebers") wird, wennd die Member der Gruppe N voll sind, wieder Gruppe 1 verwendet.

 

Wenn Du keine Datenvverluste akzeptieren kannst (Produktionsumgebung und so ), dann musst Du die DB im ARCHIVELOG mode betreiben. Dann wird jedes volle Logfile von der Datenbank auf eine (oder mehrere) Archivelog Destination(s) kopiert. Die brauchst Du für einen Rollforward von einem Backup aus.

[Gork Harkvan]

Wie wärs denn mit Raid5 für die DB und Raid 1 für die Logs?

Ich habe nur maximal 8 Platten im System. Momentan liebäugele ich mit 2 RAID 5 zu je 4 Platten, von denen eine jeweils Hotspare wäre.

 

Aber über den Mechanismus, wie die Datenbank auf den Sekundär-Server übetragen wird, habe ich mir noch keine Gedanken gemacht. Ich weiß, daß es zur Not über den Basis-Mechanismus Dump und neu einlesen funktionieren könnte.

 

Aber das ist glücklicherweise ein Software-Problem, während ich nur die Hardware zusammen stellen muß.

 

Dump auf dem anderen Rechner hochziehen dauert im Zweifel viel zu lange,

zumal du sie nicht verfügbar hast, wenn dir z.B. der Rechner abraucht.

Es gibt glaube ich relativ einfache Mechanismen die logfiles auf den Ersatzrechner rüber zu kopieren und dort sequenziell einzulesen.

 

Persöhnlich würde ich für die Logfiles Raid 1 machen, weil du da bei Plattenausfall nicht mehr groß rekonstruieren musst, was Zeit kostet und auch schon mal schief gehen kann.

Und dann hast du für die DB und Betriebsystem noch 6 Platten incl. Hotspare.

 

Naja nur imo, da gibt es sicher Leute die als admin mehr von verstehen als ich ;-).

[Akeem al Harun]

Die Platten für die eigentliche DB haben wesentlich mehr zu tun. Das wäre ein Grund, das OS zu den Log-Dateien zu packen. (Die Logfiles werden nur geschrieben, außer beim Restore)

Muss ich noch antworten?

 

@Raistlin:

 

Ich habe mal Onkle Google gefragt und ein paar Links für dich:

 

Optimale Hardware Konfiguration für Oracle Datenbanken (PDF, HP User Society)

Linux Magazin, Schneller Oraceln (bezieht sich allerdings auf Oracle 8)

Oracle Database Performace Tuning Guide, Chapter 8: I/O Configuration and Design

 

Viele Grüße

Harry

[Widukind]

Also ich betreibe selbst mehrere Oracle-Server, alle mit RAID1 und taeglichem Backup to Tape. Ideal ist es, wenn man Archive Logs und Daten auf verschiedene Raid-Paare legt, dann kann man die DB schnell wieder herstellen, wenn ein RAID-Paar tatsaechlich komplett ausfallen sollte.