Langzeitarchivierung für relationale Datenbanken

Präsentation zum Thema: "Langzeitarchivierung für relationale Datenbanken"—  Präsentation transkript:

1 Langzeitarchivierung für relationale Datenbanken
Projektbericht Stefan Brandl, CSP GmbH & Co. KG

2 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

3 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

4 Wieso archivieren Sie? Optimierung der Performanz
Einleitung Wieso archivieren Sie? Optimierung der Performanz Reduzierung des Speicherplatzbedarfs Reduzierung der Kosten Rechtliche Vorgaben (GDPdU, GoBS, Basel II) Vorgaben durch Zertifikate Interne Qualitätsansprüche Beobachtung: Großteil der Daten in rel DBMS wird eigentlich nicht benötigt,…  Niemand traut sich, Daten aus der Datenbank zu löschen: Man könnte sie ja noch mal gebrauchen. Diese unnötig große Datenmenge muss aber durch Hardware und Organisation der Datenbanken online gehalten werden: Unnötig viel Manpower, Speicherplatz, Rechenleistung wird benötigt (zus.: Aufwand für kurze Recoveryzeiten im Fehlerfall wird hoch!) Pluspunkte für Archivierung: s.o. (3 Punkte) Grund für Datenanstieg: Rechtliche Vorgaben: GDPdU: Grundsätze des Datenzugriffs und der Prüfbarkeit digitaler Unterlagen: seit Jan 2002, steuerrelevante Daten, bis zu 10 Jahre GoBS: Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme Basel II: Infos mit Relevanz für die Kreditvergabe müssen revisionssicher abgelegt sein, um gutes Rating zu erhalten Zertifikate, interne Qualitätsansprüche, Produkthaftung

5 Einleitung Archivierung Elektronische Archivierung steht für die unveränderbare, langzeitige Aufbewahrung elektronischer Information. Für die elektronische Archivierung werden in der Regel spezielle Archivsysteme eingesetzt.

6 Einleitung Archivierung Archivierung bezieht sich nicht nur auf gedruckte oder elektronische Dokumente, sondern zunehmend auch auf Daten, die strukturiert in relationalen DBMS gespeichert werden und zur Wiederverwendung langfristig aufzubewahren sind. Heutige DBMSe sehen Archivierung als Datensicherung und geben die Kontrolle über die archivierten Daten auf. Fazit: Archivierung von relationalen Daten wird immer wichtiger (Erweiterung des Begriffes) , relationale Daten werden bei der Archivierung aus der Datenbank entnommen, A. Herbst in: Anwendungsorientiertes DB-Archivieren

7 Archivierung vs. Backup
Einleitung Archivierung vs. Backup Archivierung Backup Aktualität der Daten Veränderbarkeit Daten Schnelles Wiederherstellen Langfristige Aufbewahrung Performancesteigerung Löschen der Daten Quelle: Schaarschmidt, Seite 33 oben

8 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

9 Performance Zeit Herausforderungen
Verlauf verschiedener Datenbankparameter ( Speicherplatz und Performance ) falls keine Archivierung betrieben wird Speicherplatz (DB) Zeit

10 Oracle Tools für Backup und Recovery
Herausforderungen Oracle Tools für Backup und Recovery ≠ Archivierung! Online - / Offline – Sicherung Export / Import, Oracle Data Pump RMAN Datenbankinterne Archivierung Oracle bietet integrierte Möglichkeiten… Online / Offline: kopieren der Datenbankdateien (Tablespace- und Systemdateien) Online: Konsistenz wird durch kopieren der RedoLog-Dateien gewährleistet Offline: Konsistenz durch Herunterfahren der DB Export: Extrahieren der Daten auf Schema- oder Tabellenebene Data Pump: serverbasierte Lösung (erhöhte Geschwindigkeit, abgebrochene Jobs können fortgesetzt werden, bessere Bestimmung des Exportumfangs) RMAN: auf DB-Recovery ausgerichtetes Werkzeug Protokollierung von Änderungen in der DB auf Blockebene Datenbankinterne Archivierung: Umlagern von Daten vom prod. Tablespace in Archivtablespace: PL/SQL Routinen

