AW: AW: Grenzen von MySQL

[Andreas Müller]

Hallo Gerhard,

> Was mich aber in dem Zusammenhang noch interessieren würde, ist
> Deine Interpretation des von Dir gebrauchten Begriffs
> "Datenverlustrisiko bei leicht beschädigter Datenbank".
>
> Was ist eine "leicht beschädigter Datenbank", wie kommt es dazu,
> welche Mittel gibt es zur Behebung dieser Probleme (evtl.
> DB-spezifisch)?

Wie es zu so einer Datenbank kommt ist oft recht unterschiedlich. Oft kommt
es dazu wenn der Server crasht, also nicht der SQL Dienst sondern die
Maschine an sich. Plattenausfälle, Controller-Probleme, Netzprobleme etc.
etc.
Teilweise sind das aber auch Probleme in der Datenbank selber.
Ich teste sowas gern indem ich bei massiven Schreiboperationen die Maschine
einfach ausschalte, das auch 1-2 mal wiederhole (Simulation
unbeaufsichtigter Stromausfälle).

Interbase:
Wird selbst auf stabil laufenden System zum Teil instabil ohne das
irgendetwas mit der Maschine passiert, Daten via Backup/Restore meist noch
zu retten. Zerstörung von Daten möglich vor allem wenn Dateigrößengrenze
erreicht ist oder Festplatte voll. Dann kann es zu irreparablen
Datenverlusten kommen meist sind aber Teile der Daten noch zu retten. Grund
für Datenverluste scheinen schwachstellen in der internen Datenverkettung zu
sein.

Oracle:
Hat die meistens Tests recht gut überstanden. Mit Boardmitteln war oft alles
bzw. sehr viel wiederherstellbar. Einmal aber Totalverlust. Da liegt die
Vermutung nahe das dieser Fall von Inkosistenz in den Reparaturtools nicht
vorgesehen war. Alles in allem rech stabil von den Daten her aber nicht ganz
ungefährlich. Besser sind da mind 2. Server mit Replikation. Probleme hatte
ich wie schon gesagt mit großen Tabellen und Indizes (mehr als 25 Millionen
Datensätze). Und mit schnellem schreiben:
Wenn man Oracle richtig unter Strom setzt kann es passieren das es sich
totläuft: Der Logbereich wird zu langsam vergrößert es kommt zu nem Fehler
da kein Log geschrieben werden kann, dieser Fehler soll auch geloggt werden,
kein Platz -> DB Server steht. Habe ich mehrfach auf Win32 System
nachvollziehen können. Praktisch äußerst riskant -> guter Admin nötig.

DB2:
Kann man fast das gleiche wie bei Oracle sagen.

MS-SQL:
Beschädigte Datenbanken sind aufgrund recht weniger Reparaturmittel ein
Problem. Schon 2 Komplettverluste von Aktivdatenbanken gehabt, aber dank
Replikation und regelmäßigen Backups kein Problem. Da ein Backup hier nichts
weite ist als das kopieren der Originaldaten (fast, bissel was macht die da
schon) nützt auch kein Backup/Restore. Da man hier extrem wenig
Möglichkeiten habe fahre ich hier mit besonderer Sicherheit.

MySQL:
Bis heute die stabilste Datenbank die ich verwende. Wenn crash dann war
bisher alles wunderbar wiederherstellbar. MyISAM Tabellen lassen sich auch
hervorragen reparieren. InnoDB hatte ich auch keine Probleme. Probleme gab
es einmal bei einem Test ein Backup+Logs wieder einzuspielen weil er
mittendrin abgebrochen hat mit einem Duplicated Key ... woher der kommt
keine Ahnung.

Alles in allem kann man sagen: Wenn ich eine wichtige DB habe muss ich mit
jedem Server dafür sorgen das sie gut abgesichert wird. Bei
Interbase/Oracle/DB2 habe ich Serverseitigen Problem festgestellt die eine
Datenbank im laufenden Betrieb in die Ecke fahren können (siehe oben). Daher
reicht es nicht immer einfach ein 2. System als Replik vorzuhalten da das
Problem diese Repliken auch betreffen kann. Am besten die Datenbank unter
Echtbedingungen testen und überwachen und beobachten was passiert. Bei
Oracle und DB2 immer genügend Platz in den Tablespaces gerade im Log-Bereich
vorhalten.
Gescheite Hardware setze ich mal voraus: Redundante Netzteile, gespiegelte
Platten, Hotplug ...

Gruß,
Andreas

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql