MARTIN-LUTHER-UNIVERSITÄT HALLE-WITTENBERG
Institut für Informatik
Prof. Dr. Stefan Brass

Die folgenden Informationen sind selbstverständlich nicht eine vollständige Liste aller möglichen Prüfungsfragen, sollten aber schon einen guten Anhaltspunkt für Ihre Vorbereitung geben. Eine vollständige Liste wäre auch deswegen nicht möglich, weil eine mündliche Prüfung auch immer etwas spontan ist. Sie werfen vielleicht ein Stichwort in die Debatte, was mich dann anregt, nachzufragen.

Diese Seite hat ein striktes Copyright (C) 2007 von Stefan Brass. Sie dürfen sie keinesfalls an anderer Stelle ins Netz stellen. Ich behalte mir vor, sie jederzeit wieder aus dem Netz heraus zu nehmen. Links auf diese Seite sind natürlich zulässig.

Beispiele für Prüfungsfragen

Allgemeines zu Oracle

• Diese Vorlesung ist sehr Oracle-lastig, da sie auch eine Hilfe für eine eventuelle Zertifizierung sein sollte. Für eine mündliche Prüfung sind aber nur wenige der sehr Oracle-spezifischen Informationen wichtig, und dann auch nur als konkretes Beispiel, wie man ein bestimmtes Problem lösen kann.
• Z.B. brauchen Sie keineswegs alle Data Dictionary Tabellen auswendig zu lernen, die im Skript aufgeführt werden. Natürlich sollten Sie das Konzept eines Data Dictionaries verstanden haben, und ich würde erwarten, daß Sie noch die Unterteilung in USER_*. ALL_*, DBA_* und vielleicht V$*, sowie auch die Tabellen CAT und DICT kennen. Irgendetwas sollte ja bei der ganzen Beschäftigung mit Oracle hängen geblieben sein. Aber im allgemeinen ist nicht das Ziel der Vorlesung, daß Sie viel auswendig gelernt haben. Viel wichtiger wäre, daß Sie ggf. eine Anfrage an das Data Dictionary in SQL formulieren könnten, wenn ich Ihnen das Schema der 2-3 relevanten Tabellen zeige. Bei Bedarf müssten Sie auch leicht eigene Data Dictionary Tabellen entwerfen können. Wenn Sie ein DBMS entwickeln würden, wie sollten dann z.B. die Data Dictionary Tabellen für Indexe aussehen? Falls Sie die Oracle Zertifizierung anstreben, müssten Sie dagegen schon genügend Tabellen auswendig wissen, so daß Sie bei Bedarf zumindest mit guter Aussicht raten könnten. Das ist eben der Unterschied zwischen einer akademischen Vorlesung und einer industriellen Zertifizierung.
• Entsprechend frage ich in der Prüfung auch nicht, wie man bei Oracle einen Benutzer anlegt oder eine Sitzung abbricht (obwohl das für einen DBA natürlich wichtige Dinge wären).
• Sie brauchen auch nicht alle Prozesse und Hauptspeicherbereiche von Oracle auswendig zu lernen, nur die wichtigsten/gröbsten Strukturen. Z.B. ist das verzögerte Schreiben der veränderten Blöcke und die Absicherung der Transaktionen mit den Redo Log Dateien schon eine konzeptionell wichtige Sache. Die sollten Sie verstanden haben.
• Die Extents sind die in Oracle verwendete Lösung des Problems, möglichst grössere Plattenbereiche am Stück zu belegen, und doch flexibel für dynamische Erweiterungen zu bleiben. Ich würde erwarten, daß Sie verstanden haben, wie das funktioniert, und auch die wichtigsten Parameter dazu aufzählen können. Wenn Sie noch andere Lösungen dieses Problems aus dem Selbststudium kennen, umso besser.
• Entsprechend sollten Sie Segmente und Tablespaces kennen. Ich denke schon, daß Sie nach dieser Vorlesung in der Lage sein sollten, auch die physischen Parameter bei CREATE TABLE Statements anzugeben, wenn Sie eventuell auch die Feinheiten der Syntax nochmal im Handbuch nachschauen müssten.

Platten und RAID-Systeme

