Protokoll 1: Listener: Bei Oracle erfolgt die Steuerung (konventionell) via listener.ora (Listener Konfiguration), tnsnames.ora (Client Konfiguration) Abschnitt 2.1 (Ausführungen zum Shutdown / Startup) ist überarbeitenswert (prinzipiell) Alte Variante Aufruf von svrmgrl durch Benutzer oracle u.a. (Authentifizierung durch OS): connect internal exit Neue Variante: Aufruf von sqlplus/nolog Connect username/password as sysdba bzw. Sysoper exit (Verwaltung der Benutzer via Password File) Ende Abschnitt 2.1 2.2 (DB-Privilegien, eigentlich Rollen, beispielhaft) connect Verbindungsaufbau zur DB möglich Protokoll 2: Mit der View Definition kann man m.e. nicht sehr viel anfangen, deshalb wäre m.e. ein Verweis auf Protokoll 1 unbedingt sinnvoller Bei den Roles sollte die Frage des Zugriffs (S.3) wie folgt beantwortet werden: Ja, aber nur, wenn er rolle1 und damit rolle0 ausübt. (Damit wird die Hierarchie der Zugriffsrechte sichtbar!) Bei der Skizze zur Instanzarchitektur fehlen die DB Writer, die die modifizierten Blöcke vom Buffer Pool in die DB schreiben, außerdem ist der Checkpoint Prozess nicht aufgeführt, der Verwaltungsinformationen zum Checkpoint in die Data Files und das Controfile schreibt. Der Vollständigkeit halber sollte man vielleicht auch PMON und SMON, die beiden Monitor Prozesse, in das Bild aufnehmen. Protokoll 3: Bei der Diskussion des Redo Log Switchs 4 -> 1 sollte das Redo Log nur aus den 4 Logs bestehen. Checkpoint-Konfiguration: Recovery Betrieb => Crash Recovery
SMON (System Monitor) Hat zwei Aufgaben - Instanz Überwachung inklusive Aufräumarbeiten - Steuerung von (Startup und) Crash Recovery Einrückung Shared Pool Library Cache Dictionary Cache Protokoll 4: Okay Protokoll 5: Bei der relationalen und physischen Algebra: Equi Join binäre Zuordnung, Non Equi Join wird nicht betrachtet (nur der Vollständigkeit halber) Protokoll 6: Überschrift Nested Loop, Sort/Merge weg! Beispiel Schritt 3: Sortieren, um Duplikate zu entfernen Vor order by ename Überschrift: Diskussion der order by Klausel Vorschlag 1: Letzte beiden Zeilen vor Vorschlag 2 ersetzen durch: Index liefert falsche Reihenfolge, also muß für order by sortiert werden. Kapitel Joins: Erstes Select kann gestrichen werden! 2. Select: Überschrift: Zunächst reduzierte Betrachtung(1 Restriktion) Betrachtung 1: Reduktion auf Restriktion e.sal >... Annahme: kleine Treffermenge, z.b. 10 Äußere Schleife: Bestimme emp Zeilen mit e.sal >... (10) via Indexzugriff Innere Schleife: Für alle 10 Treffer, bestimme zugehörige Abteilung via Index auf Primary Key (deptno).
Betrachtung 2: Reduktion auf Restriktion d.loc =... Annahme: 10 Treffer Äußere Schleife: Bestimme dept Zeilen mit d.loc =... (10) via Indexzugriff Innere Schleife: Für alle 10 Treffer, bestimme zugehörige Mitarbeiterdaten via Foreign Key d.deptno (auf FK sollte Index angelegt werden) In beiden Fällen ist die beschriebene Technik (Nested Loop Join) vorteilhaft: Indexzugriff für äußere und innere Schleife Kleine Treffermenge in äußerer Schleife => Innere Schleife besteht aus wenigen Indexzugriffen Frage: Was ist besser, wenn beide Restriktionen präsent sind? In unserem Beispiel Start mit Restriktion e.sal >... (10 Treffer), dann Nested Loop Join (jeweils 1 Treffer), Restriktion d.loc =... on the fly Variante zu Nested Loop: bestimme alle zugehörigen Abteilungsdaten via PK auf deptno (1Mio Indexzugriffe) ineffizient, auch wenn Caching berücksichtigt wird Besserer Zugriffspfad auf dept: -> Hash... Für den sequentiellen Zugriff sind CPU- und I/O-Ressourcen erforderlich => Hash Joins sind ressourcenintensiv Unterschied:... => Diese Zeile streichen! 3. Join Technik: Sort/Merge Join statt Eine Variante... Beurteilung... Nested Loop:... vermeiden durch Indexzugriff, der sowohl Restriktion als auch sortierten Zugriff unterstützt OLTP (Online Transaction Processing) Antwortzeitoptimierung (durch Indexzugriff für Restriktion und sortierten Zugriff, Nested Loop Joins) Unterstützung von (Master Detail) Left outer joins und mengentheoretische Differenz (z.b. Berücksichtigung von Abteilungen ohne Mitarbeiter) Beispiele am Ende (eher von generellem Interesse) Abfrage: Select deptno from dept where deptno not in...
Welche Abfrage ist besser? - i.a. die binäre Zuordnung - Query Rewrite Komponente sollte in der Lage sein, die (für den jeweiligen Optimizer) schlechtere Formulierung in die bessere umzuwandeln. - Wenn nicht, sollte der Entwickler die bessere Formulierung (kennen und) verwenden! Die abschließende Betrachtung der Algorithmen zur Gruppierung von Daten ist eher von prinzipiellem Interesse, also entweder weglassen oder korrekt formulieren! Abfrage: Anzahl Mitarbeiter pro Abteilung Algorithmen - Aufbau einer Hash Table zu Abteilungsnummern während sequentiellen Zugriffs auf emp: Falls Abteilung noch nicht vorhanden, Einfügen und mit Anzahl 1 initialisieren Sonst Anzahl erhöhen - Sequentieller Zugriff auf emp, Projektion auf Spalte deptno, Sortieren des Resultats, danach Bestimmung der Anzahl Mitarbeiter pro Abteilung - Falls Index auf deptno in emp existiert, kann der zweite Algorithmus via Index Only Zugriff umgesetzt werden (zu jedem Eintrag muß nur die Anzahl der Row Ids bestimmt werden) Protokoll 7 Teil 1: Mein Vorschlag: Die Problematik der NULLs in Oracle weglassen und nur die beiden Abfragen (Anzahl Mitarbeiter, Durchschnittsgehalt) mit dem jeweiligen Hinweis auf den Index Only Zugriff bringen. Problem bei Oracle: NULL wird im Index nicht berücksichtigt, dadurch wäre der Indexzugriff nicht korrekt. Dto. Für die nächste Abfrage gilt das gleiche. Lösungsansatz: Default Wert anstelle von NULL, functional Index, Umformulierung der Abfrage in Select deptno, count (*) From emp Where deptno >0 Group by deptno Union all Select deptno, count (*) From emp Where deptno not null Order by: Es ist die Entscheidung zu treffen: - Daten expliziert zu sortieren oder - Sortierung durch sortierten Zugriff via Index zu vermeiden?
OLTP. Hier ist eine kurze Antwortzeit gefordert, demnach sollte eine Sortierung vermieden werden. Projektion / Vereinigung Triviale Operationen für den Optimizer (Duplikate entfernen wird ja gesondert betrachtet) Kartesisches Produkt Sollte i.a. nicht verwendet werden Strategien des Optimizers: - Wahl der geeigneten Join Reihenfolge und Join Algorithmen fehlt! (s. Folie) Weiter (nach Liste der Strategien): Der Optimizer muss wissen, ob auf Antwortzeit oder Durchsatz optimiert werden soll Bei Oracle gibt es hierfür sog. hints : Select /*+ first_row */ opt. Auf Antwortzeit Select /*+ all_rows */ opt. Auf Durchsatz Bei DB2 gibt es die hierfür folgende Klausel: Optimize for N rows Das Problem hierbei ist die mangelnde Portabilität. N=1 Antwortzeit, N groß Durchsatz Protokoll 7 Teil 2: Anmerkung: Welchen Vorteil hat es, sal mit in den Index zu nehmen? Kleinere Treffermenge Abfragen (siehe Skript) finde ich unglücklich, am besten die Abfragen werden in das Dokument hineinkopiert. Protokoll 8 Teil 1: Erstes Beispiel ist unglücklich, weil vorher nur von ODBC, JDBC gesprochen wird und dann ein Beispiel zu Embedded SQL kommt. Vorschlag: vorher (ODBC, JDBC, aber auch Embedded SQL, SQL/J) Embedded SQL bei statisches SQL weglassen und zusammen mit SQL/J aufführen: Embedded SQL für C/C++, Cobol,..., SQL/J (Embedded SQL für Java) Das SQL kann... JDBC Treiber: Typ 1 bzw. 2: Installationsaufwand auf (DBS) Client Rechner Typ 3 bzw. 4: Nur JDBC Treiber muß auf (DBS) Client Rechner verteilt werden
Protokoll 8 Teil 2: Zum Savepoint: JDBC3 bietet die Möglichkeit, Transaktionen durch Savepoints intern zu strukturieren.... rowcount // gibt Anzahl der von einem DML Statement betroffenen Zeilen zurück: execute ist auch für den Aufruf von Stored Procedures einzusetzen! Optimierung: - Optimierung beim Prepare - Optimierung (direkt) vor der ersten Ausführung Effizienz der Wiederverwendung von Plänen: Hängt vom DBS ab..., ist aber generell gegeben (falls der Plan nicht parameterabhängig ist) Voraussetzung... Identifikation des Plans, z.b. anhand des Statement Texts Weitere Protokolle liegen zur Zeit nicht vor!!!