Otto-von-Guericke-Universität Magdeburg

Otto-von-Guericke-Universität Magdeburg

Fakultät für Informatik

Institut für Technische und Betriebliche Informationssysteme

Master-Thesis

Untersuchungen zum aktuellen Forschungsstand von Self-Healing und Self-Protection in

Datenbankmanagementsystemen

Verfasser :

Stefan Barthel

Matrikel-Nr.: 191261

Betreuer :

Dr.-Ing. Eike Schallehn

Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik

D-39016 Magdeburg

Betreuer :

Prof. Dr.-Ing. Andreas Nürnberger

Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik

D-39016 Magdeburg

Barthel, Stefan

Untersuchungen zum aktuellen Forschungsstand von Self-Healing und Self-Protection in

Datenbankmanagementsystemen

Master-Thesis

Otto-von-Guericke-Universität Magdeburg, 2012.

Danksagung

Eine wissenschaftliche Arbeit wie diese braucht die Unterstützung Vieler, um zum Abschluss zu kommen. Mein Dank gilt daher allen helfenden Händen und Augen, welche ihre Zeit opferten, um mich in meinem Vorhaben zu unterstützen, diese Arbeit zu verfassen.

Mein größter Dank gilt Herrn Dr. Eike Schallehn für seine Bereitschaft, mich seit dem ersten Tag mit Ideen und Wissen zu unterstützen. Zudem bin ich sehr dankbar, in ihm einen Betreuer und Freund gefunden zu haben, der auch zu untypischen Tages- und Nachtzeiten aufgekommene Fragen beantwortet und dieses stets als selbstverständlich betrachtete.

Weiterhin möchte ich mich bei Prof. Dr. Andreas Nürnberger für die Bereitschaft bedanken, die ehrenvolle Aufgabe des Zweitgutachters zu übernehmen, trotz der relativ kurzen Vorlaufzeit.

Zuletzt möchte ich auch meinem ehemaligen Arbeitgeber - COMPAREX - danken, der mir die Wichtigkeit dieser Arbeit nachsah und mich anfangs teilweise freistellte, sowie schlussendlich anstandslos freigab, damit ich die Arbeit bestmöglich beenden konnte.

Inhaltsverzeichnis

D

... IV I

... VI A

... X T

...XII A

... XIV

1. E

... 1

1.1. ZIELSETZUNG ... 2

1.2. GLIEDERUNG ... 2

2. G

D

... 5

2.1. GRUNDLEGENDE BEGRIFFE ... 5

2.2. HISTORISCHE ENTWICKLUNG DER DATENBANKMANAGEMENTSYSTEME ... 7

2.3. ARCHITEKTUR UND EIGENSCHAFTEN EINES DATENBANKSYSTEMS ... 11

2.3.1. NEUN ANFORDERUNGEN NACH CODD ... 11

2.3.2. ARCHITEKTUR VON DATENBANKMANAGEMENTSYSTEMEN ... 12

2.3.2.1. SCHEMAARCHITEKTUR ... 12

2.3.2.2. ANWENDUNGSARCHITEKTUR ... 14

2.3.2.3. SYSTEMARCHITEKTUR ... 15

2.3.2.4. FÜNF-SCHICHTEN-MODELL ... 16

2.3.3. SPEICHERHIERARCHIE ... 19

2.3.4. VERWALTUNG DES HINTERGRUNDSPEICHERS ... 20

2.3.5. SEITEN,SÄTZE UND ADRESSIERUNGEN ... 23

2.3.6. TRANSAKTIONEN ... 24

2.4. MARKTANALYSE DERZEITIGER DATENBANKSYSTEME ... 25

2.4.1. DBMS-BEZUG IN DIESER ARBEIT ... 28

3. G

S

-H

S

-P

... 29

3.1. EINORDNUNG IN DAS AUTONOMIC COMPUTING ... 29

3.2. ABGRENZUNG UND GEMEINSAMKEITEN MIT ANDEREN WISSENSCHAFTSBEREICHEN ... 34

3.3. HERKUNFT UND EINORDNUNG DES SELF-HEALINGS ... 36

3.4. HERKUNFT UND EINORDNUNG DER SELF-PROTECTION ... 41

4. B

G

D

47 5. A

S

-H

... 53

5.1. MECHANISMEN IN KONVENTIONELLEN SYSTEMEN ... 53

5.1.1. SELF-HEALING WÄHREND EINER DATABASE MIRRORING SESSION ... 53

5.1.2. SELF-HEALING DURCH WARTUNGSARBEITEN ... 53

5.1.3. SELF-REPAIR DURCH AUTOMATIC FAILOVER ... 55

5.1.4. STATISTISCHES MANAGEMENT ... 56

5.1.5. DEADLOCKERKENNUNG ... 57

5.1.6. GESUNDHEITSCHECKS PER HEALTH MONITOR ... 58

5.1.7. FEHLERBEHEBUNG BEI DER TRANSAKTIONSVERARBEITUNG ... 58

5.1.8. AUTOMATISCHES WACHSEN BEI PLATZMANGEL ... 59

5.1.9. STABILISIERUNG DES SERVERS UND ANPASSUNG AN ARBEITSAUFKOMMEN . 60 5.1.10. AUTOMATISCHE INDEX- UND TABELLEN-ORGANISATION ... 61

5.1.11. ANPASSUNG DES DATENBANKDESIGN BEI WECHSELNDEM ARBEITSAUFKOMMEN... 62

5.2. AKTUELLE FORSCHUNG UND PROTOTYPEN ... 62

5.2.1. ITDB-ASELF-HEALING DATABASE SYSTEM [LIU04] ... 63

5.2.2. OPTIMIZING SECURITY MEASURES IN AN INTRUSION TOLERANT DATABASE SYSTEM [UD08] ... 66

5.2.3. RAINBOW-PROJEKT [GS02] ... 67

5.2.4. SHAMAN:ASELF-HEALING DATABASE SYSTEM [DFT08] ... 70

5.2.5. ACCURATE AND EFfiCIENT INTER-TRANSACTION DEPENDENCY TRACKING [CB08] 71 5.2.6. A PORTABLE IMPLEMENTATION FRAMEWORK FOR INTRUSION-RESILIENT DATABASE MANAGEMENT SYSTEMS [SC04]... 73

5.2.7. SELF-HEALING AND HYBRID DIAGNOSIS IN CLOUD COMPUTING [DXZ09] .. 75

5.2.8. REMUSDB: TRANSPARENT HIGH AVAILABILITY FOR DATABASE SYSTEMS [DXZ09] 79 5.3. VERGLEICH UND ZUSAMMENFASSUNG ... 82

6. A

S

-P

... 87

6.1. MECHANISMEN IN KONVENTIONELLEN SYSTEMEN ... 87

6.1.1. VERSCHLÜSSELUNG VON PROZEDUREN UND FUNKTIONEN ... 87

6.1.2. QUERY- UND RESSOURCEN-KONTROLLE... 87

6.1.3. IDENTITÄTS- UND ZUGRIFFSSTEUERUNG ... 89

6.1.4. MODULSIGNIERUNG ... 90

6.1.5. SELF-AUDITING UND MONITORING ZUM SYSTEMSCHUTZ ... 91

6.1.6. CLR-INTEGRATION UND CODEZUGRIFFSSICHERHEIT ... 92

6.1.7. HALBAUTOMATISCHES BACKUP UND RECOVERY ... 92

6.1.8. EXCEPTION- UND ERROR-BEHANDLUNG BEI SKRIPTAUSFÜHRUNG ... 93

6.1.9. VERHINDERUNG VON OUT-OF-SPACE-SITUATIONEN ... 94

6.2. AKTUELLE FORSCHUNG UND PROTOTYPEN ... 94

6.2.1. HOW TO BUILD A TRUSTED DATABASE SYSTEM ON UNTRUSTED STORAGE [MVS06] 95 6.2.2. TOWARDS SELF-PROTECTION UBIQUITOUS SYSTEMS: MONITORING TRUST- BASED INTERACTIONS [ETN05] ... 96

6.2.3. TOWARDS DATABASE FIREWALL: MINING THE DAMAGE SPREADING PATTERNS [BL07] ... 98

6.2.4. SELF-PROTECTED SYSTEM:AN EXPERIMENT [DCL06] ... 100

6.2.5. REDUCING ERRORS IN THE ANOMALY-BASED DETECTION OF WEB-BASED ATTACKS THROUGH THE COMBINED ANALYSIS OF WEB REQUESTS AND SQL QUERIES [VVB09] 103 6.2.6. SQLRAND:PREVENTING SQLINJECTION ATTACKS [BK04]... 105

6.2.7. DETECTION OF MALICIOUS TRANSACTIONS IN DBMS[ASB10] ... 107