• Selbstverständlich brauchen Sie nicht die Daten der Beispielplatte auswendig zu lernen. Die ist bei Ihrer Prüfung schon veraltet. Ich würde aber erwarten, daß Sie die ungefähren Größenordnungen wichtiger Parameter wissen. Z.B. sollten Sie wissen, wie lange das wahlfreie Lesen eines Blockes ungefähr dauert. Eine richtige (und leicht zu merkende) Antwort wäre 10 Millisekunden, aber Sie könnten auch 15 oder sogar 20 Millisekunden sagen (dann würde ich denken, Sie haben aber eine langsame Platte), umgekehrt wäre auch 5 Millisekunden eine richtige Antwort (das wäre schon sehr schnell). Aber Sie sollten Millisekunden nicht mit Nanosekunden verwechseln. Daraus können Sie sich auch herleiten, wie viele wahlfreie Blockzugriffe pro Sekunde möglich sind. Wenn Sie die Platte nicht bis zum Anschlag ausnützen (damit sich bei den normalen statistischen Streuungen keine langen Warteschlangen aufbauen) kommen Sie auf 70-80 Blockzugriffe. Schließlich sollten Sie wissen, wieviel man sequentiell von der Platte lesen kann, hier wäre wohl 20-100 MB/Sekunde der korrekte Bereich, vielleicht inzwischen auch noch ein bisschen mehr. Daraus sollten Sie ableiten können, wieviel schneller das sequentielle Lesen als das wahlfreie Lesen ist. Bei 40 MB/Sekunde sequentiell und 4KB Blöcken kommen Sie auf 10.000 Blöcke pro Sekunde sequentiell. Wenn Sie als Vergleich 100 Blöcke pro Sekunde wahlfrei nutzen, ist das sequentielle Lesen 100-mal schneller. Das lässt sich doch auch einfach merken.
• Sie sollten die üblichen RAID-Level kennen, und z.B. die Verteilung von Blöcken auf Platten bei einem RAID-Level mit einer gegebenen Anzahl Platten aufzeichnen können. Sie sollten sich bei Bedarf zurecht legen können, wie viele lesende/schreibende Blockzugriffe pro Sekunde dann wohl möglich sind, bzw. wie schnell sequentielles Lesen/Schreiben wohl gehen wird. Zum Teil sind dabei im Skript vereinfachende Annahmen getroffen worden. Wenn Sie durch Literaturstudium oder eigenes Nachdenken erklären können, warum sich das System wohl nicht ganz so verhält, oder was man eigentlich noch berücksichtigen müsste, umso besser (Sie können die 1.0 aber selbstverständlich auch nur durch Kenntnis des Skript-Stoffes erreichen). Falls Sie mit den Nummern der RAID-Level durcheinander kommen sollten, wäre das kein Beinbruch (sofern Sie die Konzepte noch wissen): Ich bin gegen reines Auswendiglernen.

Cache

• Sie sollten die Pufferung von Datenbank-Blöcken erklären können.
• Warum ist es wichtig, das auf die Blöcke nicht völlig gleichverteilt zugegriffen wird?
• Was ist eine gute "Hit Ratio"? Was kann man tun, wenn die Hit Ratio nicht gut genug ist?
• Sie sollten die Operationen "pin" und "unpin" erklären können. In diesem Zusammenhang könnte man auch auf die Unterschiede zum Betriebssystem zu sprechen kommen, das Plattenblöcke ja auch puffern würde.
• Wie funktioniert das LRU-Verfahren?
• Was ist das Problem beim "sequential flooding" des Puffers, und was kann man dagegen unternehmen?
• Was ist "Double Paging"?
• Warum lohnt sich das verzögerte Schreiben der Blöcke, wenn man doch zur Absicherung der Dauerhaftigkeit der Transaktion auf die Log-Datei schreiben muß?

Datenstrukturen für Relationen

