CSP, Hersteller der Datenbankarchivierungslösung Chronos, hat jetzt die Einsatzbereiche des neuen Flashback Data Archives von Oracle gegen die der eigenen Archivierungslösung abgegrenzt. Die Unterschiede zwischen den Einsatzgebieten "Archivierung" und "Historisierung" sind immens: Die Datenbankarchivierung mit Chronos zielt vor allem auf die Senkung der Betriebskosten der Produktivdatenbank ab. Diese wird durch den Archivierungsvorgang dadurch entlastet, dass Daten, die nicht oder selten benötigt werden, auf günstigere Speichermedien geschrieben werden. Das Flashback Data Archive, bekannter unter dem Namen "Total Recall", bietet die Möglichkeit, jede Veränderung der Daten einer Tabelle zu historisieren. Ein Archivierungsvorgang wie bei Chronos wird dabei nicht unterstützt. Im Gegenteil: Durch die Historisierung wächst das Datenvolumen sogar noch an. Die Datenmanipulationen werden durchgängig aufgezeichnet und ebenfalls in der Datenbank abgelegt. Mit der Total-Recall-Funktion kann daher auf alle Datenbestände zurückgegriffen werden, die jemals in der entsprechenden Tabelle enthalten waren. Damit der Zustand der Datenbank für einen bestimmten Zeitpunkt abgebildet werden kann, werden alle Statements wie Insert, Update und Delete mit einem Zeitstempel markiert. "Wenn 'Total Recall' bei Tabellen aktiviert ist, die häufigen Datenänderungen unterliegen, erhöht sich der zusätzlich benötigte Speicherbedarf sehr rasch und die produktive Datenbank wird weiter belastet. Wir warnen deshalb davor, die Historisierung mit einer Archivierung gleichzusetzen", betont Stefan Brandl, Produktmanager Datenbankarchivierung von CSP.
Das Produkt Chronos von CSP ist speziell für die Datenbankarchivierung konzipiert. Es eignet sich zur Bereitstellung von strukturierten Daten über einen sehr langen Zeitraum. Unterstützt werden beliebige relationale Datenbanken, unabhängig vom Hersteller. Kostenseitig ist die Archivierung besonders interessant: Weil die produktive Datenbank nicht ins Uferlose wächst, sondern der Datenbestand regelmäßig minimiert wird, spart ein Unternehmen die Investitionen in immer performantere Hardware. Gleichzeitig arbeitet die Lösung konform zu Gesetzesvorgaben in Bezug auf Aufbewahrungsfristen, zum Beispiel für steuerlich relevante Daten. Damit die Daten stets wieder aufrufbar sind, werden beim Entfernen aus der Produktivdatenbank stets alle relationalen Abhängigkeiten beachtet. Dadurch können auch alte Daten zu einem späteren Zeitpunkt problemlos wieder eingespielt werden, auch wenn sich die Datenbankstrukturen zwischenzeitlich verändert haben.
Die Total-Recall-Funktion dagegen hat keine Archivierungsfunktionen und verhindert teilweise auch die Verwendung bereits vorhandener, Oracle-eigener Möglichkeiten, wie die Ausführung der meisten DDL-Statements und den Einsatz des ILM-Managers sowie Partitioning. Das Konzept der Foreign Keys kann nicht auf die Total-Recall-Funktion abgebildet werden, und auch der SQL-92-Standard wird für den Zugriff auf Altdaten nicht mehr unterstützt. Wird also zu einem späteren Zeitpunkt auf eine andere Datenbank migriert, müssen alle Anwendungen, die auf eine Total-Recall-Tabelle zugreifen, auf ihre Validität hin überprüft werden. Auch wer das Oracle-Konzept für Information-Lifecycle-Manangement umsetzen möchte, kann nicht auf "Total Recall" zurückgreifen, da einige dafür benötigte Oracle-eigene Funktionen nicht unterstützt werden.
"Die Begriffe Historisierung und Archivierung rufen ähnliche Assoziationen hervor: Im Falle der Datenbanken sind damit aber gänzlich unterschiedliche Vorgänge bezeichnet. Welche Lösung genutzt wird, ist damit völlig abhängig von den Anforderungen im jeweiligen Projekt", zieht Brandl ein Resümee.
Das Produkt Chronos von CSP ist speziell für die Datenbankarchivierung konzipiert. Es eignet sich zur Bereitstellung von strukturierten Daten über einen sehr langen Zeitraum. Unterstützt werden beliebige relationale Datenbanken, unabhängig vom Hersteller. Kostenseitig ist die Archivierung besonders interessant: Weil die produktive Datenbank nicht ins Uferlose wächst, sondern der Datenbestand regelmäßig minimiert wird, spart ein Unternehmen die Investitionen in immer performantere Hardware. Gleichzeitig arbeitet die Lösung konform zu Gesetzesvorgaben in Bezug auf Aufbewahrungsfristen, zum Beispiel für steuerlich relevante Daten. Damit die Daten stets wieder aufrufbar sind, werden beim Entfernen aus der Produktivdatenbank stets alle relationalen Abhängigkeiten beachtet. Dadurch können auch alte Daten zu einem späteren Zeitpunkt problemlos wieder eingespielt werden, auch wenn sich die Datenbankstrukturen zwischenzeitlich verändert haben.
Die Total-Recall-Funktion dagegen hat keine Archivierungsfunktionen und verhindert teilweise auch die Verwendung bereits vorhandener, Oracle-eigener Möglichkeiten, wie die Ausführung der meisten DDL-Statements und den Einsatz des ILM-Managers sowie Partitioning. Das Konzept der Foreign Keys kann nicht auf die Total-Recall-Funktion abgebildet werden, und auch der SQL-92-Standard wird für den Zugriff auf Altdaten nicht mehr unterstützt. Wird also zu einem späteren Zeitpunkt auf eine andere Datenbank migriert, müssen alle Anwendungen, die auf eine Total-Recall-Tabelle zugreifen, auf ihre Validität hin überprüft werden. Auch wer das Oracle-Konzept für Information-Lifecycle-Manangement umsetzen möchte, kann nicht auf "Total Recall" zurückgreifen, da einige dafür benötigte Oracle-eigene Funktionen nicht unterstützt werden.
"Die Begriffe Historisierung und Archivierung rufen ähnliche Assoziationen hervor: Im Falle der Datenbanken sind damit aber gänzlich unterschiedliche Vorgänge bezeichnet. Welche Lösung genutzt wird, ist damit völlig abhängig von den Anforderungen im jeweiligen Projekt", zieht Brandl ein Resümee.
