ORACLE. ORACLE-SQL für Profis. Tuning von ORACLE-SQL (Einführung-2) Januar,

Transkript

1 ORACLE ORACLE-SQL für Profis Tuning von ORACLE-SQL (Einführung-2) 1

2 1. Die Oracle Optimizer Die SQL-Optimizer entscheiden grundsätzlich anhand der folgenden Kriterien: Angegebene Syntax für die Anweisung Bedingungen, die die Daten erfüllen müssen (die WHERE-Klauseln) Datenbank-Tabellen, auf die die Anweisung zugreifen wird Alle vorhandenen Indizes, die das Abfragen der Daten aus der Tabelle unterstützen Version des RDBMS Aktueller Optimizer-Modus Hints in der SQL-Anweisung Alle vorhandenen Objekt-Statistiken (die über das Kommando ANALYZE generiert werden) Der physikalische Speicherort der Tabelle (Distributed SQL) Einstellungen in der INIT.ORA (Parallele Abfrage, async I/O etc.) 2

3 2. Der RBO 2.1 Funktionsweise des regelbasierten Optimizers Der regelbasierte Optimizer (RBO) verwendet einen vordefinierten Satz von Prioritätsregeln, um herauszufinden, welcher Zugriffspfad auf die Datenbank verwendet werden soll. Der RDBMS-Kernel verwendet unter den folgenden Bedingungen standardmäßig diesen regelbasierten Optimizer: 1. In der Datei INIT.ORA wird OPTIMIZER_MODE = RULE angegeben. 2. In der Datei INIT.ORA wird OPTIMIZER_MODE = CHOOSE angegeben, und es existieren keinerlei Statistiken für Tabellen in der Anweisung. 3. Das Kommando ALTER SESSION SET OPTIMIZER_MODE = RULE wird gesetzt. 4. Das Kommando ALTER SESSION SET OPTIMIZER_MODE = CHOOSE wurde gesetzt, und es existieren keinerlei Statistiken für Tabellen in der Anweisung. 5. Der Regel-Hint (z.b. SELECT /*+ RULE */...) wurde in der Anweisung verwendet. Der regelbasierte Optimizer wird hauptsächlich durch 20 Einstufungsbedingungen oder»goldene Regeln«gesteuert. Diese Regeln sind fest vorgegeben und werden, im Gegensatz zum kostenbasierten Optimizer, nicht durch äußere Parameter (Tabellen-Volumen, Index- Verteilung etc.) beeinflußt. 3

4 ! 3.1 Funktionsweise des kostenbasierten Optimizers Der kostenbasierte Optimizer ist ein weit ausgefeilteres feature als der regelbasierte Optimizer. Um den besten Ausführungspfad für eine Anweisung zu ermitteln, verwendet er statt fester Regeln Datenbankinformationen wie etwa Tabellengröße, Zeilenanzahl, Schlüsselverteilung etc. Die Informationen, die der kostenbasierte Optimizer benötigt, sind verfügbar, sobald eine Tabelle entweder über das Kommando ANALYZE oder das Package DBMS_STATS analysiert wurde. Wurde eine Tabelle nicht analysiert, kann der kostenbasierte Optimizer nur regelbasierte Vorgaben verwenden, um den bestmöglichen Zugriffspfad zu ermitteln. Ein Mix im Schema ist möglich Standardmäßig wird CBO immer dann für eine SQL-Anweisung aktiviert, wenn mindestens eine der Tabellen in der Anweisung analysiert wurde. Der CBO ermittelt daraufhin anhand der Informationen im Data Dictionary den bestmöglichen Zugriffspfad für die übrigen Tabellen. HINWEIS: Das Kommando ANALYZE und die DBMS_STATS-Funktionen sammeln Statistiken über Tabellen, Cluster und Indizes. Diese werden im Data Dictionary gespeichert. 4

