Aufgabe 1 (40 Punkte)

Aufgabe 1 (40 Punkte)
Diskutieren Sie folgenden Ansatz und nehmen Sie Stellung:
Bei der Implemenatition der Indexverwaltung, die als Binary Trees verwirklicht werden, verzichtet der DBMSHersteller darauf, nicht mehr benötigte Index-Pages freizugeben.
1) Begründen Sie die Überlegung des DBMS-Herstellers.
2) Welche Konsequenzen hat das z.B. für folgende Situation: in einem Transaktions-orientierten System sollen
die Transaktionen durch einen Timestamp gekennzeichnet werden. Es ist mit hohem Transaktionsaufkommen zu
rechnen. Drei Monate alte Transaktionen werden, um Platz zu sparen, komprimiert und aus der Datenbank
entfernt.
1.) Ein Index ist häufig als Btree organisiert, das DBMS stellt die entsprechenden
schnellen Suchmethoden bereit. Eine Organisation der Daten als Bbaum spart
Zugriffszeit ein.
Der Binär-Baum muss nicht neu durchsortiert und angeordnet werden. Bei
jedem INSERT, UPDATE oder DELETE muss der Index neu aufgebaut werden.
Eine solche Änderung ist unter Umständen mit hohem Aufwand verbunden.
Die Beschleunigung, die SELECT-Anweisung durch den Aufbau von Indexen
erfahren, wird bei hoher Änderungsfrequenz möglicherweise aufgewogen
durch den hohen Änderungsaufwand. Deshalb sollten Indexe sorgfältig
bedacht werden. DBMS verzichten deshalb auf eine Neuordnung.
Reorganisation:
von der Implementation abhängig, gilt unter anderem für die von DB2
implementierten Indexe.
Wir ein Index auf einer Spalte errichtet, die mit monoton steigenden Werten
gefüllt wird, so wächst der Index weiter, auch wenn frühe Dateneinträge
gelöscht werden. Es erfolgt in diesem Falle nicht, wie man erwarten würde,
eine Freigabe der nicht mehr benötigten Indexseiten. Die Indexeinträge sind
zwar gelöscht, aber die Seiten werden für neue Indexeinträge vorgehalten.
Aufgrund der monoton wachsenden Werte wird dieser Bereich aber nicht mehr
mit neuen Indexeinträgen gefüllt.
Für solche Index-Organisation muss – je nach Änderungsvolumen der Tabelle
– von Zeit zu Zeit eine vollständige Reorganisation des Index, d.h. Löschen
und Neuanlegen, vorgenommen werden.
2.) Löcher im Baum, da 3 Monate alte Transaktionen entfernt werden.
Performance wird vermindert, da Äste des Baumes ins Leere zeigen
Aufgabe 2 (20 Punkte)
Welche Berechtigung gibt es für den DRDA-Ansatz, da ja ODBC bereits lange etabliert ist?
ODBC ist eine standardisierte Schnittstelle für den Zugriff auf relationale Datenbanksysteme.
Sie wurde ursprünglich von Microsoft spezifiziert, hat sich aber inzwischen zu einem
betriebsübergreifenden, allgemein akzeptierten de facto-Standard entwickelt. Mittels ODBC
kann auf jede Datebank, für die ein ODBC-Treiber existiert, zugegriffen werden. ODBC stützt
sich auf eine standardisierte SQL-Version. Dadurch ist es möglich, die Anwendung
unabhängig von einer spezifischen Datenbank zu programmieren. ODBC kann jedoch
ausschließlich von C- und C++-Programmen verwendet werden. Es wurde ursprünglich für C
entwickelt und ist daher nicht objektorientiert. ODBC stellt dem Programm ganzzahlige Werte
als handles und Zeiger auf Strukturen zur Verfügung, die von der Anwendung zu verwenden
sind. Der Verzicht auf Objektorientierung und der Zugriff mittels Zeigern machen ODBC
relativ fehleranfällig.
Eine verteilte Datenbank soll dem Benutzer - interaktiver Benutzer oder
Anwendungsprogramm - die Moeglichkeit bieten, mit auf verschiedenen Rechnern verteilten
Daten genauso zu operieren, als wären sie in dem lokalen DBMS (Database Management
Systems) gespeichert.
Die Arbeitsweise von Distributed Databases baut darauf auf, dass ein SQL-Befehl ueber das
Netz zu dem DBMS gesandt wird, in dem die betreffenden Daten gespeichert sind. Jeder
SQL-Befehl wird so zu einem Nachrichtenpaar: SQL-Befehl hin und Antwort zurueck.
Wenn ein Unternehmen DB2, SQL/Base und Informix in seiner Client- Server-Welt
kombinieren moechte, ergeben sich zwei Probleme: - Die unterschiedlichen DB-Systeme
muessen sich untereinander verstaendigen koennen. - Die Anwendungen muessen ihre
SQL-Befehle unabhaengig von dem jeweiligen DBMS absetzen. Fuer ersteres bietet sich die
Standard-Schnittstelle DRDA (Distributed Relational Database Architecture) von IBM an, die
inzwischen von verschiedenen DB-Systemen genutzt wird. In der Praxis findet zur Zeit
allerdings nur eine rudimentaere Art der Zusammenarbeit statt ... Da aber DRDA keinen
Standard fuer die SQL-Befehle enthaelt, die zwischen den beteiligten DB-Systemen
verschickt werden, muessen die Anwendungsprogramme Disziplin ueben: Sie duerfen nur
SQL-Anweisungen aus dem kleinsten gemeinsamen Nenner aller DB-Systeme verwenden.
Das entspricht zur Zeit dem Befehlsumfang von DB2. Als Konsequenz aus diesen
Darstellungen ergibt sich, dass eine Distributed Database wenig hilfreich fuer verteilte
Systeme ist. Vorrangiger ist es: - die Daten so an die dezentralen Rechner zu verteilen, dass
keine oder nur wenige Zugriffe auf entfernte Datenbanken noetig sind; - nur Daten, die
weitgehend statisch sind, redundant zu halten (hierfuer genuegt File-Transfer als
Aktualisierungsmechanismus), waehrend Update-intensive Daten nur einmalig zentral
gespeichert werden; - statt SQL-Befehle ueber das Netz zu versenden, lieber
Funktionsaufrufe im Rahmen von Cooperative Processing zu versenden. Wer seine Daten
zu sehr streut, ist selbst daran schuld, wenn er sie hinterher wieder muehsam
zusammensuchen muss.
DRDA
Application
und
DBMS
können
auf
unterschiedlichen
Hardwareund
Betriebssystemplattformen basieren, im Falle von DUOW (distributed unit of work) können
auch die angesprochenen DBMS in einer Unit of work von unterschiedlichem Typ sein.
DRDA beschreibt
die Aktionen zwischen Application und Server, um folgende Funktionen
auszuführen:
- Verbindungsaufbau einschließlich Identifikation
- Binden der Hostvariablen und des SQL-Statements an ein entferntes DBMS
- Ausführung des SQL-Statements im entfernten DBMS für die Application und Rückgabe
der ermitteltenDaten
- Ausführen dymanischer SQL-Anweisungen für die Application und Rückgabe der
ermittelten Daten
- Unterstützung der Transaktionen
- Abbau der Verbindung
DUOW
pro Unit of Work kann auf mehrere DBMS mit Requests zugegriffen werden, die Anwendung steuert
die Verteilung der Zugriffe, pro Request kann jeweils nur ein DBMS angesprochen werden, die
Anwendung löst Commit aus, das als 2-Phasen-Commit die beteiligten DBMS koordiniert
Aufgabe 3 (15 Punkte)
SQL92 (full level) fordert eine einheitliche Struktur für das Data Dictionary. Wie können DBMS-Hersteller dies
verwirklichen, ohne ihre speziellen DBMS-Fähigkeiten und -Strukturen aufgeben zu müssen?
???
Der Katalog ("Data Dictionary") ist eine Menge von Tabellen, die vom Data Base
Management System (DBMS) selbst verwaltet werden. Diese Tabellen beschreiben
die Struktur der Datenbank, d.h. den Aufbau der übrigen realen und virtuellen
Tabellen, der Indexe und übrigen Objekte der Datenbank, aber auch Zugriffsrechte
einzelner Benutzer usw. ...
Aufgabe des DBMS ist es, die Daten in diesen Tabellen immer auf dem neuesten
Stand zu halten, so dass der Katalog den Zustand der Datenbank richtig beschreibt.
Jede Anweisung, die ein neues Objekt in der Datenbank erzeugt oder ein bereits
vorhandenes ändert, bewirkt indirekt eine Veränderung der Eintragungen im Katalog.
In SQL wird ein INFORMATION_SCHEMA gefordert, das aus einer Sammlung von
Datensichten besteht. Die Basistabellen, auf denen diese Datensichten beruhen,
werden ebenfalls im Standard aufgeführt. Das zugehörige Schema wird
DEFINITION_SCHEMA genannt. Es ist aber nicht so gemeint, dass ein
standardkonformes DBMS genau diese Basistabelle und Datensichten bereitstellen
muss. Das INFORMATION_SCHEMA kann und darf durch Datenbankhersteller
jederzeit erweitert werden, wenn dies für die Funktion des DBMS erforderlich ist....
Aufgabe 4 (20 Punkte)
Was ist Ihrer Einschätzung nach die Zielrichtung von Lotus Notes? Ist es ein Werkzeug, um rel. DBMS
abzulösen?
---
Aufgabe 5 (15 Punkte)
In der Regel wird Information aus einem OLTP-System in ein Data-Ware-House übernommen. Wie kann dies
geschehen? Zeigen Sie mehrere Möglichkeiten auf.
OLTP = Online Transaktion Processing, Transaktionssysteme, die interaktiv und mit
schnellen Antwortzeiten arbeiten
Ein DSS stellt an das DataWareHouse in der Regel nur lesende Fragen, die Zugriffe
sind also ReadOnly. Aus diesen Gründen können die Daten, die typischerweise aus
einem transaktionsorientierten OLTP-System kommen, während der Ruhephasen
des OLTP-Systems bereitgestellt werden. Eine Vorverdichtung ist dabei üblich, da
von einer Reihe von Detail-Informationen abstrahiert werden kann. Zudem reduziert
eine Vorverdichtung den Aufwand bei Anfragen an das System. Aus diesem Grunde
werden in der Regel stark denormalisierte Daten eingesetzt, d.h. anstelle der
"schlanken" Tabellen im OLTP werden im DataWareHouse "fette" Tabellen mit vielen
redundanten Spalten gespeichert; Joins werden vorab vollzogen, damit bei den
Anfragen die Performance nicht leidet.
Anlegen und Laden eines Data Warehouses vom OLTP