6.2.8. DELIVERING SERVICES WITH INTEGRITY GUARANTEES IN SURVIVABLE DATABASE SYSTEMS [ZL04] ... 109

6.3. VERGLEICH UND ZUSAMMENFASSUNG ... 111

7. Z

A

... 117

L

... 121

S

... 137

Abbildungsverzeichnis

Abbildung 1: Aufbau des Datenbanksystems ... 6

Abbildung 2: Aufbau einer Relation ... 6

Abbildung 3: Zugriffsarten (vgl. [Wiki02]) ... 8

Abbildung 4: Drei-Ebenen-Schema-Architektur (vgl. [SSH10]) ... 13

Abbildung 5: Anwendungsarchitekturen... 15

Abbildung 6: Systemarchitektur (vgl. [SHS05]) ... 15

Abbildung 7: Fünf-Schichten-Modell ... 17

Abbildung 8: Unterscheidung Primär-, Sekundär-, und Tertiärspeicher ... 20

Abbildung 9: Festplattenaufbau ... 21

Abbildung 10: Darstellungen einer Relation (vgl. [SHS05]) ... 22

Abbildung 11: Tupelidentifikator ... 23

Abbildung 12: Autonomic Computing-Loop (vgl. [IBM01]) ... 31

Abbildung 13: Autonomic Computing-Abhängigkeiten ... 32

Abbildung 14: Bestandteile des Autonomic Computings (vgl. [IBM01]) ... 33

Abbildung 15: Herkunft Self-Healing Systems ... 37

Abbildung 16: Self-Healing-Kreislauf (vgl. [PD10]) ... 40

Abbildung 17: Herkunft Self-Protection Systems ... 41

Abbildung 18: Problemlösungskreislauf (vgl. [RMS10]) ... 61

Abbildung 19: Arbeitsweise ITDB [Liu04] ... 65

Abbildung 20: Modell-basierte Adaptierung (vgl. [GD02]) ... 67

Abbildung 21: Modell eines verteilten DBMS ... 69

Abbildung 22: Abhängigkeiten der Transaktionen ... 72

Abbildung 23: Arbeitsweise Self-Healing and Hybrid Diagnosis in Cloud Computing (vgl. [DXZ09]) ... 78

Abbildung 24: Architektur RemusDB (vgl. [DXZ09]) ... 80

Abbildung ²⁵: Architektur TDB (vgl. [MVS06]) ... 96

Abbildung 26: One-hop und multi-hop spreading (vgl. [BL07]) ... 99

Abbildung 27: Komponenten-basierte Jade-Architektur (vgl. [DCL06]) ... 102

Abbildung 28: Kommunikation zwischen Web Server und Database Server (vgl. [BK04]). 107 Abbildung 29: Einordnung DBMTD (vgl. [ASB10]) ... 108

Tabellenverzeichnis

Tabelle 1: Strukturelle Bezeichnungen zu Systemebenen ... 18

Tabelle 2: Abbildung der Speicherstrukturen ... 22

Tabelle 3: Top 10-DBMS-Anbieter 2009 (vgl. [IDC09]) ... 27

Tabelle 4: Gegenüberstellung der technischen und biologischen Systeme ... 36

Tabelle 5: Gegenüberstellung von Zugriff, Autorisierungsstatus und Angriffsebene ... 49

Tabelle 6: Gewichtungs-Level ... 77

Tabelle 7: Auswertung der Self-Healing-Mechanismen und -Systeme ... 83

Tabelle 8: Auswertung der Self-Protection-Mechanismen und -Systeme ... 113

Abkürzungsverzeichnis

5SM Fünf-Schichten-Modell AC Autonomic Computing

ADDM Automatic Database Diagnostic Monitor ADL Architecture Description Language ADR Automatic Diagnostic Repository ANSI American National Standards Institute ASC Automatic Statistics Collection

ASH Active Session History

ASM Automatic Storage Management

ASMM Automatic Shared Memory Management ASP Active Server Pages

AWR Automatic Workload Repository

BDE Backup Data Exposure

BI Business Intelligence

CERT Computer Emergency Response Team

CGI Common Gateway Interface

CLR Common Language Runtime

CODASYL Conference on Data System Language CPM Corporate Performance Management CPU Central Processing Unit

DB Datenbank

DBA Datenbankadministrator

DBS Datenbanksystem

DBMS Datenbankmanagementsystem

DBMTD Database Malicious Transactions Detector

DBTG Data Base Task Group

DCL Data Control Language

DCPV Database Communication Protocol Vulnerabilities

DDL Data Definition Language

DSS Dateischnittstelle

DML Data Manipulation Language

DoS Denial of Service

DQL Data Query Language

DSS Decision Support System

EPA Excessive Privilege Abuse ESoF External Software Failure ESyF External System Failure HTTP Hypertext Transfer Protocol ID Identifikationsnummer IHF Internal Hardware Failure IP Internet Protocol

ISF Internal System Failure ISS Interne Satzschnittstelle

JSP Java Server Pages

LDAP Lightweight Directory Access Protocol LPA Legitimate Privilege Abuse

LRU Least Recently Used

MDD Multi-Valued Decision Diagram MOS Mengenorientierte Schnittstelle

NCIRC Nato Computer Incident Response Capability´s Technical Center OODBS Objektorientiertes Datenbanksystem

OOP Objektorientierte Programmierung PE Privilege Elevation

PGA Program Global Area

PHP PHP: Hypertext Preprocessor PV Platform Vulnerabilities

QoIAS Quality of Integrity Assurance Service RAM Random Access Memory

RDBMS Relationales Datenbankmanagementsystem SGA System Global Area

SIS Strategische Informationssicherheit SOS Satzorientierte Schnittstelle

SPARC Standards Planning and Requirements Committee SPS Systempufferschnittstelle

SQL Structured Query Language

SQLI SQL Injection

TID Tupelidentifikator

TSQL Transact SQL

VM Virtual Machine

WA Weak Authentication WAL Write Ahead Logging WAT Weak Audit Trail

XML Extensible Markup Language

1. Einleitung

Computer werden heutzutage in so vielfältiger Art und Weise verwendet, dass es den meisten Menschen sehr schwer fallen wird, einen Bereich zu benennen, welcher vollkommen ohne Computer auskommen kann. Besonders bemerkenswert ist dieses jedoch, wenn in die Überlegung einfließt, dass der erste funktionsfähige Digitalrechner - Z3 - erst 1941 vom deutschen Wissenschaftler Konrad Zuse entworfen und gebaut wurde. Somit hat sich der Computer innerhalb von wenigen Jahrzehnten von einem Helfer zur Auszählung von Wahlstimmen zum wichtigsten technischen Gut des einundzwanzigsten Jahrhundert entwickelt (vgl. [S 12 ff. [Wur02]]). Die Evolution des Computers ist aber keinesfalls bereits abgeschlossen, sondern ein kontinuierlich fortschreitender Prozess. Mit der steigenden Komplexität sinkt jedoch auch die Nachvollziehbarkeit für den Menschen und so müssten entweder fremde Systeme die Prozesse überwachen oder das System eigenständig diese Aufgabe übernehmen. Somit geht mit wachsender Komplexität zwangsweise eine kontinuierliche Abkapselung von menschlichen Einflüssen einher. In fast allen Fällen kommt eine solche Automatisierung dem Menschen sehr entgegen, da ihm auf diese Weise Zeit und Anstrengungen erspart bleiben und auf der anderen Seite Genauigkeit, Effizienz und Verlässlichkeit gesteigert werden können. Darüber hinaus werden Kapazitäten des Systemadministrators freigesetzt, wodurch er sich anderen Problemen annehmen kann.

Das Bedürfnis eine Selbstverwaltung des Computers zu etablieren ist somit ein erstrebenswertes Ziel, gerade wenn die Maximierung der Funktionalität, die hohe Komplexität und die umfassenden Strukturen, um große Datenmengen eines DBMS zu bewältigen, betrachtet werden. Zukünftig wird dieses Bedürfnis wahrscheinlich noch weiter zunehmen, da die zu sammelnden Datenmengen stündlich wachsen und damit auch deren Verwaltungsaufwand steigt. So werden Daten heutzutage nur noch sehr selten gelöscht, auch wenn der User das eigentlich verlangt (vgl. [SML07]). Je mehr Daten vorliegen, desto höher auch deren Wert und die Begehrlichkeiten Außenstehender. Des Weiteren sollten bei größeren und wertvolleren Datenbeständen, auch größere und intensivere Schutzmechanismen etabliert werden. Da diese Anstrengungen wiederum einen massiven Verwaltungsaufwand nach sich ziehen, wäre eine Automatisierung auch an dieser Stelle erstrebenswert.

All diese Vorteile und Probleme motivierten die IT-Industrie und viele Forschungsgruppen in der Vergangenheit, die Automatisierung der DBMS voran zu treiben, welche immer weniger äußere, menschliche Einflüsse nötig macht.

