Post by Ralph AichingerJa, nur warum sollte man das absichtlich tun? Bei jeder halbwegs
wichtigen Datenbank die ich jemals in Firmen gesehen hab, war
irgendeine Form von nächtlichem/wöchentlichem Dump-Job implementiert,
der das ganze in eine Datei rausgeschrieben hat. Zumindest bei den
relationalen, mit SQL.
Es gab dafür einen Grund, nämlich dass der Restore schnell sein sollte.
Auf einen Restore der Datenbank aus so einem Dump hätte man im Ernstfall
nicht warten können; die Datenbanken waren etwas größer. Ursprünglich
lief das Ganze auf Solaris, später auch auf Linux, Umfeld war SAP (noch
nicht HANA). Und natürlich war von "nachts hat man ja Zeit zum Backup"
keine Rede, der Betrieb lief auch nachts.
Erzeugt wurden da Snapshots auf Hardware-Basis in einem externen
Raidsystem, mehrere Generationen im Raisdystem (meiner Erinnerung nach 2
oder 3 Generationen pro Standort, und die Daten waren (auch über die
Raidsystemne) standortübergreifend gespiegelt - auch im Fall eines
Brandes sollte es schnell weitergehen können). Nicht täglich, nicht
wöchentlich, mehrmals am Tag - auch die im Ernstfall noch anfallenden
Rollforward-Zeiten mussten in Grenzen gehalten werden, wenn man
tatsächlich restoren musste. Das Raidsystem konnte zeitlich "atomare"
Snapshots über mehrere logische Platten, die es dem Host rausreichte,
erzeugen. Anfangs haben wir die Oracle-Datenbamk dazu noch in den
Backupmopde versetzt, aber nach einiger Diskussion mit Oracle waren sich
alle darüber einig: wenn man das geschickt organisiert, also Redologs
und Archivelogs auf die richtigen Platten verteilt (die Archivelogs
wurden natürlich nicht in diesen zeitlich atomaren Snapshot einbezogen),
dann kann man auf so einem Snapshot genb´auso wieder anlaufen wie auf
einem Zustand bei Stromausfall, und die Oraclianer haben es auch
hinbekommen, auf diesem Zustand später angefallene redologs
nachzufahren.
Der Witz des Ganzen war, dass das Raidsystem bei einem SNap-Rollback
sofort wieder auf dem alten Stand war (vom Host aus gesehen), wenn auch
ggf. etwas langsamer (d.h. der Restore lief im Backend des
Rauidsystems,für den Server wars dann etwas langsamer, das Raidsystem
hatte ja damit zu tun, die Snaps zurückzufahren; aber der Rollforward
konnte schon beginnen). Damit waren wir damals dann in der Lage, eine
Datenbank von mehreren Terabyte innerhalb von ca 5-10 Minuten soweit zu
restoren, so dass der Rollforward von Logfiles anfangen konnte.
Ja, auf den ersten Blick klingt das gruselig. Aber das Verfahren wurde
regelmäßig getestet, nämlich einfach dadurch, dass aus diesen Snapshots
auch die SAP-Quaitätssicherungssysteme erzeugt wurden. Und tatsächlich
ist auch einmal ein Fall vorgekommen, wo die SAPler kreidebleich zu den
Admins dieses Verfahrens kamen und sagten "wir haben uns unsere
Datenbank zerschossen, wie schnell könnt ihr welchen Stand wieder
einspielen, wie alt ist die Sicherung?". Die Antwort war "dauert maximal
15 Minuten, ist dann der Stand von vor zwei Stunden". Es war zwar nur
irgendein SAP-Entwicklungssystem, aber die rechneten damit, dass sie
mehrere Zeitverlust hätten hinnehmen müssen ...
Ja, das war eine extrem teure Lösung. Aber Restore innerhalb von 15 min
unabhängig von der Datenbankgröße kostet halt Geld. Und nachdem ich
wusste, wieviel Geld die SAP-Consultants da bekamen, die in Heerscharen
die Kundenlösung bastelten, hatte ich kein schlechtes Gewissen mehr,
teure Hardware zu verwenden, um so was zu bauen.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.