SQL-Anweisungen während off-Zeit des OLTP
Snapshot
Log sniffing
Insert-, Update-, Delete-Trigger
spezielle Data Extract Programme während off-Zeit des OLTP
SQL-Anweisungen während off-Zeit des OLTP
können insbesondere dazu benutzt werden, Pre-Joins anzulegen
Snapshot
Überführung einer Tabelle in das Data Warehouse
Ausnutzen von Replikation
Log sniffing
mit Spezialprogramm die Logs auf Änderungen untersuchen und diese in das
Data Warehouse einbringen
Insert-, Update-, Delete-Trigger
direktes Übernehmen jeder Änderung
spezielle Data Extract Programme während off-Zeit des OLTP
dieses Vorgehen bietet die besten Möglichkeiten, vor dem Einfügen Daten zu
aggregieren
Aufgabe 6 (25 Punkte)
Zugriffe auf eine Datenbank, die von Ihnen administriert wird, werden ein paar Wochen, nachdem die gesamte
Anwendung installiert wurde, merklich langsamer. Dabei hat sich nichts an den Anwendungen, die auf die
Datenbank zugreifen, geändert.
Welche Überlegungen stellen Sie an?
-
Reorganisation von Tabellen und Indexen, wenn Datenmenge zu groß,
Anzahl der gespeicherten Dateien.
Optimizer hinzufügen, bzw. Hilfestellungen dem Optimizer geben
SQL-Anweisungen anders formulieren
Einführen redundanter Datenhaltung
Optimistisches Synchronisationsverfahren, evtl. zuviel Sperren, manuell
durch lock abhelfen
Aufgabe 7 (15 Punkte)
Es wird eine spezielle Anwendung für die Datenbank geplant, die (in großen Zeitabständen) gestartet werden
und dabei mehrere große Tabellen ,,updaten`` soll. Wie kann sichergestellt werden, dass diese Anwendung
deadlock-frei und möglichst effizient laufen kann? Was für Folgen hat Ihr Vorschlag für die Zeitpunkte, zu
denen diese Anwendung gestartet werden sollte?
-
setzen manueller Sperren
Zeitpunkt: nachts
optimistisches Synchronisationsverfahren
batchverarbeitung
evtl. Timestamp setzen
Mit der Benutzung von Sperren ist ein Problem verbunden: wird in einer Transaktion
ein Objekt verändert und damit gesperrt, so kann eine andere Transaktion auf dieses
Objekt erst nach dem Ende der ersten Transaktion zugreifen. Was passiert aber,
wenn eine andere Transaktion auch ein Objekt ändert und somit sperrt und wenn die
Transaktionen wechselseitig auf die gesperrten Objekte der jeweils anderen
Transaktion zugreifen wollen?
Dies ist die typische Verklemmung, auch Deadlock genannt. Erst das Abbrechen einer der
beteiligten Transaktionen mit der ROLLBACK-Anweisung gibt die vormals gesperrten
Objekte wieder frei, die verbleibenden Transaktionen können nun weiterarbeiten.
Die abgebrochene Transaktion muss zu einem späteren Zeitpunkt wiederholt
werden.
Normalerweise sind Sperrmechanismen nicht notwendig, da SQL die Sperren
automatisch anfordert. Der Benutzer kann aber auch manuell Sperren setzen. Dies
ist gerade bei umfangreichen Transaktionen sehr nützlich. Eine Sperre kann vom
Benutzer durch die Anweisung
LOCK TABLE table_name [IN EXCLUSIVE MODE | IN SHARE MODE]
anfordern. Mit dem Zusatz IN EXCLUSIVE MODE ist Tabelle bis zur COMMIT- bzw.
ROLLBACK-Anweisung für alle anderen Benutzer gesperrt. Soll die Tabelle hingegen
nur zum Lesen gesperrt werden, so wird das bewirkt durch IN SHARE MODE.
Gerade bei eingebetteten SQL-Anweisungen in Programmen, in denen lange
Transaktionen aufgebaut werden, ist eine sorgfältige Prüfung des Zeitpunktes, zu
dem die Sperren gesetzt werde, und eine Analyse, welche Sperren aufgebaut
werden müssen, zwingend erforderlich.
Zur schnelleren Ausführung der Abarbeitungen empfiehlen sich Batches.
Zum Schutz gegen Deadlocks bieten die DBMS'e weiterhin das optimistische
Synchronisationsverfahren an. Diese Systeme gehen von der Annahme aus, dass
Konflikte zwischen Transaktionen seltene Ereignisse darstellen und somit das
präventive Sperren der Objekte unnötigen Aufwand verursacht. Daher greifen diese
Verfahren zunächst nicht in den Ablauf einer Transaktion ein, sondern erlauben ein
nahezu beliebig paralleles Arbeiten auf der Datenbank. Erst bei Transaktionende
wird überprüft, ob Konflikte mit anderen Transaktionen aufgetreten sind. Gemäß
dieser Vorgehensweise unterteilt man die Ausführung einer Transaktion in drei
Phasen:
- Lesephase
- Validierungsphase
- Schreibphase
In der Lesephase wird die eigentliche Transaktionsverarbeitung vorgenommen, d.h.
es werden Objekte der Datenbank gelesen und modifiziert. Jede Transaktion führt
dabei ihre Änderungen auf private Kopien in einem ihr zugeordneten
Transaktionspuffer durch, der für keine andere Transaktion zugänglich ist.
Validierungsphase
Im Gegensatz zu Sperrverfahren, bei denen Blockierungen das primäre Mittel zur
Behandlung von Synchronisationskonflikten sind, werden hier Konflikte stets durch
Zurücksetzen einer oder mehrerer beteiligter Transaktionen aufgelöst. Es ist so mit
mehr Rücksetzungen als bei Sperrverfahren zu rechnen; andererseits können bei
optimistischen Verfahren keine Deadlocks entstehen.
Hat die Transaktion die Validierungsphase erfolgreich durchlaufen - und nur in
diesem Falle - werden die gepufferten Änderungen zurückgeschrieben;
Schreibphase! Dadurch werden die Änderungen für andere Transaktionen erst
sichtbar.
Aufgabe 8 (25 Punkte)
Beschreiben Sie, wie in Embedded SQL, in CLI und in JDBC der Zugriff auf eine Ergebnistabelle erfolgt.
Embedded SQL:
Sollen SQL-Anweisungen im Quelltext eingebettet werden, so muss ein Precompiler
verwendet werden, um daraus den entsprechenden Code zu generieren, der
anschließend vom Compiler verarbeitet werden kann.
Zwischen Programm und eingebetteter SQL-Anweisung müssen Variablen
ausgetauscht werden können. Hierzu dienen die mit dem Doppelpunkt
gekennzeichneten Variablen. Sie werden als Hostvariablen bezeichnet und müssen
auch in der SQL-Anweisung dem Precompiler zugänglich sein. Die Einleitung des
SQL-Statements ist "EXEC SQL", das Endekennzeichen ist ";", diese sind jedoch
sprachabhängig.
EXEC SQL
INSERT INTO teile
VALUES (: t_tnummer, :t_tname, :t_minimum,
: t_gewicht );