Archivierung in Datenbanksystemen

Datenbanksysteme sind dafür geschaffen worden,um große Datenmengen adäquat behandeln zu können, d.h. diese Datenmengen strukturiert abzulegen sowie Such- und Änderungsdienste darauf bereitzustellen. Die heutigen relationalen Datenbanksysteme sind auch weitestgehend dazu in der Lage, die in sie gesetzten Erwartungen zu erfüllen. Probleme treten jedoch in der Praxis in vielen Fällen dann auf, wenn die Datenmengen wirklich sehr groß werden (etwa im Bereich vieler Hundert Gigabyte oder im Terabyte-Bereich): Es wird immer mehr Sekundärspeicher (Platten) benötigt, der "online" gehalten werden muß; die Zugriffszeiten zu den Daten wachsen an, da auch bei effektiver Speicherorganisation und Zugriffspfadnutzung ein größer werdender Datenbestand bzgl. der Performance nicht völlig neutralisiert werden kann; die Backup- und Recovery-Zeiten nehmen zu; gewisse Schwellwerte des Datenbank-Management-Systems (DBMS), wie z.B. Maximalgröße von Tabellenbereichen, werden erreicht und drohen,einen DBMS-Stillstand zu verursachen bzw. erfordern massives Eingreifen durch den Datenbankadministrator (DBA); die Übersichtlichkeit des Datenbestands leidet, da oftmals aktive und inaktive, weitgehend veraltete Daten vermischt im Datenbestand auftreten etc.

Die Probleme verschärfen sich dadurch weiter, daß gerade in jüngerer Zeit bzgl. der Datenhaltung Entwicklungstendenzen und Anwenderwünsche zu beobachten sind, die auf den ersten Blick nur schwer miteinander vereinbar erscheinen: Auf der einen Seite werden die Datenbestände typischerweise immer größer (so wird bereits von Datenbeständen im praktischen Einsatz berichtet, bei denen einzelne Tabellen -zig Milliarden Zeilen aufweisen), auf der anderen Seite werden gleichzeitig immer höhere Verfügbarkeitsanforderungen gestellt in Richtung auf einen 24-Stunden-Betrieb an 365 Tagen im Jahr. Es liegt auf der Hand, daß beispielsweise klassische Verfahren der Datensicherung oder Datenreorganisation hier nicht mehr angemessen sind, wenn sie mit sehr großen Datenmengen umgehen sollen und gleichzeitig den OLTP-Betrieb (Online Transaction Processing) nicht wesentlich behindern dürfen; auch neue Verfahren schaffen nur begrenzt Abhilfe in Anbetracht des "Datenwusts".

Letztendlich gibt es aus praktischer Sicht zwei Möglichkeiten, auf die beschriebene Situation zu reagieren: Es wird versucht, durch Datenlöschungen das Anwachsen der Datenmengen zum Stillstand zu bringen oder wenigstens zu bremsen, oder es erfolgt eine Datenarchivierung aus der Datenbank heraus auf geeignete andere Speichermedien. Datenlöschungen sind oftmals nicht möglich oder im geforderten Umfang nicht erwünscht, da betriebswirtschaftliche oder rechtliche Gründe dagegensprechen (Wiederbenutzung (auch) der alten Daten für betriebliche Zwecke nicht auszuschließen, Daten werden für Revisionszwecke und aufgrund gesetzlicher Regelungen doch noch gelegentlich nachgefragt u. dgl. mehr). Da das Weiteranwachsen der Datenmengen auch keine Lösung darstellt, bleibt die Datenarchivierung somit als erwägenswerte Alternative.

Im einfachsten Fall kann Archivieren bedeuten, daß solche Datenbankinhalte, die aktuell nicht (mehr) oder nur noch sehr selten gebraucht werden,entladen werden auf geeignete (Tertiärspeicher-) Medien; diese werden dann "in den Schrank" gestellt, bis man die auf ihnen abgelegten Daten eventuell wieder einmal benötigt.