• Das TID/ROWID-Konzept kommt häufig in Prüfungen vor. Sie sollten das Problem von verlängernden Updates kennen, und erklären können, wie das Tupel bei bekannter ROWID gefunden wird, und warum maximal zwei Blockzugriffe ausreichen (wenn das Tupel nicht länger als ein Block ist). Dazu müssen Sie natürlich die wesentlichen Komponenten der ROWID erklären können (Blockadresse und Tupelnummer im Block), und die Funktion des Row Directory im Block.
• Natürlich gibt es auch hier Alternativen. Es stellt sich z.B. die Frage, warum man nicht die Indexe aktualisiert, wenn man das Tupel verschieben muß. Sie sollten Vor- und Nachteile nennen können.
• Oracle verwendet den Parameter PCTFREE, mit dem man einstellen kann, wieviel Platz im Block für verlängernde Updates gelassen wird. Sie sollten die genaue Bedeutung dieses Parameters erklären können. Sie können aber sehr gerne auch irgendwelche Alternativen nennen, die Sie in der Literatur gefunden oder sich selbst ausgedacht haben. Im Skript ist eine Formel für PCTFREE angegeben. Sie brauchen diese Formel nicht auswendig zu lernen. Sie gilt ja nur unter ganz bestimmten Voraussetzungen, die häufig nicht zutreffen. Sich mit dieses Voraussetzungen zu beschäftigen, könnte aber vielleicht von Vorteil sein, um die Probleme der PCTFREE-Lösung zu erkennen.
• Sie sollten auch erklären können, wie Oracle einen Block findet, um ein Tupel einzufügen. Hier würde auch der Parameter PCTUSED eine Rolle spielen. Er ist in den Prüfungen bisher aber nur sehr selten drangekommen, PCTFREE deutlich häufiger. Auch beim Finden eines Blockes, der das neue Tupel aufnehmen kann, sind natürlich Alternativen denkbar. Überlegen Sie sich doch, wie Sie es machen würden, wenn Sie ein DBMS entwickeln würden.
• Im schlimmsten Fall muß Oracle das Segment verlängern (wenn es beim Einfügen gar keinen Block mehr gibt, der für die Relation reserviert ist, und noch Tupel aufnehmen kann). In diesem Zusammenhang sollten Sie vielleicht die Bedeutung von PCTINCREASE kennen. Toll wäre es auch, wenn Sie wüssten, daß sich bei Oracle mit dem "Local Extent Management" das Verfahren gegenüber der früheren Lösung mit dem Data Dictionary geändert hat. Aber das ist vielleicht ein bißchen sehr Oracle-spezifisch, und ist bisher noch bei keiner Prüfung dran gekommen. Aber andererseits ist es ja immer gut, mehrere alternative Lösungen für ein Problem zu kennen.
• Dann ist ein allgemeines Problem, wie beim Full Table Scan alle Blöcke gefunden werden, die möglicherweise Tupel enthalten. Oracle verwendet hier die "High Water Mark". Das hat zumindest den Vorteil der Einfachheit. Sie sollten aber auch eine Situation erklären können, in der sich diese Lösung sehr schlecht verhält.
• Das Tupelformat von Oracle sollten Sie zumindest ungefähr erklären können. Sie brauchen aber nicht auswendig zu lernen, wie lang der Row Header genau ist, oder ähnliche Details. Viel wichtiger wäre ein wenig über Alternativen nachzudenken, und wenigstens ein bißchen über Vor- und Nachteile sagen zu können. Das haben wir in den meisten Semestern in der Vorlesung besprochen, obwohl es nicht im Skript steht.
• In den Klausuren kam häufig vor, daß Sie den (minimalen) Platz für eine gegebene Relation ausrechnen sollten. Das kommt in einer mündlichen Prüfung eher nicht vor. Die Details der Länge von Datentypen und Headern brauchen Sie nicht auswendig zu wissen, und für eine eher langwierige Berechnung haben wir in der mündlichen Prüfung keine Zeit. Außerdem gibt es auch bei dieser Berechnung die unrealistische Annahme, daß alle Tupel gleich lang sind, oder wenigstens die Streuung schon innerhalb eines Blockes ausgleicht.

B-Bäume, Indexe

