Unbegrenztes Wachstum ihrer Datenbanken:

Transkript

1 Unbegrenztes Wachstum ihrer Datenbanken: Ein unumkehrbarer Trend?

2 Datenwachstum Datenwachstum (von Objekten belegter Platz) DSS-System Order-System TB Datum

3 Konsequenzen und Maßnahmen Konsequenzen Bedarf an schnellen und teuren Plattenplatz steigt. Die Betriebs- und Investkosten für Festplattenplatz steigen Backup- und Recovery SLAs können mit den bestehenden Sicherungssystemen nicht eingehalten werden Backup- und Restore-Laufzeiten werden größer Die Verfügbarkeit der Anwendung sinkt Mögliche Maßnahmen Bereitstellung von Festplattenplatz. Daten werden entfernt (oder komprimiert) Aufbau neuer leistungsfähigerer und teurerer Sicherungssysteme (z.b. BCV-Backup mit RMAN- Proxy-Copy) Daten werden entfernt (oder komprimiert) Die immer größer werdenden Sicherungsvolumina treiben die Betriebskosten für die Bandsicherung in die Höhe Daten werden entfernt

4 Probleme und Maßnahmen Konsequenzen Mögliche Maßnahmen Die Wartbarkeit der Datenbank und Anwendung sinkt und es besteht die Gefahr, dass die Datenqualität abnimmt Lange Laufzeiten bei Datenbank Deployments (Längere Wartungsfenster werden nötig) Lange Laufzeiten bei Reorganisationsmaßnahmen in der Datenbank Daten werden entfernt Lange Laufzeiten bei Migrationen, die eine Neuorganisation der Daten mit sich bringen. Die Verfügbarkeit der Anwendung sinkt

5 Möglichkeiten zur Lösung der Probleme Daten werden gelöscht Besteht aus fachlichen und/oder rechtlichen Gründen keine Möglichkeit die Daten zu löschen, gibt es folgende Möglichkeiten: Daten in der Datenbank komprimieren Daten werden archiviert

6 Datenkompression (9i R2) INSERT UPDATE. HIS_TAB HIS_TAB Komprimierte HIS_TABELLEN und HIS_INDIZES Trigger HIS_VIEW SELECT from HIS_VIEW

7 Datenkompression (9i R2) Effekt der Tabellen- und Indexkompression: ca GB => 380 GB ~ Faktor 1/ TB Datum

8 Ergebnisse der Tabellenkompression Tabellenkompression ist ein Mittel um das Wachstum zu reduzieren und zu verzögern, wenn nicht Lob-Segmente für das starke Wachstum verantwortlich sind. Bis 10g R 2 müssen die Daten regelmäßig im Wartungsfenster komprimiert werden, da nur Daten komprimiert werden, die im Direct-Path Modus geschrieben werden. Die Auswirkungen auf die Anwendung müssen gut getestet werden (insb. Update-Statements). Nicht alle Probleme können durch Datenkompression gelöst werden.

9 Fazit Da wir eine nachhaltigere und allgemeingültigere Lösung anstreben, haben wir uns dafür entschieden, eine Datenbankarchivierungslösung aufzubauen