11 Nachteile Keine Bestimmung des Archivumfangs möglich
Herausforderungen Nachteile Keine Bestimmung des Archivumfangs möglich Proprietäres Format des Archives Reimport bei Strukturänderungen Teilweiser Reimport Bei all diesen Möglichkeiten, die in einer Oracle Datenbank vorhanden sind, existieren Nachteile, die diese Lösungen als Archivierungslösung ausscheiden lassen, da sie die vorher genannten Wunscheigenschaften nicht erfüllen: Keine Bestimmung des Archivumfangs möglich (Online - /Offline Sicherung, Export Sicherung). Es kann nur der gesamte User exportiert werden, oder bei der Export Sicherung können einzelne Tabellen ausgewählt werden, aber niemals nur ein Teil der Tabellen. Die erzeugten Archive können ohne die erstellende Software nicht mehr gelesen werden. Man macht sich von einem Hersteller abhängig. Falls dieser vom Markt verschwindet, sind die Archive de facto unlesbar. Ein Reimport bei Veränderungen in der Struktur des Datenbankschemas ist nicht möglich. Hier muss in einen neuen Datenbankuser importiert werden. Ein Reimport von Ausschnitten der Archive ist ebenfalls nicht möglich. Archive können nur komplett in die Datenbank zurückgespielt werden. Noch nicht erwähnte aber oben vorgestellte Verfahren: Datenbankinterne Archivierung  verlagert nur die entstehenden Performanceprobleme  Alle hier vorgestellten Tools sind auf Backup und Recovery ausgelegt, wo es um Zeiträume geht, in denen es unwahrscheinlich ist, dass das Datenbanksystem nicht mehr am Markt existiert. Hier ist es wichtig nach einem Ausfall von Hard- oder Software schnellstmöglich wieder einen aktuellen Stand zu erhalten.

12 Was erwarten Sie von einer Archivierungslösung?
Herausforderungen Was erwarten Sie von einer Archivierungslösung? Flexible und komfortable Beschreibung der zu archivierenden Daten Offenes Archivformat Beschreibung der Archivdaten z.B. Datentypen, relationale Abhängigkeiten Komprimierung der Archivdaten In den vorausgegangenen Folien wurden die Möglichkeiten vorgestellt, wie man mit den Tools einer Oracle Datenbank, Daten sichern kann. Im Folgenden soll diskutiert werden, inwiefern diese Möglichkeiten die Erwartungen, die an eine Archivierungslösung gestellt werden, erfüllen können. Zuerst wollen wir uns überlegen, was eine Archivierungslösung für relationale Datenbanken bieten soll: Der Umfang des Archivs, das heißt die Daten, die archiviert werden, müssen eingegrenzt werden können, um Redundanzen im Archiv zu vermeiden. Falls zum Beispiel wöchentlich ein Archiv erstellt werden soll, die archivierten Daten aber wegen des schnelleren Zugriffs noch in der Datenbank benötigt werden, dürfen die bereits archivierten Daten im nächsten Archiv nicht noch mal mit archiviert werden, da so die Archive unnötig anwachsen. Die geschriebenen Archive sollten ohne weitere Software lesbar sein, um Abhängigkeiten von Herstellern zu vermeiden. Falls die Archive in einem proprietären Format geschrieben werden kann bei einem Archiv, welches über viele Jahre (also mehr als 10!) Bestand haben soll, der Hersteller vom Markt verschwinden oder das Produkt nicht mehr supported und weitergeführt werden, was de facto zum Verlust der Archivdaten führt. Hier bietet sich ASCII als Standard an. Darüber hinaus sollte über die relationalen Daten im Archiv eine Beschreibung vorliegen, um zum einen die programmatische Rekonstruktion der Daten und relationalen Abhängigkeiten zu ermöglichen, zum Anderen, um bei manueller Betrachtung der Daten diese den richtigen Spalten zuordnen zu können. Auch für diesen Teil der Archive sollte natürlich ein standardisiertes und offenes Format gewählt werden. Um Speicherplatz zu sparen sollten die Archivdateien komprimiert abgelegt werden. Auch hier ist die Verwendung eines verbreiteten Algorithmus anzuraten. Diese Eigenschaften sind für die Archive selbst wünschenswert. Um den Vorgang des Rearchivierens auch nach vielen Jahren noch zu ermöglichen, müssen diverse andere Gegebenheiten berücksichtigt werden.