Das Lesen der archivierten Daten und ein mögliches Wiedereinladen in die Datenbank werden manuell angestoßen und zeigen schon die Schwerfälligkeit dieses Vorgehens, das jedoch in der Praxis weit verbreitet ist. Auch bekannte Anwendungssysteme,wie das System R/3 von SAP, verfolgen heute eine Archivierungslösung, die nicht sehr weit von jenem einfachen Vorgehen entfernt liegt. Man spricht hier auch von datenbanksystembasierter Archivierung, denn die zu archivierenden Daten werden mittels einer Anwendungsschicht aus der Datenbank herausgeholt und in ein separates Archiv übertragen, das sich nicht unter Kontrolle des Datenbanksystems befindet. Dabei wird eine Verschiebesemantik verfolgt, die zu archivierenden Daten werden also ins Archiv bewegt und verbleiben nicht in der Datenbank, sondern werden dort gelöscht. Obwohl hier zusätzliche unterstützende Dienste denkbar sind (bspw. zur Verwaltung und zum Zurückladen archivierter Daten), besitzt diese nur sehr lose Anbindung von Datenbank und Archiv offensichtliche Nachteile, wenn man etwa an Forderungen denkt wie eine übergreifende Integritätsüberwachung zwischen Datenbank und Archiv, die Einbindung der Archivierung in Datenbanktransaktionen u. a.m. Ein Vorteil der datenbanksystembasierten Archivierung liegt in der vergleichsweise einfachen Realisierbarkeit, weil sie keine Eingriffe ins DBMS (funktionale Erweiterungen dort) erfordert.

Beispiele für praktisch eingesetzte Lösungen im Bereich der datenbanksystembasierten Archivierung sind das ADK (Archive Development Kit) des Systems R/3 und CERA (Climate and Environmental Data Retrieval and Archiving System) vom Deutschen Klimarechenzentrum. Das ADK ermöglicht die Entwicklung von Archivierungsprogrammen für die R/3-Anwendungen. Beim Archivieren werden Daten der Datenbank in Archivdateien geschrieben und anschließend aus der Datenbank gelöscht. Die Archivdateien befinden sich zunächst auf Magnetplatte, können aber auf Tertiärspeichermedien verschoben werden. CERA basiert auf Oracle und realisiert die Migration von Tabellenbereichen auf Bänder. Ausgenutzt wird hierbei die Möglichkeit, Tabellenbereiche in Oracle „offline" zu setzen und auf Tertiärspeicher auszulagern, bis eine spätere Nutzung eine Wiedereinlagerung erforderlich macht.

Der datenbanksystembasierten steht die datenbanksystemintegrierte Archivierung gegenüber. Dort bietet das DBMS integriert selbst Archivierungsdienste an, d.h. es kennt und kontrolliert auch das Archiv und bietet damit Möglichkeiten, die sonst der (zu) losen Anbindung zwischen Datenbank und Archiv wegen nicht ohne weiteres realisierbar wären. Idealerweise werden hier die Archivierungsdienste in Form von erweitertem SQL angeboten, um auf diesem Wege etwa die Archivierung von Daten zu veranlassen, im Archiv zu lesen oder Daten aus dem Archiv in die Datenbank zurückzuholen.

In den heutigen (relationalen) Datenbanksystemen ist solche Funktionalität jedoch noch nicht vorhanden; eine Möglichkeit, sich dem Idealzustand jedoch wenigstens anzunähern, liegt in einer Nachbildung des integrierten durch einen basierten Ansatz.

Eine wichtige Forderung bei der Bereitstellung von Archivierungsfunktionalität ist die Anwendungsorientierung. Anwendungsorientiertes Archivieren läßt sich durch vier Eigenschaften charakterisieren:

• Benutzerveranlassung, d.h. das Archivieren geschieht nicht primär implizit durch das DBMS veranlaßt, sondern explizit durch den Benutzer oder DBA.
• Abstraktionsebene Datenmodell, d.h. es werden solche Granulate beim Archivieren angesprochen, die dem Benutzer/DBA auf der Ebene des Datenmodells bekannt sind (relational also etwa Tabellen oder Tupel, nicht aber bspw. Tabellenbereiche oder Dateien).
• Datenauslagerung im Sinne der zuvor bereits erwähnten Verschiebesemantik, also Überführen von Daten ins Archiv und nicht einfaches Kopieren.
• Archivzugriff schließlich, wofür Funktionalität gebraucht wird zum Lesen auf dem Archiv und ggf. auch zur Rückübertragung von Daten aus dem Archiv in die Datenbank.