1.1. Zielsetzung

Ziel dieser Arbeit ist es, den aktuellen Stand der Technik - State of the Art - von Self-Healing- und Self-Protection-Mechanismen darzulegen, welche zu den selbstverwaltenden Eigenschaften eines DBMS gehören. Im Zuge dessen werden Grundlagen des Self-Healings und der Self-Protection erläutert und es wird eine Übersicht über existierende Implementierungen in den drei am meisten etablierten DBMS gegeben. Darüber hinaus werden aktuelle Forschungsarbeiten vorgestellt, die noch nicht etablierte Ansätze von Self- Healing und Self-Protection in DBMS erforschen. Die aufgeführten Sicherheitsvorkehrungen sind den im Abschnitt 4 aufgelisteten Gefahren und Bedrohungen gegenübergestellt und es wird verglichen, inwieweit diese eliminiert oder eingedämmt werden können.

1.2. Gliederung

Im Zuge dieser Forschungsarbeit werden Self-Healing und Self-Protection-Mechanismen aus Echtzeitsystemen und Forschungsbeiträgen untersucht. Vorausgesetzt wird für die gesamte Arbeit grundsätzliches Wissen über Tabellen und Relationen sowie über Datenbanksysteme.

Dennoch sollen die wichtigsten Aspekte für das grundlegende Verständnis von Methoden und Technologien im Grundlagenkapitel 2 erläutert werden. Dazu wird auch auf die geschichtliche Entwicklung des DBMS eingegangen und revolutionäre Meilensteine, wie die von Edgar F. Codd tiefergehend erläutert. Diese sind dem fachkundigen Leser jedoch in der Regel geläufig und können bei Bedarf auch übersprungen werden. Damit die Abstammung und Einordnung der beiden selbstverwaltenden Mechanismen nachgewiesen werden kann, wird umfassend auf das Autonomic Computing sowie dessen Herkunft im Kapitel 3 eingegangen. Die Unterteilung der potentiellen Gefährdungen eines DBMS im Kapitel 4 nach Gefahren und Bedrohungen dient als Einführung für die eigentlichen Ansätze. Die beiden Hauptthemen Self-Healing- und Self-Protection werden ab Kapitel 5 nach Vorkommen in etablierten Systemen und Forschungsbeiträgen unterteilt, wobei die betreffenden Gefährdungen am Anfang jedes Kapitels genannt werden. Schlussendlich dient eine Zusammenfassung am Ende der beiden Kapitel als Resümee sowie eine sich am Ende

befindende Zusammenfassung aller aufgeführten Mechanismen als Fazit in dem auch ein Ausblick auf zukünftige Entwicklungen gegeben wird.

Verwendete Abkürzungen, werden im Abkürzungsverzeichnis erläutert und sind in dieser Arbeit großgeschrieben abgebildet (z.B. PHP). Hervorgehobene Begriffe (Schlagwörter) werden kursiv dargestellt und Angaben zu Literaturquellen befinden sich in [eckigen Klammern]. Dem Leser unbekannte Termini, welche jedoch im weiteren Verlauf dieser Arbeit nicht wieder in Erscheinung treten, sind mit einer Fußnote gekennzeichnet und werden in der Fußzeile erläutert.

2. Grundlagen zu Datenbanken

Dieses Kapitel dient zur Darlegung der Grundlagen von Datenbanken und dessen Verwaltungssystemen. Es werden zunächst grundlegende Begriffe erläutert und ein geschichtlicher Einblick gegeben, bevor grundlegende theoretische und technische Aspekte genannt werden.

2.1. Grundlegende Begriffe

Die nachfolgend aufgeführten Begriffe werden in dieser Forschungsarbeit mehrfach verwendet, können auf Grund ihres häufigen Auftretens jedoch nicht wiederholt erläutert werden. Daher werden die Termini an dieser Stelle aufgegriffen und kurz erläutert, ohne jedoch umfassende und tiefgreifende Grundlagen auszubreiten. Für nähere Ausführungen sei auf das Buch [SSH10] von Saake, Sattler und Heuer verwiesen.

Datenbank

Eine Datenbank (DB) ist eine organisierte Sammlung von Daten (Datenbestand), welche von einem DBMS verwaltet wird und den darauf operierenden Anwendungssystemen und Benutzern verborgen bleibt. Physisch werden die Daten in einer DB, auf nichtflüchtigen Speichermedien, abgelegt.

Datenbankmanagementsystem

Ein Datenbankmanagementsystem (DBMS) ist die Verwaltungssoftware einer oder mehrerer Datenbanken. Es ist die zentrale Anlaufstelle, welche alle Anfragen, Änderungs- oder Einfüge-Operationen der DB bearbeitet und durchführt. Zur Übermittlung der Befehle nutzt es Datenbanksprachen, zu dessen Vertreter in relationalen Systemen SQL gehört. Das DBMS entscheidet maßgeblich über Funktionalität und Geschwindigkeit des Gesamtsystems, da es unter anderem für Verschiebungen in der Speicherhierarchie bzw. das Zwischenspeichern (puffern) verantwortlich ist. Darüber hinaus definiert das DBMS das Datenbankmodell, durch das alle Daten einheitlich beschrieben werden.

Datenbanksystem

Das Datenbanksystem (DBS) ist die Kombination der DB, welche als Datenbasis fungiert und des DBMS, welches das Verwaltungsprogramm darstellt. Es ist ein System zur Beschreibung,

Speicherung und Wiedergewinnung umfangreicher Datenmengen, das von mehreren Anwendungsprogrammen oder Anwendern benutzt wird (vgl. [S 1 [Eng00]]).

Abbildung 1: Aufbau des Datenbanksystems

Relationale Datenbankmanagementsysteme

In dieser Forschungsarbeit wird immer wieder Relationalität als Grundlage des jeweiligen DBMS vorausgesetzt werden, da es derzeit der Industriestandard ist. Das von Edgar Frank Codd 1970 vorgestellte Relationenmodell ist das am weitesten verbreitete Modell, welches sich zudem in der Praxis etabliert hat und den erfolgreichsten DBMS zu Grunde gelegt wurde.

Es werden dabei gleichartige Objekte durch n-Attribute beschrieben, wobei jedes Attribut durch einen bestimmten Ausprägungstyp (ganzzahlige Zahlen, Fließkommazahlen, Zeichen, Wahrheitswerte) charakterisiert werden kann. Die sequentielle Auflistung dieser Objekte, welche durch ihre Eigenschaften (Attribute) präsentiert werden, stellt die Relation dar. Jedes einzelne Objekt in dieser Relation wird als Tupel bezeichnet.

Abbildung 2: Aufbau einer Relation

Wie in Abbildung 2 zu erkennen ist, kann eine Relation anschaulich als Tabelle verstanden werden, wobei Attribute als Spaltenüberschriften, die Menge aller Attributnamen als

Relationenschema, eine Zeile als Tupel und der Verbund aller Tupel als Relation verstanden werden kann.

SQL

SQL, welches für Structured Query Language steht, ist eine Datenbanksprache für relationale DBMS und vereint vier verschiedene Typen von Datenbanksprachen in sich: Data Manipulation Language (DML), Data Definition Language (DDL), Data Control Language (DCL) und Data Query Language (DQL). Neben den genannten Möglichkeiten Daten zu verändern, definieren und abzufragen sowie Berechtigungen zu vergeben, umfasst SQL die Ausdrucksfähigkeit der Relationenalgebra¹ und zusätzliche Funktionen (min, max, sum, count usw.) zur Aggregation sowie einfache arithmetische Operationen (Addition, Subtraktion, Multiplikation und Division).

Cloud Computing

Cloud Computing, ein erst seit kurzem weit verbreiteter Terminus, scheint den Weg für zukünftige Computergenerationen zu weisen. Er bezeichnet eine computerbasierende Architektur, welche Software und Plattformen Service-orientiert bereitstellt, damit der informationstechnologische Aufwand und damit einhergehende Kosten innerhalb einer Firma reduziert werden können. Der Unterschied zwischen dem Cloud Computing und den standardmäßig an das Internet angeschlossenen Servern macht vor allem genau die Anforderung an die Robustheit, höchste Skalierbarkeit und äußerst leistungsfähige Infrastruktur aus. Die Cloud betitelt hierbei einen Pool von externen Computerressourcen, welche im Verbund massives Arbeitsaufkommen bewältigen können und dabei ausschließlich benötigte Ressourcen belegen. So können abhängig vom Workload virtualisierte Ressourcen hinzu- oder abgezogen werden. Damit die Ausfallsicherheit und Skalierbarkeit für jeden Kunden, egal ob Privatperson oder Konzern, gewährleistet werden kann, sind die im Hintergrund befindlichen Systeme dementsprechend komplex und pflegebedürftig. Für tiefergehende Informationen zum Cloud Computing sei auf [BKN10] verwiesen.

