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 Suchund Ä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 Backupund RecoveryZeiten 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 [6]),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 [5].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 [5] und CERA (Climate and Environmental Data Retrieval and Archiving System) vom Deutschen Klimarechenzentrum [3].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 Aktuelles Schlagwort*