10 Fachliche Anforderungen Die archivierten Daten müssen ohne Informationen aus dem Live-System interpretierbar sein Die Weiterentwicklung der aktuellen Anwendung und Datenstruktur muss unabhängig von den archivierten Daten sein. Auswertungen auf zurückgespielten Archiven müssen möglich sein Archive müssen nach einem bestimmten Zeitraum gelöscht werden können Die Archive müssen revisionssicher abgelegt sein und die gesamte Archivierungslösung muss den rechtlichen Anforderungen genügen (GoBS( und GDPdU) Auf archivierte Daten dürfen nur bestimmte Personen zugreifen (Sicherheitskonzept) Ein ROI muss innerhalb von drei Jahren gegeben sein

11 Technische Anforderungen Daten müssen langfristig lesbar sein: Archive müssen auch nach einem Wechsel der darunter liegenden Hardware zu verarbeiten sein Archive müssen auch bei einem Wechsel der Datenbanksoftware zu verarbeiten sein Die Archivierung soll automatisiert erfolgen Größtmögliche Abdeckung aller bei uns betriebener Datenbanksysteme Aus den archivierten Daten muss sich jederzeit das korrespondierende Schema wiederherstellen lassen. Die Archive müssen ohne dass sie in die Datenbank zurückgespielt werden müssen auszuwerten sein. Daten müssen in Archiven schnell lokalisiert werden können (Indizes auf archivierte Daten) Es muss alle gängigen Archivierungssysteme unterstützen (WORM/CAS/Band) Alle verwendeten Datentypen müssen archivierbar sein

12 Datenbank-Archivierungswerkzeuge Derzeit sind mir nur zwei kommerziell erwerbbare Archivierungswerkzeuge für Datenbanken außerhalb des SAP- Umfeldes bekannt: OPTIM (Heute IBM, vormals PrincetonSoftech) Chronos (CSP GmbH & Co. KG / Entwicklungszusammenarbeit mit der Universität Landshut)

13 Übersicht über die Architektur Chronos WEB-Browser OPTIM Thick-Client auf XP Applikations- Server (Rep.) Repository DB Chronos Server Export Import OPTIM Server Archiv Restore Indizes Search Indizes Browse DB Archiv DB Archiv

14 Vergleichbare Merkmale Sicherheitskonzept bis auf Spaltenebene hinunter, existiert. Sicherheitskonzept separiert die Archivdaten verschiedener Anwendungen. Auswertung auf Archivdateien ist möglich Index basierte Suche in Archivdateien ist möglich Datenbankstruktur wird mitgesichert und ist wiederherstellbar Anwendungsentwicklung kann von der Archivierung entkoppelt werden Unterstütze Datenbanken: Oracle, DB2/Unix und MS- SQL

15 Unterschiedliche Merkmale OPTIM Lizenzkosten hoch Datenbankunterstützung für DB2 auf Z/OS und Sybase Unterstützung für Content Addressed Storage (z.b. EMC- Centera), Band und WORM Die Archivierung mit OPTIM kann in folgende Standardanwendungen integriert werden: - Amdocs CRM (Clarify) - Siebel - Oracle E-Business Suite - JD Edwards EnterpriseOne - People Soft Proprietäres Archivdateiformat Lizenzkosten niedrig - (?) Chronos Unterstützung für CAS wird aktuell entwickelt. Derzeit wird Band und WORM unterstützt Einbindung der Archivierung in Anwendungen ist über Web- Services vorgesehen. Offenes Archivdateiformat

16 POF DB-Archivierung mit OPTIM Funktionale Tests Alle Standard-Datentypen inkl. Lob s sind archivierbar Objektorientierte Datentypen können nicht archiviert werden (Für den Objekttyp XMLTYPE konnte eine einfache Umgehungslösung von uns bereitgestellt werden, die die Archivierung ermöglicht) Performance Tests Es gelten die Datenbank-Performance-Regeln Fachliche Tests mit der Pilot-Anwendung Daten konnten erfolgreich aus dem Archiv zurückgespielt werden Sicherheitskonzept konnte erfolgreich umgesetzt werden Betriebliche Tests Archivierung kann über Deployment-Verfahren aus der Entwicklung in andere Umgebungen gebracht werden. Die Archivierungsläufe können über einen beliebigen Scheduler automatisiert werden

17 Erstellen einer Archivierung I Archivierungskonzept - Definition der Geschäftsobjekte, die archiviert werden sollen - Abbildung dieser Objekte im relationalen Datenmodell der Anwendung - Archivierungskriterien für die zu archivierenden Objekte

18 Ablauf einer Archivierung pr0cmnd pr0svce pr0sver DB PST Archivdatei EMC Centera Archivdatei

19 Aktueller Stand Unsere Archivierungslösung ist seit Januar 2008 im produktiven Betrieb Aktuell wurde ein Oracle-Datenbanksystem archiviert, das abgeschaltet wurde und es erfolgt eine fortlaufende Archivierung eines weiteren Oracle-Datenbanksystems, dass sich in Produktion befindet. Für ein weiteres großes DB-System wurde ein Archivierungskonzept erstellt und die Archivierungsläufe werden aktuell entwickelt. Für zwei weitere Systeme werden derzeit Archivierungskonzepte erstellt.

20 Aktuelle Größe Datenbankwachstum Datum TB db_size used_size max_size

21 DB-Größe nach Reorg Dem Rechenzentrumsdienstleister können ca. 700 GB zurückgegeben werden Voraussichtliche Verringerung der Datenbankgröße nach der Reorganisation TB db_size used_size max_size Datum

22 Ende Mit Tabellenkompression und Archivierung kann das Datenwachstum reduziert werden. Im besten Fall ist es auch möglich, nach geeigneten Reorganisationsmaßnahmen die Gesamtgröße der Datenbank zu verringern