2.2. Historische Entwicklung der Datenbankmanagementsysteme

Datenbanken werden bereits seit den Anfängen des Computers genutzt. Anders als moderne Systeme, welche an fast alle Anwendungen angepasst werden können, wurde die Mehrheit

1 Die Relationenalgebra bietet spezielle Operationen für Relationen, welche die Mengenalgebra nicht abdeckt.

der älteren Systeme jedoch mit einer systemspezifischen Datenbank eng verzahnt. Diese Verzahnung brachte große Performancesteigerungen mit sich, war aber nachteilig für Flexibilität und Portierbarkeit. Ursprünglich konnten Datenbanksysteme auch nur in großen Unternehmen gefunden werden, die sich die dementsprechende Hardware leisten konnten, um die benötigte Rechenkapazität zu nutzen.

In den sechziger Jahren, als die Rechenkapazität der Computer anstieg, wurde die Abhängigkeit der DBS von Großrechnern immer geringer, weswegen immer mehr universelle DBS entwickelt wurden. Nachdem immer mehr universelle Systeme ihren Einsatz fanden, wurde der Ruf nach Vereinheitlichung immer lauter. Charles Bachman, welcher selbst Entwickler eines solchen Systems war - Integrated Data Store (IDS) - , gründete auf Grund dessen die Data Base Task Group (DBTG). Die DBTG war unter anderem für die Erschaffung und Standardisierung von COBOL² im Rahmen der Conference on Data System Language (CODASYL) verantwortlich. Weitere herausgegebene Standardisierungen dieser Vereinigung waren so einschneidend und wichtig für die gesamte Branche, dass dem Standard folgende DBS als CODASYL-Systeme bezeichnet wurden. Ein großer Nachteil des CODASYL- Ansatzes bestand jedoch bei der manuellen Suche. So waren alle Datensätze nacheinander verkettet und im Falle einer Selektion mussten alle Datensätze sequentiell gelesen werden.

Abbildung 3 verdeutlicht die genannten Abhängigkeiten des sequenziellen Zugriffs gegenüber einem wahlfreien Zugriff.

Abbildung 3: Zugriffsarten (vgl. [Wiki02])

2 COBOL ist eine Hardware-unabhängige, standardisierte Programmiersprache, welche stark an die natürliche Sprache angelehnt ist und für die Erstellung von Programmen für betriebswirtschaftliche Bereiche gedacht ist.

Der sequentielle Zugriff, welcher durch den genannten Nachteil in den meisten modernen Systemen kaum noch zur Anwendung kommt, war damals weniger dramatisch, da der wahlfreie Zugriff auf Magnetbänder ohnehin nicht realisiert werden konnte. Auf Grund dieser Verkettung wurde das DBS, wie auch alle anderen DBS nach CODASYL, dem Netzwerkdatenbankmodell zugeordnet. IBM entwickelte 1968 derweilen ein DBS namens IMS, welches für das Apollo-Programm auf dem System/360 beruhte, im Gegensatz zu CODASYL jedoch eine strikte Hierarchie für die Navigation nutze. IMS gehört folglich auch den hierarchischen Datenbankmodellen an.

In den siebziger Jahren war es vor allem Dr. Edgar Frank Codd, welcher an der Entwicklung von Speichersystemen in der IBM arbeitete, der die Entwicklung der DBMS entscheidend veränderte. Auf Grund seiner Unzufriedenheit bezüglich des CODASYL-Ansatzes verfasste er einige Forschungsbeiträge, welche schlussendlich in dem Forschungspapier "A Relational Model of Data for Large Shared Data Banks" [Codd70] ihre Krönung fand und als Grundstein des relationalen Modells gilt. In Codds Forschungsarbeit steht beschrieben, wie ein damals neuerliches System große Datenbanken speichern und verwalten kann, indem es Daten in tabellarische Strukturen verlagert.

Es brauchte jedoch einige Zeit bis IBM die Forschungen Codds als ernst zu nehmend einstufte und ein System beruhend auf diesem Modell entwickelte. Die erste Version von System R wurde 1975 veröffentlich wobei diese lediglich als Mono-Tabellen-Systeme ausgelegt war.

Zur selben Zeit begann das Team um Eugene Wong und Michael Stonebraker ein Projekt namens INGRES, welches im Grunde eine ähnliche Mächtigkeit wie System R hatte. Bereits 1979 konnte eine Version von System R vorgestellt werden, die Multi-User-kompatibel war und in welcher die standardisierte Abfragesprache SQL implementiert wurde. Durch die unübersehbaren Vorteile des Codd'schen Ansatzes wurde IBM direkt dazu getrieben, eine kommerziell veräußerliche Version des System R am Markt zu platzieren, was durch SQL/DS (später Database 2 - DB2) auch umgesetzt wurde.

Einige INGRES-Entwickler waren gegen 1980 davon überzeugt, dass auch eine kommerzielle Version von INGRES heraus gebracht werden müsse und gründeten Firmen, die sich das zur Aufgabe machten. Sybase, Informix, NonStop SQL und Ingres selbst - in der heutigen Form - entstanden auf diese Weise. Sogar Microsofts SQL Server beruht auf einer stark umgebauten

und verbesserten Version von INGRES, da Großteile des INGRES-Ablegers Sybase in ihre Entwicklung einflossen.

Nur Larry Ellisons Oracle DBMS startete unabhängig von INGRES-Konzepten. Oracle erschuf ihr DBMS auf den Grundlagen von System R und konnte schon bei der Markteinführung dank dieser Herangehensweise IBMs DB2 in Performance-Angelegenheiten schlagen. Auch Michael Stonebraker, der ein fester Bestandteil des Teams um INGRES war, ging seine eigenen Wege und verließ das INGRES-Team. Er machte sich an eine Neuentwicklung, die heute unter dem Namen "PostgreSQL" bekannt ist.

In den 1980er Jahren konnte zudem ein Anwachsen der objektorientierten Datenbanksysteme (OODBS), zusammen mit der objektorientierten Programmierung (OOP), beobachtet werden.

Mit OODBS muss die Komplexität vieler Anwendungen, die durch OOP entstanden sind, nicht auf ein relationales Datenbankschema abgebildet werden, sondern kann direkt in die Datenbank übertragen werden. Jedoch haben die OODBS im Gegensatz zu relationalen Datenbanksystemen kein einheitliches Datenmodell, das allen (kommerziellen) OODBS zugrunde liegt. Die OODBS bieten Möglichkeiten wie persistente Speicherung von Objekten, Speicherstrukturen für Mengen von Objekten und wichtige Operatoren für Datenbankanwendungen (vgl. [Dit86], [Dit88], [DK89]). Darüber hinaus entstanden objektrelationale Datenbanksysteme (ORDBS), welche eine Lösung zwischen relationalen und objektorientierten DBS darstellen. So wurde in den meisten Fällen ein relationales Datenmodell um objektorientierte Methoden und Datentypen erweitert, womit anschließend auch komplex strukturierte Daten abgebildet werden konnten. Als eines der letzten Systeme, welche in dem vergangenen Jahrtausend entstand, sollen XML-DBS genannt werden, die Daten im XML-Format abspeichern können. Dabei gilt es zwischen nativen XML-DBS und herkömmlichen DBS zu unterscheiden, welche eine alternative Speicherung oder Umwandlung erlauben.

Seit dem Beginn des einundzwanzigstens Jahrhunderts sind es vor allem die NoSQL- Datenbanken, welchen große Aufmerksamkeit erregen. Diese unterscheiden sich jedoch durch ihre Nicht-Relationalität von den "klassischen" Systemen. Sie benötigen nur selten ein festes Tabellen-Schema, meiden JOIN-Operationen und können selbst zusätzliche Ressourcen einholen oder abgeben (Scale-Out).

2.3. Architektur und Eigenschaften eines Datenbanksystems

Nachdem auf grundlegende Begriffe und die historische Entwicklung der DBMS bzw. DBS eingegangen wurde, sollen noch grundlegende architektonische, theoretische und technische Eigenschaften aufgeführt werden.

2.3.1. Neun Anforderungen nach Codd

Die in dieser Forschungsarbeit betrachteten selbstverwaltenden Eigenschaften eines DBMS setzten voraus, dass das betreffende DBMS die neun Fähigkeiten besitzt, welche der britische Wissenschaftler Edgar Frank Codd im Jahre 1982 verfasste ([Codd82]). Dr. Edgar Frank Codd war einer der Urväter aller modernen DBMS, da er sowohl das erste relationale DBMS - System R - mitentwickelte, als auch die theoretischen Grundlagen für Datenbankmanagementsysteme, durch seine neun Basis-Funktionalitäten definierte. Zu den neun Fähigkeiten eines DBMS nach [Seite 114 [Codd82]] gehören:

1. Data storage, retrieval and update - Operationen, welche das Einfügen, Löschen, Suchen und Updaten abdecken.

2. A user-accessible catalog for data description - Ein Katalog (Data Dictionary), welcher den Zugriff auf die Datenbeschreibung der Datenbank erlaubt.

3. Transaction support to ensure that all or none of a sequence of database changes are reflected in the pertinent database - Transaktionen als Zusammenschluss von Datenbankänderungen, die nur vollständig ausgeführt werden können und anschließend permanent in der Datenbank gespeichert sind.

4. Recovery services in case of failure - Die Wiederherstellung des Datenbestandes nach etwaigen Fehlern oder Systemausfällen.

5. Concurrency control services to ensure that concurent transactions behave the same way as if run in some sequential order - Die Concurrency Control regelt die Synchronisierung parallel laufender Transaktionen, die auf den selben Datenobjekte arbeiten.

6. Authorization services to ensure that all access to and manipulation of data be in accordance with specified constraints on users and programs - Die Autorisierung stellt sicher, dass Veränderungen und Zugriffe auf Datenobjekte nur im Einklang mit den für das System definierten Systemrichtlinien geschehen.

7. Integration with support for data communication - Die Integration und einheitliche, redundanzfreie Bereitstellung aller abgelegten Daten.

8. Integrity service to ensure that database states and changes of state conform to specified rules - Die Integritätsüberwachung sichert die Korrektheit der Datenbankinhalte sowie deren Änderungen.

9. Views - Sichten sind als virtuelle Tabellen definiert und bestehen aus einer umfangreicheren Abfrage auf gegebenenfalls mehrere reale Tabellen.

Nicht zu verwechseln sind diese neun Basis-Funktionalitäten eines DBMS mit den von Codd 1985 erklärten zwölf Codd'schen Regeln (vgl. [Codd851], [Codd852]), welche darlegen, was ein DBMS zu erfüllen hat, um als relational bezeichnet zu werden. Diese wurden darüber hinaus Anfang 1990 um eine dreizehnte (Regel-0) erweitert und später in diesem Jahr auf achtzehn Regeln ausgebaut. Viele der Regeln sind jedoch so streng, dass kein derzeitig erhältliches DBMS von sich behaupten kann, ein vollständig relationales Datenbankmanagementsystem nach Codd zu sein (vgl. [Seite 4 [Xia11]]).

2.3.2. Architektur von Datenbankmanagementsystemen

Da viele Passagen dieser Arbeit grundlegendes Wissen über DBMS und DBS voraussetzen und darauf aufbauende Mechanismen näher beschreiben, wird an dieser Stelle die Architektur eines DBS näher erläutert. Die Architektur kann laut [Seite 29 ff. [SSH10]], ausgehend von verschiedenen Aspekten, unterschiedlich betrachtet werden. Zum besseren Verständnis der selbstverwaltenden Konzepte eines DBMS im Zuge dieser Arbeit wird an dieser Stelle sowohl auf die Schema-, System- als auch auf die Anwendungsarchitektur eingegangen.

2.3.2.1. Schemaarchitektur

Die Schemaarchitektur beschreibt den Zusammenhang zwischen dem konzeptionellen, internen und externen Schema. Sie beruht auf der 1975 vom Standards Planning and Requirements Committee (SPARC) des American National Standards Institute (ANSI) entwickelten Drei-Ebenen-Schema-Architektur und beschreibt die grundlegende Trennung verschiedener Beschreibungsebenen für Datenbanksysteme. Darunter fallen drei unterschiedliche Schemata (vgl. [Seite 29 ff. [SSH10]]):

 Das externe Schema charakterisiert (anwendungsspezifische) Sichten auf den Gesamtdatenbestand und verweist zumeist auf das lokalere konzeptuelle Schema.

Dieses wird beispielsweise durch eine View gewährleistet, welche ihre Daten aus zwei unterschiedlichen Tabellen bezieht.

 Das konzeptuelle Schema ist das Ergebnis der Datenbankmodellierung, des

Datenbankentwurfs und der Datendefinition. Es liefert eine anwendungsunabhängige Gesamtsicht auf den Datenbestand. Die konzeptuelle Gesamtsicht erfolgt in

relationaler Darstellung.

 Das interne Schema realisiert die Dateiorganisation und Zugriffspfade auf physische Daten, welche durch das konzeptuelle Schema in abstrakterer Weise genutzt werden.

Eine nähere Erläuterung zu den physischen Gegebenheiten findet sich Abschnitt 2.3.

Abbildung 4: Drei-Ebenen-Schema-Architektur (vgl. [SSH10])

Sowohl das externe als auch das konzeptuelle Schema sind unabhängig von der jeweils darunter liegenden Schicht. Sie können somit angepasst werden, ohne dass Änderungen an weiteren Schichten vorgenommen werden müssen. Bezüglich der konzeptuellen Ebene wird von einer Implementierungsunabhängigkeit oder physischen Datenunabhängigkeit gesprochen und bei der externen Ebene von einer Anwendungsunabhängigkeit oder logischen Datenunabhängigkeit. Durch diese Unabhängigkeiten müssen sich beispielsweise Anwendungsentwickler nicht daran stören, dass Daten intern spalten- oder zeilenorientiert gespeichert werden.

Daten (Anfragen und Änderungstransaktionen), die zwischen den Ebenen weiter gegeben werden, sind in einer formalen Beschreibungssprache mit festgelegter Semantik verfasst. In der Abbildung 4 sind zudem zwei Pfeile dargestellt, welche den Transformationsweg der Datenbankzustände, Anfragen und Änderungstransaktionen zwischen den verschiedenen Schemaebenen dokumentieren:

 Die Anfragebearbeitung zeigt den Weg auf, den Anfragen und Änderungsoperationen zu bewältigen haben. Die Aufgabe besteht hierbei darin, eine extern formulierte Operation, in eine interne, auf die Datenstruktur bezogene, Operation umzuwandeln.

 Die Datendarstellung beschreitet diesen Weg rückwärtig, indem Ergebnisse, die in der internen Datenstruktur gefunden wurden, in die externe Darstellung überführt werden.

2.3.2.2. Anwendungsarchitektur

Die Anwendungsarchitektur bezieht sich auf die konkreten Aufgaben, Komponenten und Schnittstellen eines Datenbanksystems bei der Verzahnung mit einer Applikation. Heutzutage liegt den meisten Datenbankanwendungen eine Client-Server-Architektur zugrunde. Die Client-Server-Architektur beschreibt dabei den Zustand, dass ein Dienstnehmer (Client), Dienste eines Dienstanbieters (Server) nutzt. Der Client selbst kann darüber hinaus eine Server-Rolle bezüglich anderer Dienste oder zur Weiterverteilung selbst abonnierter Dienste übernehmen. Das DBMS ist unter Einhaltung dieser Aspekte der Server, der Dienste (Datenbankabfragen, -änderungen und -löschungen) anfragenden Clients (Benutzern an Computern) anbietet. Die eigentlichen Funktionalitäten können jedoch variabel verteilt werden und sind von Implementierung zu Implementierung unterschiedlich. [Seite 45 ff.

[SSH10]] unterscheidet drei Funktionsgruppen, die stufenlos mehr client- oder serverseitig integriert werden können:

1. Präsentation und Benutzerinteraktion 2. Anwendungslogik

3. Datenmanagementfunktionalität, einschließlich der Anfragebearbeitung und Transaktionskontrolle

Neben dieser zweielementigen Client-Server-Architektur existiert auch noch eine Drei- Schicht-Architektur, bei der die Anwendungslogik in einer eigenen Schicht realisiert wird (vgl. Abbildung 5). Diese zusätzliche Instanz, die zwischen Client und Server existiert, wird Applikationsserver genannt. Real existierende Beispiele wären die auf der Java Enterprise Edition basierenden Umgebungen JBoss von Red Hat oder Apples WebOjects.

Abbildung 5: Anwendungsarchitekturen

2.3.2.3. Systemarchitektur

Die Systemarchitektur unterteilt das DBS in Komponenten, Bausteine, Elemente oder auch Werkzeuge und zeigt Schnittstellen sowie den Kommunikationsverlauf zwischen diesen auf.

In [Seite 29 ff. [SSH10]] wurden zwei verschiedene Granularitäten einer Systemarchitektur vorgestellt. Zur klaren Abgrenzung werden Objekte der feineren Granularität als Elemente und Objekte mit gröberer Granularität als Komponenten bezeichnet.

Die in Abbildung 6 aufgeführten blauen Elemente und orangenen Komponenten wurden zusammen mit den aus der SPARC-Architektur bekannten drei Ebenen übereinander gelegt, um die Zusammenhänge zu verdeutlichen (siehe Abbildung 6).

