[60646] in SAPr3-news
Re: Content Server - flatfile oder DB?
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Markus_D=F6hr?=)
Tue Feb 19 19:43:44 2008
To: sapr3-news@mit.edu
Date: Wed, 20 Feb 2008 01:41:09 +0100
From: =?ISO-8859-1?Q?Markus_D=F6hr?= <wantbottom@t-online.de>
Message-ID: <47BB7725.3040202@t-online.de>
> 2 Leut, 2 Meinungen, vielleicht gibt es ja noch ne dritte ;-)
>
> Ich erinnere mich, daß vor einiger Zeit einem Anwender, der sich
> wegen einer zerschossenen Datei an mich wandte, von der
> Systemtechnik mit der Sicherung einer wenig älteren Vorversion
> geholfen werden konnte, scheint also ein hinreichend schlaues
> Konzept dahinterzustecken (davon versteh ich so wenig, daß ich nicht
> mal mit Schlagworten um mich werfen kann, die ein Wissender
> einordnen könnte).
Wie Du schon selbst richtig geschrieben hast, bleibt die "Logik" im
Backend-System, nur die Dateien liegen auf der Platte
> Dazu kommt, daß bei flatfile mit Deltasicherungen
> gearbeitet werden kann, wogegen eine DB nur ganz oder gar nicht
> gesichert werden kann. Bei einem erwarteten Volumen von ca. 1
> Terrabyte ist die deutlich geringere Netzlast für Sicherungen IMO
> dann schon ein Argument.
Die MaxDB beherrscht auch Delta-Sicherungen (save pages) - sodaß man z.
B. sonntags eine Vollsicherung macht und die Woche über nur die
Deltas/Änderungen sichert.
Es ist eine Strategiefrage. Wenn mal jemand was morgens im R/3 löscht
und es fällt erst am anderen Tag auf, muss man die ganze DB zurücksetzen
und alles, was zwischen den Tagen passiert ist, ist weg. Diese Situation
gab es schon zweimal bei uns und deshalb haben wir uns entschieden,
unsere Content-Server nach Flatfile zu migrieren, da hätte ich dem User
einfach das File wieder aus der letzten Datensicherung zurückladen
können ohne das irgendwelche Inkonsistenzen entstehen.
--
Markus