13 Was erwarten Sie von einer Archivierungslösung?
Herausforderungen Was erwarten Sie von einer Archivierungslösung? Auswahl der Daten bei Rearchivierung Nachverfolgung von Schemaänderungen über einen längeren Archivierungszeitraum Abbildung der Datentypen für Migrationsmöglichkeit über mehrere Oracle Versionen hinweg Indizierung der Archivdaten Um zu ermöglichen , dass auch Teilausschnitte des gesamten Archivs rekonstruiert werden können, muss eine Auswahlmöglichkeit für die Rearchivierung bestehen. Diese kann über eine Zeitraumangabe erfolgen (also zum Beispiel: rearchivieren des Monats Juli 2004), über eine Angabe eines Suchprädikats (Nation = ‚Austria‘) oder eine Kombination von beiden (alle Lieferungen nach Österreich im Jahr 2004) Des Weiteren sollte es auch möglich sein, Archive mit unterschiedlichen Schemabeschreibungen zu rearchivieren. Falls eine Spalte im Datenbankschema hinzukommt oder gelöscht wird, eine Spalte auf zwei Spalten aufgeteilt wird oder umgekehrt eine Spalte aus zwei Spalten zusammengeführt wird, sollten die Archive über diese Änderungsgrenzen hinweg, miteinander verarbeitet und auch wieder rearchiviert werden. Es soll auch funktionieren, wenn alte Daten mit einem Schema, das in der aktuellen Datenbank so nicht mehr existiert in diese Datenbank wieder rearchiviert werden sollen. Das selbe gilt für alte Archive, die mit einer alten Datenbankversion archiviert wurden. Hier kann es sein, dass Datentypen entweder in der aktuellen Datenbankversion nicht mehr existieren oder sich im Schema geändert haben. Somit muss entweder ein neuer möglicher Datentyp aus der zu importierenden Datenbank gefunden werden, oder falls das Schema in das importiert werden soll schon existiert, muss die Kompatitibilität der Datentypen im Archiv und der Datentypen im Datenbankschema sichergestellt sein. Das heißt, jeder Wert im Archiv muss in den Datentyp, der im aktuellen Schema in der Datenbank existiert, importiert werden können. Um bei Rearchivierungen mit Suchprädikaten einen effizienten Suchvorgang zu gewährleisten, müssen die Archive indiziert werden. Dies kann implizit über eine Aufteilung der Archivstruktur nach Jahren und Monaten erfolgen und explizit über Indexstrukturen, die die einzelnen Daten der Archive beschreiben.

14 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

15 Speicherplatz (Archivierung)
Lösung Performance Wie bereits Anfangs gesehen, wachsen bei einer typischen Datenbankanwendung die zu speichernden Daten stetig an, meistens sogar exponentiell. Werden keine Investitionen in Hardware vorgenommen, sinkt damit die Performance in ungefähr gleichem Verhältnis…. Setzt man nun eine Archivierungslösung ein, können schrittweise nicht mehr häufig benötigte Daten archiviert werden und anschließend aus der Produktivdatenbank gelöscht werden. So wächst auch die Performance wieder, da die zu verwaltende Datenmenge kleiner wird. Der Speicherplatzbedarf für die Archive ist dabei um ein vielfaches geringer, als der Bedarf für die Vorhaltung der Daten in der Datenbank. Beispielrechnung: 20 MB Archivdatei  300 MB Nutzdaten  1,2 GB Tablespace (TODO: Nachschauen, wie groß der Export von der ipmv3 messung war) Zusätzlich muss noch berechnet werden, dass Tablespace Dateien auf schnellen und teuren Serverplatten liegen sollten, während die Archive auf billigen Medien, wie DVDs oder zukünftigen Blu Ray Disc o.ä. gesichert werden können. Speicherplatz (Archivierung) Speicherplatz (DB) Zeit

