Das eine ist das was man deklarativ in einer Datenbank machen kann, in dem man ein paar Befehle
ausführt und wenn man Pech hat, die Größe der Datenbank explodieren lässt und das andere ist
das, was man mit den Mitteln der Datenbank schon lange kann.
Wir nutzen unsere Replikation in Firebird schon seit Jahren auch dafür, das wir eine unlimited
Redo/Undo Log haben und die Entstehungsgeschichte jedes Datensatz der letzten 5 Jahre bei einem
unserer wichtigsten Kunden bei Bedarf nachschauen zu können, und dann nicht nur wer wann was
gemacht hat, sondern auch welche Daten vorher in der Datenbank waren. Die üblichen Felder
create/update user/timestamp in jeder Tabelle kann man sich daher sparen, weil die eh nichtssagend
sind und beim delete eh verloren wären.
Neben der Tatsache, das wir auf dem Wege auch alle gelöschten Datensätze nachvollziehen können,
ist es auch möglich, damit ein Undo zu machen, wenn man weiss, das zu irgendeinem Zeitpunkt
eine Connection gegeben hat, ggf auch nur eine Transaction, deren Operationen rückgängig
gemacht werden sollen. Das Rückgängig machen ist dann der Aufruf einer Stored Proced
mit Parameter für Connection und Optional Transaction ID.
Alle Logs werden jahreweise in eigene Datenbanken gepackt und danach sind die Read Only und müssen
nicht mehr gesichert werden, weil sich nie wieder was ändern kann. Ganz nebenbei hat man
auf dem Wege ein sehr überzeugendes Audit System und falls durch Prüfungen irgendwelche Zweifel
an der Datenqualität aufkommen, findet man mit
IP Adresse und Zeitpunkt und ggf Firebird
User sofort den schuldigen und wenn hilfreich, auch den Prozess, der dafür zuständig war.
Die Log DBs sind zusammen mittlerweile ca 700 GB, aber da ist auch der Speed ziemlich egal, weil
man nur selten da dran muss, aber den Vorteil hat, das die nicht auf dem selben Server
gelagert werden müssen, geschweige denn wie bei Changeviews sogar in der selben Datenbank.
Das ist alles wesentlich weniger kompliziert als man denkt und wir haben das auch schon für
mehrere Kunden in deren Firebird Datenbank eingebaut. Bei Interbase geht das nicht, weil
alleine so wichtige Operation wie "execute statement ... on external" nicht existieren
und vieles mehr da eben fehlt.
Wenn Ihr also mit Enterprise Datenmengen zu tun habt, dann vorsichtig sein. Jeder, der mal
eine 500GB Datenbank (egal ob interbase oder Firebird) auf einer lahmen VM auf für Datenbanken
ungeeignete Hardware durch einen Backup Restore schicken musste, weiss, das Nächte dafür
manchmal deutlich zu kurz sind. Da dann auf irgendwelche Brückentags/Feiertagskombinationen
warten zu müssen ist auch keine echte Strategie. Das 500GB auf einem für
FB geeigneten Server
auch locker innerhalb von 1-2 Stunden duch einen Backup/Restore laufen können, ist mal nur ganz
am Rande erwähnt.