Abbildung 6: Systemarchitektur (vgl. [SHS05])

Nachfolgende Komponenten können unterschieden werden:

 Die Definitionskomponente dient zur Datenbestimmung auf der konzeptuellen Ebene, zur Definition der Dateiorganisation auf der internen Ebene und zur Sichtdefinition auf der externen Ebene.

 Mit der Programmierkomponente werden Datenbankoperationen, Einbettungen und Masken bereitgestellt.

 Die Benutzerkomponente, die auch als Übergangskomponente bezeichnet werden könnte, beinhaltet Anwendungsprogramme, die auf die Datenbank zugreifen sowie interaktive Anfrage- und Änderungswerkzeuge.

 Die Transformationskomponente beinhaltet Werkzeuge zur Optimierung, Auswertung und für den Plattenzugriff und wird genutzt für die Transformation der Daten von der internen zur externen Darstellung und vice versa.

 Das Data Dictionary ist eine zentrale Komponente des Systems, da es sämtliche Daten der Definitionskomponente aufnimmt und alle anderen Komponenten mit diesen Informationen speist.

2.3.2.4. Fünf-Schichten-Modell

In der Drei-Ebenen-Schema-Architektur (ANSI-SPARC) sind die Transformationsschritte etwas ungenau und schemenhaft beschrieben. In dem Fünf-Schichten-Modell wird hingegen die Transformationskomponenten eines DBS detailiert erklärt. Somit muss für das Verständnis neben der globalen Beschreibung des Gesamtsystems, noch auf das Fünf- Schichten-Modell (5SM) von [Sen73] eingegangen werden, welche 1987 von [Här87]

weiterentwickelt wurde. Das 5SM stellt eine detailierte Beschreibung der Transformationskomponente, der im Abschnitt 2.3.2.3 beschriebenen Systemarchitektur dar, und konkretisiert die an der Transformation einer Anfrage oder Änderung teilnehmenden Elemente eines DBMS. Die Transformierung verläuft vom abstrakten konzeptuellen Schema (Datenbankmodell) bis zur physischen, internen Ebene (Speicherzugriff). Die Fünf-Schichten- Architektur ist jedoch kein normierter Standard, sondern lediglich ein Industriestandard, welcher eine vieler möglicher Sichtweisen auf das System widerspiegelt.

Abbildung 7: Fünf-Schichten-Modell

Abbildung 7 zeigt die einzelnen Elemente und Schnittstellen der Transformation sowie abstrakte bzw. physische Speichereinheiten (links), die in den verschiedenen Etappen genutzt werden. Alle in dieser Forschungsarbeit vorgestellten Mechanismen zum Schutz oder zur Heilung von betroffenen DBS setzen an mindestens einer dieser Elemente oder Schnittstellen an, weswegen nachfolgend auf die Objekte eines DBS eingegangen wird. Das Betriebssystem ist kein Teil eines DBS und wird deshalb im weiteren Verlauf nur oberflächlich betrachtet.

Einige wichtige, der erwähnten Speicherstrukturen (Seiten, Blöcke usw.) werden im Abschnitt 2.3.5 tiefergehende erläutert.

Darüber hinausgehende, tiefgreifende Informationen zu den Elementen und Schnittstellen kann zudem aus [S 40 ff. [SHS05]] sowie [S 37 ff. [SSH10]] entnommen werden.

Mengenorientierte Schnittstelle (MOS) - Die MOS stellt eine standardisierte Datenabfrage- und Datenmanipulationssprache (SQL) auf ganzen oder Teilen von Tabellen und Sichten zur Verfügung.

Datensystem - Es übersetzt und optimiert SQL-Anfragen der MOS für die SOS, unter Ausnutzung der Zugriffspfade und nimmt eine Auswertung der Relationenalgebra-Operatoren

vor, da diese die Antwortzeiten auf eine Anfrage entscheidend beeinflussen. Zwar weist [S 53 [SHS05]] darauf hin, dass vor allem ältere Datenbanksysteme diese Schicht nicht besitzen, für diese Forschungsarbeit ist aber vor allem der neuste Stand der Technik relevant, weshalb diese Tatsache außen vor gelassen werden kann.

Satzorientierte Schnittstelle (SOS) - Sie bewerkstelligt den Zugriff auf die innere Darstellung der Relation und nutzt dabei Zugriffspfade (Indexe, Scans) und typisierte Datensätze, sowie interne Relationen.

Zugriffssystem - Aufgabe des Zugriffssystems ist es, die konzeptuellen Darstellungen (Relationen, Tupel) auf interne Darstellung (Seiten) abzubilden. Im Zugriffssystem selbst werden nur interne Tupel bzw. logische Datensätze betrachtet. Operationen im Zugriffssystem sind das Einfügen, Löschen, Modifizieren und Suchen von Sätzen in Scans und Indexen.

Darüber hinaus übernimmt es die Sortierung und die Mehrbenutzerverwaltung von Transaktionen sowie Transformation auf die ISS.

Interne Satzschnittstelle (ISS) - In der ISS werden Tupel ohne Typisierung einheitlich verwaltet. Zudem sind Speicherstrukturen der Zugriffspfade implementiert.

Speichersystem - Das Speichersystem setzt die Operationen der ISS auf virtuelle Adressen des Adressraums um. Anwendungsobjekte sind in ihrer internen Speicherdarstellung sichtbar, werden jedoch nicht direkt (physisch) umgesetzt, sondern abstrakt als interne Datensätze beschrieben. Des Weiteren ist es auch für die Sperrverwaltung im Mehrbenutzerbetrieb und das Schreiben des Logbuchs zuständig. Eine Übersicht über die Bezeichnungen je Systemeben findet sich in Tabelle 1.

Systemebene Strukturelle Bezeichnung

Datensystem Tupel

Zugriffssystem Internes Tupel oder logischer Datensatz

Speichersystem Interner Datensatz

Tabelle 1: Strukturelle Bezeichnungen zu Systemebenen

Systempufferschnittstelle (SPS) - Sie manipuliert den virtuellen Adressraum, welcher durch Seiten und Seitenadressen realisiert wird.

Pufferverwaltung - Sie bildet interne Seiten auf Blöcke der Dateischnittstelle des Betriebssystems ab und speichert Daten im Primärspeicher zwischen. Sie übernimmt die Zuteilung von Speicherplatz für Seiten und das Suchen und Ersetzen von Seiten im Zwischenspeicher (Puffer). Darüber hinaus ist sie für die Optimierung der Lastverteilung zwischen parallel laufenden Transaktionen zuständig. Die Pufferverwaltung bildet die Seiten der SPS auf Blöcke der DSS ab.

Dateischnittstelle (DSS) - Die DSS realisiert Operationen auf Blöcken des externen Speichers. Dies ist jedoch Aufgabe des Betriebssystems und unabhängig vom DBMS.

2.3.3. Speicherhierarchie

Um die Vorteile der selbstverwaltenden Eigenschaften eines DBMS zu verstehen, ist ein Verständnis der Speicherhierarchie eines Computers notwendig. [S 83 [SHS05]] geht davon aus, dass der Geschwindigkeitsunterschied zwischen Festplattenspeicher und Cache des Prozessors ca. das 10⁶-fache beträgt. Dieser Unterschied wird auch als Zugriffslücke bezeichnet. Um dieser Zugriffslücke entgegen zu wirken, macht sich das DBMS die Dreiteilung des Speichers zu nutze. Der kleinste und schnellste Speicher (Cache) lädt die gerade benötigten Daten, der Arbeitsspeicher hält die wichtigeren Daten im größeren Sinne und der Festplattenspeicher alle anderen Daten in der Datenbank bis auf die archivierten Daten, welche sich auf Magnetbändern befinden. Durch diese Abstufung der Abhängigkeiten muss bei einer fehlenden Information die Speicherinstanz im optimalen Fall lediglich auf die direkt unter ihr liegende Schicht zugreifen und hat somit einen Geschwindigkeitsvorteil der sich laut [S 83 [SHS05]] um das 10³-fache bewegt.

Die Zwischenspeicherung wird zudem notwendig, da sich Primär-, Sekundär und Tertiärspeicher neben der Geschwindigkeit, auch in Größe, Preis und Vorhaltezeit unterscheiden.

Abbildung 8: Unterscheidung Primär-, Sekundär-, und Tertiärspeicher

Tritt jedoch der ungünstigste Fall ein und eine benötigte Information ist in keiner direkt angrenzenden Speicherinstanz vorhanden, müssen die Informationen dennoch von den langsamsten Medien geladen werden.

2.3.4. Verwaltung des Hintergrundspeichers