5 Der RDBMS-Kernel verwendet standardmäßig den kostenbasierten Optimizer in folgenden Situationen: OPTIMIZER_MODE = CHOOSE wurde in der Datei INIT.ORA angegeben, und die Statistiken liegen für mindestens eine Tabelle in der Anweisung vor. Das Kommando ALTER SESSION SET OPTIMIZER_MODE = CHOOSE wurde ausgeführt, und die Statistiken liegen für mindestens eine Tabelle in der Anweisung vor. Das Kommando ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS (oder ALL_ROWS) wurde ausgeführt, und die Statistiken liegen für mindestens eine Tabelle in der Anweisung vor. In einer Anweisung wird der Hint FIRST_ROWS oder ALL_ROWS verwendet (z.b. SELECT /*+ FIRST_ROWS */...). Gut formulierte SQL s und ein sauberes physisches Datendesign sind immer noch die beste Garantie für gutes Laufzeitverhalten 5

6 3.2 Die Anweisung ANALYZE Wie die Tabellen analysiert werden, kann sich erheblich auf die SQL-Performanz auswirken: Vergisst der DBA, die Tabellen oder Indizes nach einem Tabellen-Neuaufbau zu analysieren Führt der DBA zu oft eine Analyse durch, kann Oracle u. U. den Ausführungsplan wechseln. Der neue Plan wird in der Regel eine Verbesserung darstellen, gelegentlich aber auch eine Verschlechterung Will man öfter eine Analyse durchführen, verwendet man DBMS_STATS.EXPORT_SCHEMA_STATS, um vor der erneuten Analyse eine Sicherheitskopie erstellt zu bekommen. Oracle kann entweder alle Zeilen (ANALYZE COMPUTE) oder nur eine Auswahl von Zeilen (ANALYZE ESTIMATE) in einer Tabelle untersuchen. Normalerweise verwendet man ANALYZE ESTIMATE für sehr große Tabellen ( Zeilen und mehr) und ANALYZE COMPUTE für kleine bis mittlere Tabellen. Eine Analyse mit FOR ALL INDEXED COLUMNS wird für jede Tabelle empfohlen. Hat ein Großteil der Zeilen in einer Tabelle denselben Spaltenwert, liegt ein Verteilungsproblem vor. Die Option FOR ALL INDEXED COLUMNS teilt dem kostenbasierten Optimizer das Problem der Datenverteilung zusätzlich zu deren Kardinalität (Anzahl unterschiedlicher Werte) mit. 6

7 3.2 Die Anweisung ANALYZE (contn d) Wird eine Tabelle mittels ANALYZE analysiert, werden alle betroffenen Indizes ebenfalls analysiert. Wird ein Index gelöscht und neu angelegt, muß er erneut analysiert werden. Man beachte, daß die Prozeduren DBMS_ STATS.GATHER_SCHEMA_STATS und GATHER_TABLE_ STATS standardmäßig nur Tabellen, nicht jedoch ihre Indizes analysieren. Werden diese Prozeduren eingesetzt, muß die Option CASCADE=>TRUE angegeben werden, damit auch die zugehörigen Indizes analysiert werden. Hier einige Beispiele für ANALYZE-Anweisungen: ANALYZE TABLE EMP ESTIMATE STATISTICS SAMPLE 5 PERCENT FOR ALL INDEXED COLUMNS; ANALYZE INDEX EMP_NDXl ESTIMATE STATISTICS SAMPLE 5 PERCENT FOR ALL INDEXED COLUMNS; ANALYZE TABLE EMP COMPUTE STATISTICS FOR ALL INDEXED COLUMNS; Hat man eine Tabelle aus Versehen analysiert, kann man Statistiken gezielt wieder löschen. Zum Beispiel: ANALYZE TABLE EMP DELETE STATISTICS; 7