• Die B-Baum-Datenstruktur für Indexe sollten Sie gut kennen, sie kommt in fast jeder Prüfung vor. Wenn ich "B-Baum" sage, meine ich B+-Baum (oder B*-Baum), die originalen B-Bäume werden in Datenbanken ja eher nicht verwendet (ein sehr guter Student sollte erklären können, warum nicht).
• Manche Studierende verwechseln B-Bäume mit binären Suchbäumen. Das ist ziemlich übel, da wir uns in der Vorlesung ja länger damit beschäftigt haben. Sie sollten erklären können, warum binäre Suchbäume in Datenbanken (bei Speicherung auf Platten) nicht verwendet werden.
• Sie sollten die B-Baum Struktur (d.h. den B+-Baum, s.o.) definieren können. Was sind genau die Forderungen an die Balanciertheit? Warum fordert man keine perfekte Balancierung? In diesem Zusammenhang sollten Sie natürlich auch die Komplexität für Suchen, Einfügen, Löschen wissen: O(log(n)). Verwechseln Sie es nicht mit O(n*log(n)), das wäre ja schlimmer, als den Baum komplett durchzusuchen.
• Sie sollten in der Lage sein, ein einfaches Beispiel für einen B-Baum aufzuzeichnen, und daran dann z.B. auch eine Einfügung vorführen.
• Sie sollten wissen, welche Operationen der Relationenalgebra bzw. welche Arten von SQL-Anfragen mit einer B-Baum Indexstruktur beschleunigt werden. Auch Indexe über Attribut-Kombinationen wären hier interessant.
• Umgekehrt sollten Sie für eine gegebene SQL-Anfrage gute Indexe vorschlagen können. Denken Sie dabei auch an die Möglichkeit, eventuell ganz ohne Zugriff auf die Relation auszukommen.
• Sie sollten einen Full-Table-Scan mit einen Indexzugriff vergleichen können. Wann ist welcher Zugriffspfad günstiger? Was muß man dazu über die Relation wissen? Wir hatten in der Vorlesung auch ein Beispiel, in dem der Indexzugriff wesentlich länger dauerte als der Full Table Scan. Was waren da die wesentlichen Gründe? Warum ist wichtig, ob man die ROWIDs aus dem Index sortiert bekommt (nach der Blocknummer) und bei welchen Arten von Bedingungen geht das nicht?
• Sie sollten natürlich auch Nachteile von Indexen nennen können: Wann lohnt sich ein Index eher nicht?

Weitere Datenstrukturen

• Je nach Semester, in dem Sie die Vorlesung gehört haben, bin ich auch auf weitere Datenstrukturen zur Abspeicherung von Relationen und weitere Indexstrukturen in Oracle eingegangen. Ich frage danach selten bewußt, aber es kann nichts schaden, wenn Sie davon jedenfalls schon einmal gehört haben (z.B. Cluster, Hash-Cluster, Index-organized Tables, Bitmap Indexe).
• Wenn Sie diese Vorlesung bei einem anderen Professor gehört hätten, hätten Sie vielleicht weniger über Oracle, und dafür viel mehr über Indexstrukturen gelernt. Zum Beispiel gibt es für geometrische Datentypen viele spezielle Indexstrukturen. Ihrem Wissen sind da keine Grenzen gesetzt, obwohl ich nicht von mir aus danach fragen würde. Aber Sie lernen ja auch nicht nur für die Prüfung, sondern für Ihr späteres Berufsleben.

Anfrage-Auswertung

• Sie sollten das Konzept der Pipelined-Auswertung (oder "lazy" Auswertung) kennen. Warum ist es im allgemeinen gut, die Zwischenergebnisse nicht zu materialisieren? Bei welcher Operation ist das unvermeidbar? Gibt es auch Situationen, in denen man Zwischenergebnisse vielleicht doch materialisieren sollte, obwohl es nicht unbedingt nötig ist?
• Sie sollten das Nested Loop Join Verfahren und das Merge Join Verfahren erklären können, sowie auch die wesentliche Idee des Hash Join Verfahrens. Auch die Komplexitäten wären in diesem Zusammenhang interessant.
• In manchen Semestern haben wir auch über Optimierungsmöglichkeiten beim Nested Loop Verfahren unterhalten. Wie kann man z.B. vorhandenen Hauptspeicher nutzen?

Zugriffspläne, Anfrage-Optimierung