Der Hintergrundspeicher umschreibt eine physische Ablage der Daten auf einem externen Speichermedium. Zwar ist die Verwaltung des Hintergrundspeichers Aufgabe des Betriebssystems, der Vollständigkeit halber wird jedoch darauf eingegangen, da sich weiterführende Grundlagen, welche unmittelbar für das Verständnis eines DBMS benötigt werden, damit besser einordnen lassen. Vor allem dient dieses Kapitel dem Verständnis, wie abstrakte Speichereinheiten (Seiten) eines DBMS physisch abgelegt werden. Nur so kann nachvollzogen werden, weshalb beispielsweise eine wiederkehrende Defragmentierung (Wartungsarbeiten) dem System unnötige Arbeit ersparen kann.

Das DBMS hat keinen Direktzugriff auf die Festplatte, sondern nutzt vom Betriebssystem angeforderte Dateien um Daten zu speichern. Eine Datei ist eine abstrakte Ordnungseinheit, welche das Betriebssystem verwaltet und über eine Transformation in kleinere, physische Einheiten (Blöcke) auf der Festplatte festschreiben kann. Das Betriebssystem übernimmt somit die Beschreibung der Magnetplattenspeicher für das DBMS, indem es Daten des DBMS in physische Blöcke auf die Festplatte schreibt.

Abbildung 9: Festplattenaufbau

Da die Blöcke der Festplatte jedoch relativ klein sind (512Byte), abhängig von der genutzten Formatierung des Datenträgers, müssen zusammenhängende Daten des DBMS geteilt werden.

Aus diesem Grund wird eine eigens für das DBMS entworfene, abstrakte Speichereinheit (Seiten) genutzt, welche physisch vom Betriebssystem umgesetzt werden kann. Die Zuordnung der physischen Blöcke zu Seiten wird mit einem festen Faktor vorgenommen. Es werden häufig 1,2,4 oder 8 Blöcke, die auf der Festplatte hintereinander liegen und damit in einer physischen Spur sind, zu einer Seite vereinigt (siehe Abbildung 9). Das DBMS selbst adressiert die Seiten über Seitennummern. Bei der Allokation von Speicher durch das DBMS werden aufeinanderfolgende Seiten zwar auch physisch aufeinander folgend sein, jedoch werden sich durch Änderungsoperationen im Laufe der Zeit Fragmentierungen (Verstreuungen) einstellen. Eine solche Entartung von zueinander gehörenden Daten kann das System zusätzliche Zeit kosten, da der Lesekopf mehrfach die Position wechseln muss.

Die vorgenommene Abbildung der internen, virtuellen Struktur auf die externe, physische Struktur ist in Tabelle 2 aufgeführt.

Konzeptuelle Ebene Relation Tupel Attributwert

↓ ↓ ↓

Interne Ebene Logische Datei Datensätze (Records)

Felder

↓ ↓ ↓

Dateisystem/ Festplatte Physische Datei Seiten/ Blöcke Bytes

Tabelle 2: Abbildung der Speicherstrukturen

Zur besseren Veranschaulichung werden in Abbildung 10 die Abhängigkeiten der konzeptuellen und internen Ebene sowie des Dateisystems ausgehend von einer virtuellen Relation aufgezeigt.

Abbildung 10: Darstellungen einer Relation (vgl. [SHS05])

Die darüber hinaus gehenden Blockungstechniken, welche aufzeigen mit welchen Techniken Datensätze auf mehrere Blöcke verteilt werden, sind nicht Bestandteil dieser Forschungsarbeit. Für nähere Informationen sei auf [S 99 [SHS05]] verwiesen.

2.3.5. Seiten, Sätze und Adressierungen

Als vorletzte Grundlagendarlegung dieser Arbeit sollen Seiten, interne Datensätze und ihre Adressierung näher beleuchtet werden. Wie bereits im vorangegangenen Kapitel kurz angerissen, sind Seiten Speicherobjekte, in denen das DBMS Informationen (Tupel, Datensätze) ablegt. Seiten sind ein Zusammenschluss von zumeist 1,2,4 oder 8 Blöcke der Festplatte und das DBMS adressiert diese Seiten über Seitennummern. Nicht genutzte Seiten verwaltet die Freispeicherverwaltung des DBMS und gibt diese, sobald sie angefordert werden, frei. Zusammenhängende Seiten können als eine doppelt-verkettete Liste angesehen werden, da jede Seite einen Eintrag für Vorgänger und Nachfolger enthält. Eine Seite besteht aus einem Header, gegebenenfalls eingetragenen Datensätzen und nicht belegtem Speicherplatz. Der spezifische Aufbau des Seitenkopfes (Page-Header) variiert dabei von DBMS zu DBMS. In den meisten Fällen befinden sich dort jedoch die Angaben zur Seitennummer, die Vorgänger- und Nachfolgerseite sowie die Offset-Werte³.

Ein Offset-Wert referenziert einen Datensatz innerhalb der Seite. Wird der Datensatz verschoben, muss lediglich der Offset-Wert verändert werden. Alle von außerhalb gesetzten Referenzen verweisen nicht direkt auf den Offset-Wert, sondern auf einen Tupelidentifikator (TID). Dieser TID besteht aus einer Seitennummer und einem bestimmten Offset-Wert und wird nicht verändert.

Abbildung 11: Tupelidentifikator

Darüber hinaus sind die TIDs nützliche Werkzeuge für Verweise bei Veränderungen, wenn z.B. ein Datensatz von einer Seite auf eine andere verschoben werden musste. Der TID bleibt bestehen, der Offset-Wert verweist auf dieselbe Stelle, nur steht an dieser Stelle kein

3 Der Offset-Wert ist dabei gleich der Anzahl der Bytes vom Anfang des Speicherplates auf der Seite bis zum Datensatz. Er spiegelt somit die Position des Datensatzes auf der Seite wieder.

Datensatz mehr, sondern ein weiterer TID, welcher auf die neue Seite und den neuen Offset- Wert verweist.

2.3.6. Transaktionen

Als letzte Grundlagendarlegung dieser Arbeit sollen die bereits mehrfach erwähnten Transaktionen ausgeführt werden. Transaktionen beruhen auf dem Prinzip, dass auf einer Datenbank mehrerer Benutzer, Applikationen oder andere Instanzen potentiell zur gleichen Zeit auf dieselben Daten zugreifen können. Dieses muss geregelt werden, damit anschließend keine fehlerhaften Zustände zurückgelassen werden können. Eine Transaktion vereint eine Serie von einzelnen Operationen, die die DB von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen. Die Überführung muss dem ACID-Prinzip genügen, welches ein Akronym ist und sich aus den Anfangsbuchstaben der vier englisch übersetzten Eigenschaften zusammensetzt. Im Zuge dieser Arbeit werden zwar die vier Eigenschaften genannt und kurz erläutert, jedoch ist das Gebiet der Transaktionsverwaltung weitaus umfangreicher und kann in dieser Forschungsarbeit nur angeschnitten werden. Für tiefergreifende Informationen wird auf [S 22 ff. [SHS05]] verwiesen.

Das ACID-Prinzip setzt sich zusammen aus nachfolgenden Eigenschaften:

Atomicity (Atomarität) - Die Ununterbrechbarkeit einer Transaktion, spiegelt den Fakt wider, dass eine Transaktion vollkommen oder überhaupt nicht ausgeführt werden darf. Es existieren demnach keine Zwischenzustände, welche eventuell inkonsistent sein könnten.

Consistency (Konsistenz) - Die Integritätserhaltung sorgt dafür, dass eine Transaktion das System aus einem konsistenten Zustand nur in einen konsistenten Zustand überführen kann.

Isolation - Auch wenn mehrere Transaktionen gleichzeitig ablaufen und deren Schritte ineinander verzahnt sind, muss der Ergebnis einer Transaktion gleich dem Ergebnis sein, als wären alle Transaktionen sequenziell abgelaufen.

Durability (Dauerhaftigkeit) - Einmal beendete Transaktionen sind dauerhaft in die Datenbank festgeschrieben.

Zwei wichtige Gegebenheiten, die im Zuge der Transaktionen jedoch noch erwähnt werden müssen, sind Sperren (Locks) und Deadlocks. Zur Realisierung des gemeinsamen Zugriffs auf Datenobjekte werden Sperren verwendet, welche eine Exklusivität gegenüber anderen

zugreifenden Instanzen sicherstellen. Wird somit eine Sperre von einer Transaktion auf ein Objekt gesetzt, kann eine andere Transaktion bis zur Aufhebung der Sperre nicht auf das Objekt zugreifen. Es gilt im Groben, Lese- und Schreibsperren zu unterscheiden. Für weitere Informationen wird auf [S 576 [SHS05]] verwiesen.

Deadlocks sind Verklemmungen, welche entstehen, wenn zwei oder mehrere unterschiedliche Transaktionen zwei oder mehrere unterschiedliche Objekte sperren und vor der Endsperrung auf das jeweils bereits gesperrte Objekt der anderen Transaktion zugreifen möchten. In diesem Fall wartet der eine auf den anderen und dieser Umstand muss vom System erkannt und aufgelöst werden.

2.4. Marktanalyse derzeitiger Datenbanksysteme

Wie bereits in den frühen siebziger Jahren des letzten Jahrhunderts, sind auch heutzutage viele Hersteller von DBMS am Markt vertreten. Aus diesem Grund spezialisieren sich viele Anbieter auf bestimmte Teilbereiche oder fokussieren einzelne Nischen viel stärker als andere Marktteilnehmer. So wurde mit dem SQL Server 2012 der Columnstore Index⁴ eingeführt, um das Produkt im Segment Data Warehouse noch interessanter zu machen (vgl. [BF11]). Oracle erweiterte Oracle Database 11g Release 2 ausschließlich auf Oracle Linux und Oracle Solaris um den Oracle Database Smart Flash Cache⁵, damit deren Marktposition im RDBMS unterstützt wird. Andere RDBMS wie Teradata konzentrieren sich fast ausschließlich auf das Data Warehousing und stimmen sämtliche Neuentwicklungen auf den typischen Workload eines solchen ab.

Die genaue Bezifferung aller derzeit existierenden DBMS variiert zwischen 54 lt. [FTB12]

und 100 lt. [Wiki01] und ist abhängig vom Blickwinkel des Betrachtenden sowie strengen oder weniger strengen Merkmalen, die beschreiben was genau ein DBMS ausmacht und ab wann es eigentlich nicht mehr so genannt werden dürfte. Diese Arbeit hält sich an die

4 Der Columnstore Index speichert die im Index angegebenen Spalten separat auf eigenen Seiten gespeichert.

Benötigt eine Anfrage nun spezielle Werte aus einer Spalte, können aus dem Index heraus gezielt die Spaltenseiten geladen werden.

5 Mit dem Oracle Database Smart Flash Cache lässt sich der Pufferspeicher durch einen Flash-Speicher erweitert. Somit kann mit einem größeren Second Level Cache gearbeitet werden, was lese-intensive Datenbankapplikationen unterstützt.

Definition nach Codd, welche im Abschnitt 2.3.1 vorgestellt wurde und bezeichnet ein DBMS als genau solches, wenn es die neun Codd'schen Regeln erfüllt.

Zu den wohl bekanntesten DBMS gehören der SQL Server von Microsoft, Oracles Oracle Database und IBMs DB2, welche bereits im Abschnitt 2.2 einführend erläutert wurden. Diese drei Datenbanksysteme decken zusammen mehr als 80% des Marktes ab (vgl. [DBR11], [MW11]). In Segmenten wie Business Intelligence (BI) und Corporate Performance Management (CPM) halten sie lt. [DBR11] zusammen eine Zweidrittelmehrheit. Allein Oracle deckte in einer Erhebung (siehe Tabelle 3) aus 2009 43,4% des Marktes ab. Diese Marktdominanz konnten sie bis in das Jahr 2011 noch weiter ausbauen, indem sie laut [DBR11] im dritten Quartal 2011 48,1% des Marktes beherrschten und sich erst unlängst damit brüsteten, dass sie mehr Marktanteile hätten, als ihre fünf größten Verfolger zusammen (vgl. [Orac01]). Neben diesen drei großen kommerziellen DBMS, sollen noch SAP MaxDB der deutschen Softwareschmiede SAP) sowie Terradata und deren gleichnamiges DBMS genannt werden, welche zusammen die Top 5 der DBMS-Anbieter bilden und in Tabelle 3 orange hinterlegt sind. Tabelle 3 zeigt zudem den prozentualen Anteil der Top 10-Systeme am Gesamt-Umsatz des Jahres 2009 je Betriebssystem ("Worldwide RDBMS 2009 Vendor Analysis: Top 10 Vendor License Revenue by Operating Environment") auf.

Company Unix Windows NT Linux/ Open Source Systems Other Entry Systems Mainframe Systems Other Server Systems Total Licence Revenue Maintenance Total Software Revenue

Oracle Corp. 51,9 22,9 63,8 - 0,1 2,4 31,8 57,0 43,4

IBM 19,6 13,1 16,7 10,7 90,3 46,3 25,9 15,1 20,9

Microsoft - 55,7 - - - - 26,3 14,0 20,6

Sybase (SAP) 7,3 1,8 2,2 30,7 - - 2,7 3,8 3,2

Teradata 12,4 0,3 6,8 - - - 3,7 2,5 3,1

Fujitsu 1,8 0,9 0,4 - 1,4 - 1,0 1,4 1,2

Progress Software 1,6 0,7 0,2 - - 0,4 0,7 1,1 0,9

Netezza - - - 22,6 0,9 0,2 0,6

SAS Institute 0,3 0,3 0,0 - 2,2 0,3 0,5 0,4 0,5

Hitachi 0,6 0,2 0,2 - 0,8 - 0,4 0,3 0,3

Other 4,6 4,2 9,5 58,6 5,0 28,0 6,2 4,0 5,2

Total 100 100 100 100 100 100 100 100 100

Tabelle 3: Top 10-DBMS-Anbieter 2009 (vgl. [IDC09])

Neben den kommerziellen Systemen existieren jedoch auch kostenfreie Systeme, welche auch als Open-Source-Systeme bezeichnet werden. Zu deren bekanntesten Vertretern gehören MySQL und PostgreSQL. Eine relativ aussagekräftige Markteinschätzung gab Jelastic, die eine gleichnamige auf Java basierende Entwicklungsumgebung für die Cloud entwickeln, am 19. Oktober 2011 heraus. Sie befragten fünftausend Programmierer ihrer Plattform, welches Open-Source-System sie benutzen würden, wobei MySQL als eindeutiger Gewinner hervorging.

2.4.1. DBMS-Bezug in dieser Arbeit

Im Zuge dieser Forschungsarbeit werden die DBMS der drei Branchenriesen Oracle, Microsoft und IBM untersucht und für Vergleiche herangezogen, da deren Position und Präsenz allüberschattend und maßgebend ist. Auch wenn angemerkt werden muss, das viele Impulse und Neuerungen von Open-Source-Systemen kommen. Darüber hinaus sind auf Grund der niedrigeren hierarchischen Ebenen und der demokratischen Struktur der Open- Source-Systeme, die Anpassbarkeit und Variabilität weitaus größer.

3. Grundlagen zu Self-Healing und Self-Protection

In diesem zweiten Grundlagenkapitel wird die Herkunft und Entstehung von Self-Healing- und Self-Protection-Mechanismen aufgezeigt. Dazu wird das Autonomic Computing als Ursprung identifiziert und es wird eine Abgrenzung gegenüber anderen Wissenschaftsbereichen vorgenommen. Abschließend soll in diesem Kapitel explizit auf die beiden Mechanismen eigegangen werden.

3.1. Einordnung in das Autonomic Computing

"Was man heute als Science Fiction beginnt, wird man morgen vielleicht als Reportage zu Ende schreiben müssen." Norman Mailer

In fast jedem der heutzutage auf dem Markt befindlichen DBMS (siehe [Wiki01], [FTB12]) werden Funktionen wie Management des flüchtigen Speichers, Festspeichermanagement sowie Backup und Recovery vom System selbst durchgeführt. Zudem werden heutige Systeme nur noch selten heruntergefahren und können neue Hardware dynamisch integrieren, ohne dass es Applikationen in irgendeiner Art beeinflusst. So bietet der SQL Server 2008 beispielsweise ein "Hot-add CPU"-Feature an, welches es ermöglicht, dem System während des Betriebes zusätzliche CPUs hinzuzufügen. Vor nicht allzu langer Zeit mussten jede Art der Konfigurationen oder Systemanpassung noch von den DBAs selbst durchgeführt werden oder zumindest initial eingestellt werden, damit das System lauffähig wurde. Außerdem waren die Wahrung der dauerhaften Betriebsfähigkeit und der daraus resultierende Bedarf in kritischen Situationen zu jeder Uhrzeit Unterstützung beziehen zu können, wichtige Aspekte.

All diese administrativen Aufgaben sind nicht nur äußerst zeitaufwendig, sondern erforderten auch ein großes Wissen über das System selbst sowie viel Erfahrung im Umgang mit DBS.

Um diesen Umstand zu beseitigen, sollten die Systeme mit Fähigkeiten ausgestattet werden, die eine allumfassende Selbstverwaltung erlauben. Unter anderem aus diesen Überlegungen heraus entstand eine Initiative, welche autonom arbeitende Computer (Autonomic Computing) etablieren wollte. In fast allen sich darauf beziehenden Publikationen wird genau diese Initiative als Ursprung der Idee eines autonom arbeitenden Computersystems gesehen (vgl.

[KC03], [GC03], [CPW03]).