8 3.3 Optimierung vor dem Einsatz in der Produktion Ein Hauptproblem bei der Verwendung des kostenbasierten Optimizers (CBO) ist, SQL s vor dem Einsatz in der Produktion zu optimieren: Die meisten Entwicklungsund Testdatenbanken enthalten sehr viel weniger Zeilen als eine Produktionsdatenbank. Viele Projekte können sich die Kosten und den Aufwand eines Kopierens der Produktionsdatenbank in eine Pre-Produktionsdatenbank nicht leisten. Oracle-Versionen ab 8i enthalten diverse Features wie DBMS_ STATS und die Outline-Funktionalität, zur Lösung dieses Problems. Features des DBMS_STATS Beschleunigung der Analyse mittels DBMS_STATS Kopieren von Statistiken mittels DBMS_STATS Ändern von Statistiken mittels DBMS_STATS Rückkehr zu vorherigen Statistiken Ein Outline ist nichts anderes als ein gespeicherter Ausführungsplan Features von OUTLINES Aufzeichnen eines Outline für eine SQL-Anweisung / für das gesamte SQL einer Sitzung Aktivieren von Outlines für das gesamte System / für eine Session Kopieren von Outlines zwischen Datenbanken 8

9 3.4 Detaillierte Funktionsweise des kostenbasierten Optimizers Im Gegensatz zum regelbasierten Optimizer hat der CBO keine festen Entscheidungsregeln. Der kostenbasierte Optimizer wendet immer die gleiche Methode an, um alle möglichen Ausführungspläne zu berechnen und ihre jeweiligen Kosten zu bestimmen (Effizienz). Die Funktionalität des kostenbasierten Optimizers kann grob in die folgenden Schritte aufgeteilt werden: 1. Parsen der SQL-Anweisung (Syntaxprüfung, Objekt-Zugriffsrechte etc.) 2. Erzeugen einer Liste aller potentiellen Ausführungspläne 3. Berechnen (Schätzen) der Kosten jedes Ausführungsplans unter Verwendung aller vorhandenen Objektstatistiken 4. Auswählen des Ausführungsplans mit den niedrigsten Kosten Der kostenbasierte Optimizer braucht mindestens eine Tabelle innerhalb einer SQL- Anweisung, die Statistiken hat (Tabellen-Statistiken für nicht-analysierte Tabellen werden geschätzt). -> ansonsten RBO: es sei denn, der kostenbasierte Optimizer wird durch Hints auf Anweisungsebene oder durch Angabe des Optimizer-Ziels ALL_ROWS oder FIRST_ROWS explizit eingeschaltet. Um zu verstehen, wie der kostenbasierte Optimizer funktioniert und wie man ihn gezielt nutzen kann, muß man zunächst verstehen, wie er»denkt«. 9

10 3.4 Detaillierte Funktionsweise des kostenbasierten Optimizers (cntn d) 1. Auswahl Primärschlüssel und/oder UNIQUE-Index Die Selektivität eines UNIQUE-Indexes wird als 100% gewertet. Keine andere Index-Zugriffsmethode ist genauer Auswahl Non-UNIQUE-Index Für Non-UNIQUE-Indizes wird die Selektivität berechnet. Der kostenbasierte Optimizer nimmt an, daß die Tabelle (und zugehörige Indizes) eine einheitliche Datenverteilung aufweist, wenn nicht die Option FOR ALL INDEXED COLUMNS beim ANALYZE angegeben wird. 3. Bereichsauswertung Für Ausführungspläne bei Indexbereichen wird die Selektivität ermittelt. Diese Bewertung beruht auf den letzten Statistiken für die höchsten und niedrigsten Werte einer Spalte. Auch hier geht der kostenbasierte Optimizer davon aus, daß die Daten der Tabelle (und zugehörige Indizes) gleichmäßig verteilt sind Bereichsauswertung bei Bind-Variablen Für Ausführungspläne bei Indexbereichen wird die Selektivität geschätzt. Da Werte von Bind-Variablen zum Zeitpunkt des Parsens nicht verfügbar sind, konnte der Optimizer vor Oracle9i keine auf Bind-Variablenwerten beruhenden Entscheidungen treffen. - Heute geht er z. B. bei WHERE dept_no = :bl von 25%, bei WHERE dept_no > :bl AND dept_no < :b2) von 50% Selektivität aus. 10