Diese Forderung nach Anwendungsorientierung grenzt gleichzeitig ab zu anderen DBMS-Funktionalitäten, wo speziell in der Praxis manchmal auch von Archivieren gesprochen wird: Das Erstellen einer Sicherungskopie einer Datenbank (Backup) hat z.B. nichts mit (anwendungsorientiertem) Archivieren zu tun, denn u. A. wird hier nicht ausgelagert, sondern es werden Daten kopiert, und der Archivzugriff auf selektive Weise ist hier auch nicht möglich, es wird auch eine ganz andere Intention dabei verfolgt als beim Archivieren im Verständnis dieses Beitrags.

Wichtig fürs Archivieren ist die Möglichkeit zur Nutzung von Tertiärspeichermedien. Sekundärspeichermedien (i.w. Magnetplatten) werden zwar seit Jahren auch stets preiswerter und bieten immer höhere Kapazitäten, aber bei Datenbankgrößen im Terabyte-Bereich - und künftig auch darüber hinausgehend - spielt der Kostenfaktor dann doch auch heute und in Zukunft eine signifikante Rolle. Tertiärspeichernutzung für Archive bedeutet nach heutigen Technologien i.w. die Verwendung von Magnetbändern (und Bandrobotern) sowie von optischen Platten. Tertiärspeicher kann dabei auf verschiedene Weise ins DBMS eingebunden bzw. ans DBMS angebunden werden. Kommerziell verbreitet sind heute bereits die sog. HSM-Systeme (Hierarchical Storage Manager),wo Tertiärspeicher in einer Speicherhierarchie hinter dem Sekundärspeicher angeordnet wird und typischerweise ganze Dateien je nach Bedarf zwischen dem Sekundär- und dem Tertiärspeicher ausgetauscht werden. Dieser Austausch erfolgt aus Sicht der Anwendung, und damit auch des DBMS, transparent, d.h. es ist "lediglich" anhand der Performance zu verspüren, ob zugegriffene Daten bereits auf Sekundärspeicher waren oder ob sie erst vom Tertiär- auf den Sekundärspeicher geladen werden mußten. Für anwendungsorientiertes Archivieren eignet sich dieses Vorgehen somit nicht unmittelbar, da dort Benutzerveranlassung des Archivierens gefordert wird und auch eine sichtbare, physische Trennung zwischen Datenbank und Archiv. Lösungen,die sich hier für die Archivierung anbieten, liegen also außerhalb der HSM-Systeme; der Tertiärspeicher muß explizit angesprochen werden können übers DBMS (bei datenbanksystemintegriertem Archivieren) oder die zuständige Anwendungsschicht (bei datenbanksystem-basiertem Archivieren).

In Zusammenhang mit dem Archivieren in Datenbanksystemen ergibt sich eine Fülle von Aufgabenstellungen und Problemen, wobei grob gesagt werden kann, daß gute Lösungen eher absehbar sind beim datenbanksystemintegrierten als beim -basierten Ansatz. Ein Problembereich wurde schon erwähnt: Die Auswirkungen des Vorhandenseins eines Archivs auf die Integritätssicherung, d.h. wie bspw. übergreifende Integritätsbedingungen zwischen Datenbank und Archiv definiert und unterstützt werden können,wie auch im Fehlerfall sichergestellt werden kann, daß Datenmengen nicht "halbarchiviert" verbleiben usw. Ein weiterer Problembereich hängt mit der (in der Praxis alltäglichen) Evolution des Datenbankschemas zusammen: Das Datenbankschema ändert sich, und die Frage ist zu klären, was entsprechend mit dem Archivschema geschieht. Auch die Art der Tertiärspeichernutzung und mögliche -integration kann als Problembereich gesehen werden,denn heutige DBMS-Produkte bieten noch keine volle Integration hier an (Tertiärspeicher wirklich als "first class citizen"). Die Praxis zeigt jedoch, daß vielerorts schon Archivierungslösungen entwickelt wurden und entwickelt werden, i.d.R. bisher mittels eines datenbanksystembasierten Ansatzes. D.h., obwohl die Datenbank-Management-Systeme immer bessere Lösungen auch zum Umgang mit sehr großen Datenmengen anbieten und obwohl Sekundärspeicher immer billiger wird und immer größere Kapazität aufweist, bieten die rapide anwachsenden Datenmengen offenbar genügend Veranlassung, auch weiterhin verstärkt über Archivierung nachzudenken und Lösungen zu entwickeln.