16 Einordnung Online-/Offline-Sicherung Export/Import bzw. DataPump
Lösung Einordnung Online-/Offline-Sicherung Export/Import bzw. DataPump RMAN … Die vorgestellten Oracle Tools zielen auf die Sicherung von Daten ab, die sich im täglichen Zugriff befinden und im Fehlerfall schnell wieder hergestellt sein müssen. Eine Archivlösung greift an anderer Stelle an: hier werden Daten behandelt, die nicht mehr im täglichen Zugriff liegen und auch nicht mehr verändert werden. Dies sind meist Daten, die aus Produkthaftungsgründen oder steuerrechtlichen Gründen abgelegt wurden, und viele Jahre aufbewahrt werden müssen. Diese großen Datenmengen behindern bei einem Verlust der Datenbank die schnelle Wiederherstellung durch die vorgestellten Recovery Mechanismen. Die mit einer Archivierungslösung archivierten Daten können nach einer Überprüfung aus der Produktivdatenbank gelöscht werden und so den Vorgang der Recovery beschleunigen. Generell wird natürlich der gesamte Betrieb der Datenbank performanter und die Kosten für den Betrieb sinken. Dies führt zu folgender Grafik, die den Verlauf des benötigten Speicherplatzes und der Performanz darstellt… Altdaten (nicht mehr im täglichen Zugriff) Produktivdaten (im täglichen Zugriff) Zeit

17 Beispiel TPC – Schema Order Lineitem Customer Nation Lösung Totalprice
Status Orderkey Orderdate Order Custkey Quantity Custkey Orderkey Lineitem Customer Name TPC (Transaction Processing Performing Council) führt unabhängige Datenbankbenchmarks durch. Schema öffentlich zugänglich: allgemein anerkanntes Schema Kleiner Ausschnitt aus dem ganzen Schema: Warenhaus mit Bestellungen (Order), mehreren Lineitems pro Order und je Order ein Customer, wobei ein Customer natürlich mehrere Bestellungen tätigen kann. Jeder Kunde ist einem Land (Nation) zugeordnet, um länderspezifische Auswertungen durchführen zu können. Für sinnvolle Archivierung muss eine zeitliche Beschränkung der Daten erfolgen: Bestelldatum In Chronos: Angabe eines SQL-Statements mit Zeitangabe Linenumber Address Price Nationkey Nationkey Status Nation Name

18 Archivierung – ein Beispiel
Lösung Archivierung – ein Beispiel Lineitem Orderkey Linenumber Price Quantity Status 1 23,25 O 2 5,45 5 F 270,00 3 56,14 7 411,50 4 86,1 15 97,4 Order Orderkey Totalprice Status Orderdate Custkey 1 50,50 O 43 2 810,00 F 3 1215,98 4 1291,50 5 292,20 32 Nation Nationkey Name 1 Deutschland 2 USA Customer Custkey Name Address Nationkey 1 Ullrich Musterstraße 5 2 Armstrong th 3 Virenque Rue de la roi 3 5 Gültige Ausprägung eines tpc Schemas: blau markierte Datensätze gehören zu einem konsistenten Datenbestand und müssen in einem Archivpaket enthalten sein. Nur so kann bei Rearchivierung ein konsistenter Datenstand hergestellt werden

