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

Transkript

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

2 1. Einführung ORACLE erlaubt eine Vielzahl von Tuning-Optionen, unter anderem: Optimierung der DB-Server für diverse Rechnerarchitekturen. Dazu gehören auch lose gekoppelte Cluster-Systeme wie auch Massiv-Parallele Rechnerarchitekturen unterschiedliche Konfigurationsalternativen zur Anpassung der Anwendungssysteme Datensatzsperren ohne Eskalationsverfahren, um Sperrkonflikte und Deadlock- Häufigkeiten zu minimieren Lesen ohne Sperren für (konsistente) Leseoperationen bei gleichzeitigen Modifikationsoperationen Fast-Commit Verfahren, um die physischen Schreib- und Leseoperationen zu minimieren Zwei SQL-Optimierer für die Ermittlung der optimalen Zugriffspfade Diskrete Transaktionen zur Optimierung von Systemen mit extrem hohen Transaktionsraten Verteilung der Datenstrukturen auf beliebige Plattenlaufwerke innerhalb eines Rechnersystems Physische Optimierung von DB-Objektstrukturen konfigurierbarer DB-Cache u.v.a. mehr 2

3 2. Tuning Ebenen 2.1. Datenbankstruktur konzeptionelles DM physisches DM Indexstruktur (z. B. "foreigen keys", weitere Zugriffspfade => Selektivität) 2.2. SQL-Befehlsebene Der Optimizer entscheidet über die Verwendung von definierten Indizes nach Regel-Methode nach statistischer Methode nach statistischer Methode + Hinweise(Hints) Die Statistiken werden über den ANALYZE-Befehl gewonnen und im DD eingetragen ('user_tables') 3

4 2. Tuning Ebenen 2.2. SQL-Befehlsebene Der Analyzer ermittelt für den Optimizer folgende statistischen Werte pro Tabelle: Anzahl Datensätze Anzahl DB-Blöcke Anzahl unbenutzter DB-Blöcke durchschnittlicher freier Platz innerhalb der DB-Blöcke durchschnittliche Datensatzlänge Anzahl verketteter Datensätze Anzahl eindeutiger Werte / Spalte größter / kleinster Wert einer Spalte pro Index werden folgende Statistiken ermittelt: Tiefe des IX-Baums Anzahl IX-Blöcke auf "leaf"-ebene Anzahl eindeutiger Werte im IX größter / kleinster Wert des IX durchschnittliche Anzahl IX-Blöcke / IX-Wert durchschnittliche Anzahl DB-Blöcke / IX-Wert 4

5 3. Tuninggrundlagen 3.1 Der ORACLE Optimizer Ist der Mechanismus mit Hilfe dessen der ORACLE-Kernel über den Zugriffspfad entscheidet, den das SQL-Statement für die Datenwiedergewinnung verwenden soll Der Zugriffspfad wird dynamisch vom Optimizer nach dem Parsen des SQL- Statements bestimmt Der Optimizer evaluiert alle möglichen Zugriffsstrategien und wählt die optimale aus OPTIMAL das ist generell der Pfad mit den wenigsten full table scans. Dies gilt jedoch nicht für alle Fälle!!! Der Optimizer evaluiert die optimale Zugriffsstrategie nach dem parsing 5

6 3. Tuninggrundlagen 3.1 Die ORACLE Optimizer Regelbasiert(Rule) RBO Kostenbasiert (Choose) CBO Verwendet feste Regeln; gesteuert über Syntax und Datadictionary: Ab 10g nicht mehr supported Ausführungspfad mit geringsten Kosten Statistikgesteuert -> Tabellen sollten Statistiken haben: ANALYZE TABLE COMPUTE ESTIMATE STATISTICS Kann auf Instanzebene (optimizer_mode=choose first_rows all_rows rule), auf Sessionebene (Alter session set optimizer_mode=) und auf Statement-Ebene gesteuert werden (z.b. Hint /*+ CHOOSE */) Der Optimizer nutzt für seine Optimierung Informationen aus dem Dictionary Diverse Annahmen zur besten Strategie in bestimmten Situationen Eine Menge von Annahmen, die dann zum Ziel führen, wenn es keinen besten Zugriffspfad gibt(z.b. bei gleichguten Pfaden...) 6

7 3. Tuninggrundlagen 3.2 Der ORACLE Optimizer Der Optimizer kann grundsätzlich beeinflusst werden Durch die Verfügbarkeit von Indizes und Clusters, die eine optimale Pfadauswahl zulassen Gibt es einen optimalen Pfad, dann findet der Optimizer ihn, vorausgesetzt die hierzu erforderlichen Informationen stehen ihm auch zur Verfügung Die Arbeitsweise des Optimizers kann sich von Release zu Release ändern, insbesondere bei Änderungen am Kernel Optimierung ist ein kontinuierlicher Entwicklungsprozess Der Optimizer wird immer intelligenter, erhält aber seine Grenzen durch die Informationen, die ihm zur Verfügung gestellt werden Der Optimizer kann beeinflusst werden und hat seine Grenzen bei den ihm (nicht) verfügbaren Informationen 7

8 3. Tuninggrundlagen 3.3 Beispiel eines (optimalen) Zugriffspfads SELECT ename FROM emp WHERE emp.deptno = 10 Gibt es keine Indizes, so erfolgt ein sequential table scan - Jeder Block der Tabelle EMP wird von der DB-File gelesen - Für jeden Block, wird jede row angefasst, um herauszufinden, ob deptno = 10 ist - Für jede qualifizierte row wird der Wert für ename zurückgegeben CREATE INDEX emp1 ON emp(deptno) Jetzt kann der Optimizer die deptno = 10 Zeilen bereits über den Index erkennen - Die emp(deptno) Index-Blöcke werden von der Index-File der DB gelesen - Die ROWID s der rows die deptno = 10 haben werden gefunden und die Daten-Blöcke dazu von der DB-File gelesen - Die rows werden im Datenblock lokalisiert und der Wert der Spalte ename zurückgegeben 8

9 3. Tuninggrundlagen 3.4 SQL Tracing Einschalten auf Instance-Ebene: Session-Ebene: SQL*Plus-Befehl: 3.5 Index Überwachung Überwachung mit SQL_TRACE=TRUE ALTER SESSION SET SQL_TRACE=TRUE Execute DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION (session_id, serial_id, true) -> session_id und serial_id aus V$SESSION SET AUTOTRACE [ON OFF TRACE ONLY] [EXPLAIN STATISTICS] Statistiken sammelbar mit package DBMS_STATS Parameter TIMED_STATISTICS=TRUE setzen (8i/9i) oder STATISTICS_LEVEL=TYPICAL ALL (ab9i) ANALYZE INDEX name VALIDATE STRUCTURE (9i) SELECT name, (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100 AS Nichtnutzbar FROM index_stats Wenn Wert > 20%: ALTER INDEX name REBUILD 9

10 4. SQL Statements optimieren Jederzeit ist zu beachten: 1. Jede Abfrage aus einem Programm ist bis zum schnellstmöglichern SQL-Zugriff zu tunen 2. Man benutze immer eine WHERE-Klausel über die eine Index-Nutzung möglich wird; z.b. SELECT... FROM DEPT WHERE EMP_NO > 0; 3. Man nutze Indizes zum Sortieren von Daten (Vorsicht: nach DROP INDEX sind die Daten nicht mehr sortiert... ) 4. Keine Verwendung von IX-Spalten für Rechenoperationen, wenn diese zur Optimierung eines SELECT-Statements dienen soll:... WHERE SALARY * 12 > Keine Verwendung von IS NULL oder IS NOT NULL Operatoren auf Index-Spalten 6. Beinhaltet die Ergebnismenge mehr als 30% aller Daten der Tabelle, ist ein full TS Scan u. U. schneller als ein Indexzugriff 7. NOT in WHERE-Bedingungen ist zu vermeiden 8. UNION statt OR zu nutzen ist günstiger, da die Zahl der Datensätze, die durch eine Ungleich-Operation ausgewertet werden, wesentlich geringer ist 9. Die Nutzung von HAVING ist zu hinterfragen: Grundsätzlich sind WHERE-Prädikate besser (Filterfaktor!) 10. ALIAS-Namen (Korrelationsvariable) als Präfix für die ausgewählten Spalten helfen: Es verbessert die Parse-Zeit und verringert die Fehlerquote bei gleichnamigen Spalten in unterschiedlichen Tabellen 10

11 4. SQL Statements optimieren 11. Minimieren der Häufigkeit mit der eine Tabelle durchsucht werden muß und Maximieren der Anzahl der Spalten, die mit einem SQL-Statement modifiziert werden sind klare Performance-Ziele 12. Die DECODE-Funktion oder CASE zu nutzen, hilft oft die Anzahl Abfragen an eine Tabelle zu minimieren 13. Bei zwei gleichwertigen Indizes nimmt ORACLE den in einer WHERE-Klausel zuerst genannten Indexwert. Die Indizes werden "top-down" zugewiesen 14. Bei zwei gleichwertigen Indizes können Indizes ausgeschaltet werden, indem man zu Character-Variablen ein ( mit ) hinzufügt und zu numerischen Variablen + 0 addiert 15. Niemals unterschiedliche Datentypen in den Prädikaten vermischen, da dies eine Indexnutzung verhindert; z.b.:... WHERE EMP_NO = 123.0; -- und EMP_NO ist INTEGER definiert. 16. In der Regel sind Joins statt subqueries die bessere Alternative 17. NOT EXISTS ist besser als NOT IN: wegen SORT/MERGE 18. In der Regel sind Joins einem EXISTS bzw. NOT EXISTS vorzuziehen 19. Bei Systemen mit hoher User-Anzahl gilt: Mehrere unabhängige SELECT-Befehle zu einem SELECT zusammenfassen, um den Verkehr auf dem Netz und damit die Netzlast zu minimieren 11

12 4. SQL Statements optimieren 21. Die Reihenfolge der Tabellennamen in der FROM-Klausel bestimmt die sogen. "driving table". Sollte man den "rule-based" Optimizer verwenden, kann man mit der richtigen Reihenfolge der Tabellennamen die Anzahl physischer "reads" erheblich reduzieren. ORACLE durchsucht und sortiert zuerst die Tabelle, die als letzte in der FROM- Klausel angegeben wurde und nutzt deren mögliche Indizes, dann durchsucht ORACLE die vorletzte Tabelle der FROM-Klausel und "merged" die Daten mit dem Resultat der vorhergehenden Tabelle. Aus diesem Grunde sollte sichergestellt werden, daß die Tabelle, die in der FROM- Klausel als letzte angegeben wird; immer die ist, die die wenigsten Sätze, basierend auf dem Prädikat oder den Prädikaten der zugehörigen WHERE-Klausel, zurückliefert. Dies ist nicht unbedingt die Tabelle, die die kleinste Menge an "rows" enthält. 22. Die Zeit, die ein einzelnes SQL-Statement braucht ( elapsed time ) kann wie folgt grob ermittelt werden: SET TIMING ON "elapsed time" als real: n.nnnn SET TIME ON Tageszeit neben dem SQL-Prompt: 17:47:21 SQL>... 12

13 4. SQL Statements optimieren bei Problemfällen: 1. Man untersuche jedes in Frage kommende SQL-Statement und isoliere es in SQL*Plus 2. Man isoliere alle Bind-Variablen und ersetze diese in SQL*Plus mit passenden Konstanten 3. Man nutze SQL_TRACE, um mehr über das SQL-Statement zu erfahren: Indexnutzung, Auflösung der Query über den Optimizer (TKPROF). 4. Die Nutzung des Utility EXPLAIN PLAN hilft, die Sequenz der Index- und Tabellenverarbeitung zu erkennen und interne Sortiervorgänge zu beurteilen 5. Man erarbeite verschiedene SQL-Altertnativen und messe die Ergebnisse. Zu jedem SQL gibt es abhängig von dessen Komplexität bis zu 15 und mehr verschiedene Formulierungsmöglichkeiten 6. Man evaluiere auch die Datenmengen, die das SQL-Statement bewegt. Sind diese sehr groß, so kann ein Redesign/Überprüfung der Applikation/des DB-Design von großem Nutzen sein. 7. Man untersuche jedes SQL-Staterment, das ORDER BY, GROUP BY, oder HAVING benutzt, um sicherzustellen, daß keine unnötigen Sortiervorgänge stattfinden. Es ist besser die Daten entlang der Sequenz eines Index zurückzugeben und so die gewünschte Reihenfolge der Daten zu erreichen. 13

14 4. SQL Statements optimieren 8. Vorsicht bei Konvertierungsproblemen: Ein Index kann durchaus nutzbar sein, wenn man im Test Konstante verwendet, aber er erscheint ORACLE in dem Augenblick unbrauchbar, sobald die Programmvariable und die Indexspalte inkompatible Datentypdefinitionen aufweisen. 9. Hat man das Problem über Tests eines einzelnen SQL-Statements gelöst, so baue man dieses in das Programm ein und teste es erneut: Probleme können nicht nur von schlecht formulierten SQL-Statements herrühren, sondern auch über exzessive Lockmechanismen auf Systemressourcen hervorgerufen sein. Dauern UPDATE-Operationen zu lange, hat man folgende Möglichkeiten: 10. Mehrere UPDATES sollten mit nur einer einzigen "subquery" erledigt werden. Dies reduziert die Anzahl von I/O's. 11. Man nutze "arrayprocessing" für größere UPDATE-Aktionen (ARRAYSIZE), wann immer dies möglich ist. Es reduziert den Netzwerk- und Datenbank-Overhead. 12. Man verwende PL/SQL-Prozeduren: Sie sind geeignet um "outer driving loops zu formulieren (z.b. LOOP... END LOOP) und eine UPDATE-Operation innerhalb einer Schleife mehrere Male zu durchlaufen. 13. Bei großen UPDATE-Mengen sollte man die Locking-Strategien untersuchen. Andere Prozesse können erheblich dadurch verzögert werden, dass Sie zum selben Zeitpunkt dieselben Informationen nutzen wollen. Dauern die UPDATE Programme zu lange, so sollten sie in kleinere Transaktionseinheiten unterteilt werden 14

15 Geschafft... Und viel Spass mit ORACLE... 15