11 5. Histogramme Vor der Einführung von Histogrammen in Oracle 7.3 konnte der kostenbasierte Optimizer keine ungewöhnlichen Datenverteilungen feststellen. 6. Verwendung von System-Ressourcen Grundsätzlich geht der kostenbasierte Optimizer davon aus, daß der derzeitige User die einzige Person ist, die auf die Datenbank zugreift. Erst Oracle9i ermöglicht das Speichern von Informationen über die Verwendung der System-Ressourcen. Der Optimizer kann aufgrund dieser Informationen über die Rechnerlast bessere Entscheidungen treffen (Package DBMS_STATS. GATHER_SYSTEM_STATS). 7. Aktuelle Statistiken sind wichtig Der CBO kann die Ausführungspläne nicht optimal bestimmen, wenn eine Tabelle analysiert wurde, aber nicht deren Indizes, oder umgekehrt. Man sollte die Datenbank nicht durch Inline-Hints zwingen, den kostenbasierten Optimizer einzusetzen. Der Einsatz von alten Statistiken kann gefährlicher sein als das erneute Abschätzen der Statistiken zur Laufzeit. Das Analysieren von großen Tabellen mit ihren zugehörigen Indizes kann bei Angabe der Option COMPUTE sehr lange dauern. Die Analyse mit einem konstanten Wert erlaubt es i. d. R. bereits optimale Entscheidungen zu treffen. 11

12 4. CBO und RBO Einige verbreitete Optimizer-Mißverständnisse 1. Oracle8i und Orade9i unterstützen den regelbasierten Optimizer nicht Dies ist völlig falsch. Einige Publikationen hatten dies vor einiger Zeit behauptet, doch Oracle versichert, daß dies definitiv nicht stimmt. 2. Beim regelbasierten Optimizer können keine Hints angegeben werden Der Großteil der Hints in SQL-Anweisungen können beim regelbasierten Optimizer auch angegeben werden. 3. Optimiertes SQL (regelbasiert) wird auch unter dem kostenbasierten Optimizer optimal ablaufen Wenn man Glück hat, stimmt das. Aber wenn man auf den kostenbasierten Optimizer wechselt, muß man damit rechnen, daß man eine Reihe von SQL- Anweisungen neu optimieren muß. 4. Optimiertes SQL (kostenbasiert) wird auch unter dem regelbasierten Optimizer optimal ablaufen Dies ist eher unwahrscheinlich. 5. Man kann den regelbasierten und den kostenbasierten Optimizer nicht zusammen verwenden Durch das Setzen des Parameters OPTIMIZER_MODE in der Datei INIT.ORA auf CHOOSE kann man beide verwenden. 12

13 4. CBO und RBO Welcher Optimizer sollte verwendet werden? Empfehlung: auf den kostenbasierten Optimizer wechseln: Die Entwicklungszeit wird kürzer. Entwickler müssen keine Regeln kennen. Es gibt für den kostenbasierten Optimizer viel mehr Features und Optimierungstools. Der performante Einsatz von Programmpaketen fremder Anbieter wurde deutlich verbessert. Viele Pakete wurden so entworfen, daß sie sowohl unter DB2, Informix und SQL-Server wie auch unter Oracle laufen. Der Code wurde jedoch dabei nicht für den regelbasierten Optimizer geschrieben. Meist wird eine generische Methode eingesetzt. Endbenutzer können optimierten Code schreiben, ohne einen großen Satz an Optimizer-Regeln zu lernen. Der CBO wurde von Oracle-Version zu Oracle-Version stark verbessert. Die Weiterentwicklung des regelbasierten Optimizers wurde hingegen eingestellt. Das Risiko beim Hinzufügen neuer Indizes ist geringer. Es gibt viele Features, die nur beim kostenbasierten Optimizer verfügbar sind. Diese Features ermöglichen das Erkennen von materialisierten Views, Star- Transformationen, den Einsatz von funktionsbasierten Indizes etc. 13

14 Geschafft... Und viel Spass mit ORACLE... 14