• Sie sollten für eine gegebene SQL-Anfrage erläutern können, wie man sie möglichst gut auswerten kann.
• Sie brauchen nicht alle Knotentypen in Oracle Auswertungsplänen (QEPs) auswendig zu lernen. Sie sollten aber zumindest einfachere QEPs auch aufzeichnen können, wobei Sie nicht unbedingt die offiziellen Oracle-Bezeichnungen für die Operationen verwenden müssen.
• Es kann nicht schaden, wenn Sie die ungefähre Funktionsweise des regelgesteuerten Optimierers von Oracle erläutern könnten, obwohl der jetzt nicht mehr "State of the Art" ist. Selbstverständlich müssen Sie nicht die genaue Prioritätenliste der Zugriffspfade auswendig zu lernen. Für die wichtigsten Operationen sollten Sie sich die Präferenzen ja auch leicht selbst zurecht legen können.
• Sie sollten auch die ungefähre Funktionsweise eines kostenbasierten Optimierers erklären können. Ebenso sollten Sie für gegebene Zugriffspläne vernünftige Kostenschätzungen machen können. Welches Wissen über die Relationen benötigen Sie dazu? Wo bekommt Oracle diese Daten her? Warum hält Oracle diese Informationen nicht immer aktuell? Es würde auch nichts schaden, wenn Sie wüßten, wie das Kommando heißt, mit dem man bei Oracle die statistischen Daten aktualisiert. Natürlich brauchen Sie nicht die genaue Syntax mit allen Parametern zu wissen, das könnten Sie ja bei Bedarf nachschlagen. Aber wenn Sie mal als DBA einer Oracle-Datenbank arbeiten, wäre wichtig, dieses Kommando gelegentlich zu verwenden. Sie sollten dann aber auch wissen, daß es möglicherweise eine große Last erzeugt, und nicht in den Haupt-Geschäftszeiten verwendet werden sollte.
• In manchen Semestern haben wir uns auch mit Histogrammen beschäftigt. Sie sollten wissen, wann Histogramme wichtig sind.

Bemerkungen zur Bewertung, Empfehlungen zur Prüfungsvorbereitung

• Siehe meine Prüfungshinweise zu Datenbanken I.
• Mindestens für eine Eins ist es natürlich günstig oder eigentlich sogar wichtig, noch weitere Literatur außer dem Skript zu lesen. Ich würde von Ihnen dann schon erwarten, daß Sie sich selbständig mit der Materie auseinander gesetzt haben, und Dinge kritisch hinterfragt haben. Gerade bei dieser relativ Oracle-lastigen Vorlesung wäre es ja auch von Vorteil, Alternativen zu den in der Vorlesung vorgestellten Verfahren zu kennen. So könnten Sie es besser in die Perspektive setzen.
• Ich denke, für eine Prüfung über diese Vorlesung können Sie sich am besten vorbereiten, indem Sie außer dem Skript noch weitere Literatur lesen (z.B. eines der Lehrbücher von Härder/Rahm oder Saake/Heuer, oder Garcia-Molina/Ullman/Widom). Auch das Oracle Concepts Manual wäre vielleicht interessant.
• Es ist auch sehr hilfreich, wenn Sie sich überlegen, wie Sie die Dinge programmieren würden, wenn Sie ein DBMS entwickeln würden. Ihre Zeit reicht natürlich nicht, das wirklich zu tun, aber so eine Planung kann Spaß machen, und man lernt viel dabei.
• Zu den üblichen Dingen bei einer Prüfungsvorbereitung gehört auch, sich den Stoff noch einmal mit eigenen Worten und in eingener Strukturierung kurzgefasst aufzuschreiben. Sie haben ja jetzt gelernt, daß keineswegs alles, was im Skript steht, auch direkt prüfungsrelevant ist (wenn ich auch der Meinung bin, daß Sie alles, was im Skript steht, einmal gehört haben sollten, oder Sie es zumindest bei Bedarf dort nachschlagen können sollten). Es würde sich also vielleicht lohnen, eine Kurzfassung des Skriptes zu erstellen, in der nur die wirklich prüfungsrelevanten Dinge stehen.
• Falls ich in der Prüfung etwas fragen sollte, von dem Sie meinen, daß es nicht dran war, oder von dem wir abgesprochen haben, daß ich das nicht prüfen werde, machen Sie mich bitte darauf aufmerksam. Ich bin ziemlich vergesslich und habe recht viele Prüfungen, eventuell weiß ich auch nicht mehr ganz genau, was ich in welchem Semester genau geschafft habe. Ich will aber ganz sicher keine bösen Tricks machen.

Stefan Brass (brass@acm.org), 07. August 2007

Original URL: http://www.informatik.uni-halle.de/~brass/pruef_dbIIB.html   [HTML 3.2 Checked]   [Links Geprüft]