[sage] Linux LVM2: Rollback von Snapshots möglich?

[Thomas Fritzinger]

Hallo Wolfgang

On 07/28/2008 08:51 PM, Wolfgang Stief wrote:
> On Mon, 28 Jul 2008 17:25:18 +0200
> "Martin Schröder" <martin at oneiros.de> wrote:
> 
>> Am 28. Juli 2008 17:04 schrieb Wolfgang Stief <stief at guug.de>:
>>> Mein Szenario ist eine Datenbank (hier konkret Oracle), in der lange
>>> Batch-Jobs laufen. Anforderung ist, dass vor bestimmten Batchläufen
>>> (die teilweise mehrere Stunden laufen) der Datenbankzustand in
>>> irgendeiner Form eingefroren wird. Falls der Batchlauf fehlerhaft
>>> ist (gibt Checks am Ende), soll möglichst schnell und möglichst
>>> einfach auf den Zustand vor dem Batchlauf zurück gestellt werden
>>> können.
>> Transaktion in der DB mit Rollback/Commit ist keine Möglichkeit?
> 
> Im Prinzp schon, aber: Die DB soll im Fehlerfall SCHNELL auf einen
> alten Stand zurück gefahren werden können um den (korrigierten)
> Batchlauf erneut starten zu können. Wir arbeiten hier eh schon auf
> einer Kopie, weil die Batches in Summe fast 24h laufen. Das
> dazugehörige OLTP-System läuft parallel auf einer Kopie, die Änderungen
> aus dem OLTP werden nachts in die Batch-DB überführt. Per OLTP ändern
> sich täglich je nach Monatstag zwischen 1% und 5% des gesamten
> Datenbestandes.
> 
> Wenn man sich jetzt mal vorstellt, was in 3h in einer 10TB-Datenbank so
> alles passieren kann, was man ggf. komplett zurück rollen müsste, dann
> ist das aus Zeitgründen keine wirkliche Option. Je nach Batchlauf haben
> wir im Extremfall ein Schreib-Lese-Verhältnis von 90:10, im Schnitt
> etwa 50:50.
> 
> Im Moment läuft das System auf einem BS2000 mit ISAM-Files. Die sind --
> weil stark komprimiert -- deutlich kleiner, als die gleichen Daten in
> Oracle sein werden. Und der Großrechner hat natürlich ein etwas
> anders I/O-Verhalten, als das ein SLES auf Intel/AMD haben wird :-)
> Meine Firma wiederum ist externer Dienstleister und wurde zu einem
> Zeitpunkt hinzugezogen, wo die wesentlichen Design-Kriterien schon
> beschlossen waren und die Programmierer bereits ersten Alpha-Code
> fertig hatten. 
> 
> Das BS2000 System kann diese Rollback-Funktion per Snapshots (bzw.
> abgehängten Spiegelbeinen) sehr schnell ausführen, was das neue System
> auch können soll (gegenüber den Anwendern darf es keine
> Verschlechterung des Service geben). Unsere Aufgabe ist im Prinzip nur,
> eine Gegenübersstellung auszuarbeiten, welche
> Replizierungsmöglichkeiten für welche Zwecke sinnvoll sind und wo
> welche Stolperfallen lauern. Die Entscheidung, welche Verfahren in
> welchen Bereichen des Projekts eingesetzt werden, liegt nicht bei uns. 

Neben der reinen Rollback-Funktion auf Dateisystem-/BS-Ebene sehe ich
noch 2 Moeglichkeiten, ueber die Du nachdenken koenntest:

1. Direkt in der (Oracle) DB
   Je nach Groesse der betroffenen Tabellen und der darauf liegenden
   Indexe und Constraints koennte ein vorgaengiges Kopieren der Tabellen
   moeglich und evtl. schneller sein. Insbesondere das Rollback ginge
   dann in Sekunden (rename). Das setzt natuerlich voraus, dass Du sehr
   genaue Kenntnisse ueber die Batches hast, was davon angefasst wird,
   und auch ueber die Rechte in der DB etc., die dann ja neu angelegt
   werden muessten.
2. Auf Hardware-Ebene
   Ist ein gespiegeltes SAN eine Option? Wenn das Budget das hergibt,
   waere das die Option, die ich am ernsthaftesten verfolgen wuerde.

Wenn Du den Batch und evtl. Rollbacks in der DB beschleunigen moechtest,
kannst Du auch darueber nachdenken, das Logging (und Archiving, oder nur
letzteres) temporaer zu deaktivieren.

Viele Gruesse
Thomas