19 Aufteilung der Daten im Archiv
Lösung Aufteilung der Daten im Archiv Lineitem Orderkey Linenumber Price Quantity Status 2 1 270,00 3 F 56,14 7 O 411,50 Order Orderkey Totalprice Status Orderdate Custkey 2 810,00 F 3 1215,98 O Customer Custkey Name Address Nationkey 2 Armstrong th Nation Nationkey Name 2 USA

20 Das Archiv von CHRONOS Archiving
Lösung Das Archiv von CHRONOS Archiving Zeitlich aufgeteilte Verzeichnisstruktur, Oberste Hierarchie ist das Jahr, zweite Hierarchiestufe das Monat, in diesem Vrz werden alle Archive, die in diesem Monat exportiert wurden, abgelegt. Große Datenvolumen sind so kein Problem Pro exportierter Tabelle wird eine Archivdatei angelegt, die mit einer Datumskennung versehen wird  Daten auch menschlich lesbar Archivdaten: Textformat, Spalten mit beliebigen Separator getrennt. Textdateien werden gezippt: um 90 % Komprimierung + Sicherheit, dass zip noch lange exisitiert Metadaten: parallel dazu in XML Dateien: Grund einfache programmatische Verarbeitung (siehe später) + menschlich lesbar, da es auf Textformat basiert

21 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

22 Archiv Java Applikation Index- Struktur Web- Export- Client Server
Architektur Java Applikation Datenbank Administration und Datenzugriff Index- Struktur Web- Client Export- Server Datenzugriff Import- Server Search- Engine Web-/Applikations- Server Verschiedene Server für die versch. Funktionalitäten: können beliebig auf Rechner verteilt werden  gut Skalierbar ClientSeite: Java Applikation zur Administration, Web Clients zur Suche auf den Archiven ExportServer: schreiben der Archive und Metadaten, Erstellen der Indizes, markieren der exportierten Daten  löschen möglich!, Erkennen von Änderungen im Schema ImportServer: einlesen der Daten aus Archiven, kann Daten unabhängig von der export-DB importieren, Datenfluß: entweder Import oder Anzeige der Daten am Client, zus: Überprüfung des Schemas, in das importiert werden soll: Datentyp Mapping! SearchEngine: Suche über Indexstruktur, + Daten können dem ImportServer weitergegeben werden (relevant, falls sich Daten auf DVD Jukeboxen befinden) Skalierbarkeit, Betriebssystemunabhängigkeit der Server Web- Client Archiv Datenzugriff

23 Übersicht Einleitung Herausforderungen Lösung Architektur Lebenszyklus

24 Zeit Schemaänderung Lebenszyklus
Daten können über die Schemaänderungsgrenzen hinweg durchsucht und reimportiert werden! Zeit

25 Strukturelle Veränderung
Lebenszyklus Strukturelle Veränderung Nation Nationkey Name 1 Deutschland 2 USA Nation Nationkey Name Kommentar 1 Deutschland 2 USA

26 Semantische Veränderung
Lebenszyklus Semantische Veränderung Customer Custkey Name Address Nationkey Category 1 Ullrich Musterstraße 5 D 2 Armstrong th A 3 Virenque Rue de la roi 3 5 B Customer Custkey Name Address Nationkey Category 1 Ullrich Musterstraße 5 IV 2 Armstrong th I 3 Virenque Rue de la roi 3 5 II

27 Zeit Applikation V1 Applikation V2 Lebenszyklus Datenbank Schema V2

28 Praxisbeispiel Einsatz zum Archivieren von großen Datenmengen, z.B. im produzierenden Gewerbe Datenmenge: 2,5 Mio Datensätze pro Tag  600 MB Nutzdaten Archivgröße: 40 MB pro Tag Benötigter Tablespace: > 1 GB pro Tag!

29 Internet: www.csp-sw.de
Vielen Dank für Ihre Aufmerksamkeit! Stefan Brandl CSP GmbH & Co. KG Herrenäckerstraße 11 94431 Großköllnbach Internet: