4101

4101
Aufgabe 2 (35 Punkte)
Was ist die Aufgabe des Optimizers in einem DBMS? Beschreiben Sie verschiedene Ansätze für die Arbeitsweise eines
Optimizers. Wie vermeiden verschiedene DBMSe, dass diese Komponente unnötig oft aufgerufen wird?
 ermöglichen eine effiziente Ausführung der Anfragen durch das DBMS
 Beispiel: Finde einen Relationenalgebra-Ausdruck, der äquivalent ist ("das gleiche
Ergebnis liefert") zu einem vorgegebenen, der aber effizienter auszuwerten ist.
Eine Möglichkeit der Optimierung ist die sogenannte algebraische Optimierung. Hierbei
werden Algebra-Ausdrücke nach "Rechenregeln" in äquivalente Ausdrücke umgeformt
 Es gibt regel- und kostenbasierte Optimizer. Regelbasierte Optimizer versuche im
wesentlichen aufgrund von Regeln einen guten Zugriffspfad zu ermitteln; kostenbasierte
Optimizer versuchen hingegen, möglichst viele Strategien anhand der entstehenden I/O-,
Speicher-, Transport- und CPU-"Kosten" zu bewerten und die kostengünstigste Strategie zu
ermitteln.
Um dem Optimizer zu helfen, können neben den oben erwähnten Überlegungen
typischerweise noch Hilfen angegeben werden. So ermöglicht es
Oracle, dem Optimizer einen HINT – einen Vorschlag – mitzugeben, gewisse
Aspekte besonders zu beachten,
IBM in dem Produkt DB2, durch die Anweisung SET CURRENT QUERY
OPTIMIZATION nr den Optimizer mehr oder weniger Zugriffspfade bewerten zu
lassen.
Unnötige Aufrufe des Optimizers können verhindert werden, indem man dynamische SQLAnweisungen mit einer Prepare nur einmal den Zugriffspfad vom Precompiler ermittelen
lässt und sie danach mit execute ausführt. Der Zugriffspfad wird gespeichert.
Aufgabe 4 (25Punkte)
In einem relationalen DBMS soll jede Änderung an einer Tabelle demo protokolliert werden. Dabei soll der ändernde
Benutzer, Datum und Zeit sowie die Art der Änderung (als INSERT, UPDATE, DELETE) in eine entsprechend
strukturierte Tabelle demo_protokoll eingetragen werden. Wie müsste die Struktur der Tabelle demo_protokoll
aussehen, wie könnten die Einträge bewirkt werden?
 Die Einträge können durch einen Trigger bewirkt werden. Trigger können dazu benutzt
werden, zusammen mit Einschränkungen Integritätsregeln zu unterstützen, automatisch
Datenkonvertierungen vorzunehmen, Warnungen zu erzeugen, Daten zugleich in andere
Tabellen (z.B. aggregierte Werte) einzutragen usw. Veränderungen sind INSERT, UPDATE,
DELETE.
CREATE TABLE demo_protokoll
(
user
CHARACTER (10),
datum
date,
aenderung CHARACTER (6))
CREATE TRIGGER protokoll
AFTER UPDATE, INSERT, DELETE ON demo
oder or
FOR EACH ROW
WHEN INSERTED
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"insert")
END
WHEN UPDATED
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"update")
END
WHEN DELETED
Seite 1 von 6
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"delete")
END
Ich glaub nicht das man insert,update und Delete in einem Trigger
zusammen benutzen kann.
CREATE TRIGGER protokoll_update
AFTER UPDATE ON demo
FOR EACH ROW
BEGIN
INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"update")
END
und das gleiche dann für insert und delete
Aufgabe 5 (15 Punkte)
Aus einer Tabelle tab mit den Spalten nr, fach, regal (Integer) und ware (Character) sollen in einer JavaApplikation mittels JDBC alle Zeilen mit nr 10 ausgelesen werden.
Skizzieren Sie diesen Aspekt der Java-Applikation.
Bevor eine Verbindung aufgebaut werden kann, muss der gewünschte Treiber geladen
werden. Dies erfolgt z.B. über den Aufruf
Class.forName("jdbc.TreiberName");
Die Methode forName sucht, lädt und bindet die über den Namen angegebene Klasse
jdbc.TreiberName ein.
Connection verbindung = DriverManager(url, "userid", "passwort");
Statement anweisung = verbindung.createStatement();
ResultSet ergebnisse = anweisung.executeQuery
("SELECT * FROM tab WHERE nr = 10")
Aufgabe 6 (20 Punkte)
Was sind aus Ihrer Sicht die wesentlichen Unterschiede zwischen Embedded SQL und JDBC?
 JDBC ist eine Java-basierte Schnittstelle, die mit Hilfe der CLI –Schnittstelle eine
Übersetzung der SQL- Anweisungen während der Laufzeit durch die DBMS ermöglicht.
Inkonsistenzen zwischen der Hostsprach und SQL treten im Gegensatz
zu Embedded SQL nicht mehr auf.
 JDBC ist portabel und kann auf unterschiedliche DB-Systeme angewendet werden.
 Der gleichzeitige Zugriff auf mehrere DBMS ist mit DRDA möglich.
 Während bei Embedded SQL eine DB Verbindung mkit einem Einfachen CONNECT
erfolgt, muss bei JDBC zunächst ein Treiber geladen um eine Verbindung zum DBMS
herzustellen. Über die URL der Datenbank findet der DriverManager den passenden JDBCTreiber. Der DriverManager ist eine Fabrikklasse die alle geladenen Treiber verwaltet. Er
erzeugt ein Connection-Objekt, das die Datenbankverbindung repräsentiert. Alle SQLBefehle werden über dieses Objekt dynamisch gegen die Datenbank abgesetzt. Es wird ein
Statement-Objekt erzeugt, das die Versendung übernimmt. Für Anfragen und Änderungen
Seite 2 von 6
stellt das Statement-Interface die Methoden executeQuery und executeUpdate zur
Verfügung
 Embedded SQL verwendet einen Precompiler, die SQL-Anweisungen sind im Quelltext
eingebettet. Der Precompiler generiert aus diesem Text den entsprechenden Code, der
anschließend vom Compiler verarbeitet werden kann.
Die Einleitung ist EXEC SQL und das Endekennzeichen ";".
Aufgabe 7 (15 Punkte)
Welche Aufgabe hat die LOCK-Anweisung in einem DBMS? Warum fordert der SQL-Standard diese Anweisung nicht?
Will der Benutzer selbst Sperren anfordern, so muss er sich der Lock-Anweisung bedienen.
Soll z.B. die Tabelle lager zum Schreiben gesperrt werden – weil viele Einfügen und
Änderungen vorzunehmen sind - , so lautet die Anweisung
LOCK TABLE lager IN EXCLUSIVE MODE
und lager ist bis zur nächsten Commit- bzw. Rollback-Anweisung für alle anderer Benutzer
gesperrt. Soll die Tabelle hingegen nur zum Lesen gesperrt werden, so wird das bewirkt
durch
LOCK TABLE lager IN SHARE MODE
Da SQL automatisch Sperren anfordert, liegt der Vorteil einer expliziten Anforderung von
Sperren darin, dass in besonders gelagerten Fällen der Aufwand des Datenbanksystems,
viele Sperren aufzubauen, durch eine übergreifende Sperren-Anforderung verringert werden
kann. In einer Einbettung von SQL-Anweisungen in ein Programm kann der Programmierer
damit sicherstellen, dass die Transaktion immer beendet werden kann (Zwei-PhasenProtokoll mit Preclaiming und Sperren bis EOT), indem er rechtzeitig explizit Sperren setzt.
Diese Vorgehensweise behindert andererseits alle anderen Benutzer und Programme, da
der Parallelisierung durch die Sperren reduziert wird.
Sperrmechanismen sind nicht notwendig, da das DBMS für den Benutzer transparent die
notwendigen Sperren setzen und freigeben muss, um die Integrität von Transaktionen zu
garantieren.
Dennoch gibt es gute Gründe dafür, dem Benutzer zu ermöglichen, Sperren zu setzen.
Diese treten in der Regel nur bei umfangreichen Transaktionen zutage:
durch das Anfordern der nötigen Sperren kann ein Deadlock vermieden werden;
es kann garantiert werden, dass Batch-Arbeiten ungestört zum Abschluss
kommen,
je nach Implementation des Sperr-Managers kann eine Sperr-Eskalation
vermieden werden, d.h. es werden zunächst viele Objekte feiner Granularität
gesperrt, bis der Sperr-Manager "erkennt", dass wenige Sperren größerer
Granularität effektiver sind. Granularität bedeutet, dass von atomaren Werten bis
hin zu gesamten Klassenhierarchie unterschiedlich viele und unterschiedlich große
Daten und Objekte gesperrt werden können [Heuer, Objektorientierte
Datenbanken]
je nach Implementation kann dadurch die Anzahl der Aufrufe des Sperr-Managers
reduziert werden.
[Achilles, SQL, 232]
Aufgabe 8 (25 Punkte)
Was ist Replikation? Wie wird Replikation in gängigen RDBMS eingesetzt?
Replikation bedeutet, dass ein Datenobjekt mehrfach gespeichert wird. Dies steht im
Widerspruch zur Redundanzfreiheit der Datenbasis: jeder Fakt wird genau einmal
gespeichert. Der Grund für Replikation liegt in dem Ziel der besseren Erreichbarkeit von
Daten. Replikation - oder das Verlassen des Grundsatzes der Redundanzfreiheit - kann
Seite 3 von 6
auch bei einem zentralen DBMS benutzt werden, um die Performance zu steigern: Daten,
auf die von vielen Anwendungen "parallel" üblicherweise nur lesend zugegriffen wird,
können z.B. mehrfach gespeichert werden.
Eine besondere Rolle spielt Replikation aber in verteilten DBMS. Wird in einem verteilten
DBMS in einer Transaktion auf Datenobjekte zugegriffen, die auf einem entfernten Rechner
liegen, so treten folgende Probleme auf:



In der Regel hat man mit einer - im Vergleich zu den übrigen Operationen langsamen Verbindung zu tun, es muss eine Kommunikation zwischen den Rechnern
aufgebaut werden, die Transaktion dauert lange: die Daten sind "schwer" erreichbar.
Zusätzlich kann noch der entfernte Rechner stark belastet sein, was ebenfalls die
Daten schlecht erreichbar macht.
Ist die Verbindung zusammengebrochen, so kann die Transaktion nicht durchgeführt
werden: die Daten sind nicht erreichbar.
Als Vorteil ist jedoch anzusehen, dass die Transaktion immer aktuelle Daten erhält.
Will man nur lesend auf die entfernten Daten zugreifen, so wäre häufig schon damit gedient,
eine (ggf. nicht ganz aktuelle) Kopie der Daten lokal zu besitzen. Dann könnte direkt in
dieser Kopie gelesen werden, die obigen Probleme entfallen: die Zugriffsgeschwindigkeit
wird (in der Regel) wesentlich verbessert, die Zuverlässigkeit ebenfalls. Die entstehenden
Probleme sind einerseits beanspruchter Plattenplatz (in der Regel ein unwichtiges
Argument) sowie die Verletzung der Redundanzfreiheit. Dies ist ein Grund, weswegen das
Verteilungsschema sorgfältig durchdacht und geplant werden muss. Ein weiterer Grund wird
in der folgenden Überlegung deutlich.
Wird auf einem Knoten ein Replikat einer Tabelle angelegt, so nimmt die Verfügbarkeit der
Daten bei lesenden Transaktionen offensichtlich zu, das gesamte System wird gegenüber
Ausfällen stabiler. Ganz anders wirken sich hier Änderungstransaktionen aus: da jede
weitere Komponente die Ausfallwahrscheinlichkeit für das Gesamtsystem erhöht, eine
Änderung bei allen Replikationen im Prinzip "gleichzeitig" durchgeführt werden muss, treten
offensichtlich mit einer Erhöhung der Anzahl an Replikaten in diesem Falle Probleme auf, die
Aktualität der Daten sinkt.
Oracle:

Basic Replication:
Änderung auf Primärtabelle,
Datenverteilung asynchron auf Replikate
Replikate als Snapshot der Primärtabelle
Änderungs-LOG der Primärtabelle wird benutzt, um die Änderungen zu
propagieren
entspricht dem Primary Copy
Als Basic Replication wird in Oracle die letzte Version bezeichnet. Die
Änderungen erfolgen ausschließlich auf einer Primärtabelle, die Daten
werden asynchron auf mehrere Kopien repliziert. Eine Kopie wird
zunächst als ein Snapshot der Primärtabelle angelegt, die folgenden
Änderungen können entweder als Snapshot durchgeführt werden, was
in der Regel aufgrund des zu übermittelnden Datenvolumens sehr
kritisch ist, oder als "Fast-Refresh". Bei diesem Verfahren wird aus dem
Seite 4 von 6
Änderungs-LOG der Primärtabelle abgeleitet, welche Änderungen an die
Kopien zu übermitteln sind.
[Achilles, SQL]

Advanced Replication
Symmetrische Replikation mit asynchroner Aktualisierung
alle Replikate sind gleichberechtigt, Änderungen werden an alle übrigen
Replikate asynchron weitergereicht
keine Behandlung des DELETE-Konfliktes
Symmetrische Replikation von Tabellen wird in Oracle "Advanced
Replication" genannt. Dieses Vorgehen entspricht der asynchronen
symmetrischen Aktualisierung: alle Kopien sind gleichberechtigt, die
Änderungen werden an alle Kopien weitergereicht. eine Behandlung des
DELETE-Konflikts ist nicht vorgesehen.
[Achilles, SQL]

Änderbare Snapshots
Variante der Beiden vorhergehenden Arten:
Primärtabelle verteilt weiterhin die Änderungen asynchron an alle Replikate,
Replikate richten die Änderungsmitteilung mit Hilfe des INSTEAD OF-Triggers an
die Primärtabelle
Änderbare Snapshots einer Primärtabelle. Hier handelst es sich um eine
Variante beider vorhergehenden Arten: die Primärtabelle verteilt
weiterhin die Änderungen an alle Kopien, die Kopien richten mit Hilfe
des INSTEAD OF-Triggers die Änderungsmitteilungen an die
Primärtabelle.
[Achilles, SQL]

Symmetrische synchrone Aktualisierung:
(ROWA) ist nicht vorgesehen
DB2:
Replikationen werden durch den DataPropagatorRelational ermöglicht. Dieses
Produkt überwacht die Änderungen an Quelltabellen und schreibt diese Änderungen
in eine eigene Datenstruktur, von der aus sie nach bestimmten Zeiten oder auf
Anforderung an die Kopien weiter verteilt werden.
Real-Time Data Replication zur synchronen Aktualisierung innerhalb der
Transaktionsgrenzen muss durch Trigger und gespeicherte Prozeduren implementiert
werden.
[Achilles, SQL]

Asynchrone Aktualisierung unter Einsatz einer Primärtabelle:
es werden nur transaktions-konsistente, aber nicht transaktions-basierte Änderungen
verteilt
Verringerung der Netzbelastung, indem zwischen zwei Replikationszeiten
Änderungen zusammengefasst werden
Seite 5 von 6
Bei dieser Form werden nur transaktionskonsistente, aber nicht
transaktionsbasierte Änderungen verteilt. Der Unterschied liegt darin,
dass Änderungen hinsichtlich eines Records, die sich zwischen zwei
Replikationszeiten befinden, zu einer Änderung zusammengefasst
werden, um so die Netzbelastung zu verringern.
[Achilles, SQL]


Transaktions-basierte asynchrone Aktualisierung unter Einsatz einer
Primärtabelle
Primary Copy
Asynchrone Aktualisierung unter Einsatz einer Primärtabelle mit
änderbaren Kopien
sowohl Replikate als auch Primärtabelle erzeugen Änderungsmitteilungen,
Änderungsmitteilungen der Replikate gehen an Primärtabelle, die auf
Konsistenz überprüft,
Primärtabelle übernimmt Verteilung
Hier erzeugen sowohl die Kopien als auch die Primärtabelle
Änderungsmitteilungen,
die
transaktionsbasiert
sind.
Die
Änderungsmitteilungen der Kopien richten sich an die Primärtabelle, von
der aus sie allen anderen Kopien zur Verfügung stehen. Bei der
Übernahme der Änderungsmeldungen von Kopien wird auf
Dateninkonsistenz überprüft.
[Achilles, SQL]

Symmetrische synchrone Aktualisierung:
(ROWA) ist nicht vorgesehen
Seite 6 von 6