Ausführungspläne, Hints, Zugriffs- und Join-Methoden

Transkript

1 Ausarbeitung zum Vortrag Ausführungspläne, Hints, Zugriffs- und Join-Methoden Peter Matjeschk 1 / 15

2 Inhaltsverzeichnis 1 Anfrageverarbeitung Ausführungspläne Entstehung von Ausführungsplänen Oracles Optimierer Rule Based Optimizier - RBO Cost Based Optimizer - CBO Ausgabe von Ausführungsplänen Hints Wahl des Optimierers Zugriffsmethoden Join-Methoden Parallelarbeit Weitere Hints Statistikinformationen Statistiken Histogramme Nutzung von ANALYZE TABLE Nutzung von DBMS_STATS Nutzung von IDEs SQL-Developer PL/SQL-Developer Quellen / 15

3 1 Anfrageverarbeitung 1.1 Ausführungspläne Anfragen an Datenbanksysteme werden in einer der relationalen Algebra angelehnten Sprache, der Structured Query Language SQL, formuliert. Diese für den Nutzer recht leicht verständliche Sprache, kann jedoch nicht in dieser Form vom Datenbanksystem interpretiert und verwendet werden sondern muss zunächst in einen Algorithmus transformiert werden. Dieser Algorithmus wird dabei durch einen Ausführungsplan dargestellt. Es ist zu beachten, dass es zu einer Anfrage im normalfall mehrere verschiedene Ausführungspläne geben kann, die jedoch in ihrer Ausführungszeit stark schwanken. Die Auswahl des optimalen Ausführungsplans ist Aufgabe des Optimiers. 1.2 Entstehung von Ausführungsplänen Abb. 1: Entstehung von Ausführungsplänen (allgemein) 3 / 15

4 Die Entstehung eines Ausführungsplans läßt sich prinzipiell in die folgenden Schritte unterteilen: Übersetzung und Sichtexpansion: In dieser Phase wird aus der Anfrage ein Anfrageplan generiert, arithmetische Ausdrücke werden vereinfacht und Sichten werden durch Einsetzen ihrere Sichtdefintion beseitigt. Normalisiserung und Vereinfachung: Das DBMS überführt den Anfragebaum in eine Normalform (überlicherweise eine KNF), vereinfacht Ausdrücke und eliminiert überflüssige Terme, und entschachtelt die Anfragen. Optimierung: Die Optimierung an sich läuft prinzipiell ebenfalls in drei Schritten ab. Zunächst findet eine logische Optimierung statt. In dieser Phase findet zum einen eine algebraische Optimierungen durchgeführt (entfernen redundanter Operationen, Verschieben von Selektionen und Projektionen, Ändern der Reihenfolge von Verbunden, Grupperiungen werden möglichst nah an die Blätter verschoben), zum anderen findet eine sogenannte Tableauoptimeriung statt, die das Ziel hat, überflüssige Joins zu vermeiden. Die Tableauoptimierung greift jedoch nur für eine sehr eingeschränkte Klasse von Anfragen (bspw. können durch Sichten überflüssige Joins entstehen, bei DBMS mit einer Universalrelation = Verbund über alle Relationen einer DB). Die zweite Phase der Optimierung, die physische Optimierung, greift nun auf Wissen über Speicherungstechniken (Indexe, Cluster) zurück und sucht Algorithmen zur Auflösung der Algebraterme des Anfragebaums aus. In der Regel entstehen dabei mehrere Ausführungspläne, die dann entweder durch heuristische Regeln bewertet werden oder in der dritten Phase genauer bewertet werden. In der Phase der kostenbasierten Auswahl werden nun Statistikinformationen, wie bspw. die Größe der Tabellen, die Selektivität bestimmter Attribute, die Ordnung der Dateien, die Menge des zur Verfügung stehenden Speichers usw. herangezogen Planparametrisierung: In dieser Phase werden in der Anfrage aufgetretene Platzhalter mit konkreten Werten versehen. Dieser Schritt tritt nur bei vorkompilierten Anfragen oder in Embedded-SQL-Anwendungen auf. Bei wiederholten Anfragen können dadruch auch die Optimierungsschritte ausgelassen werden, sofern ein Ausführungsplan existiert. Code-Erzeugung: Als letzter Schritt wird der entstandenen Ausführungsplan in nativ lauffähigen Code umgewandelt oder alternativ innerhalb des DBMS interpretiert. 4 / 15

5 1.3 Oracles Optimierer Abb. 2: Enstehung von Ausführungsplänen (Oracle) Rule Based Optimizier - RBO Der RBO wurde in Oracle Version 6 eingeführt und besitzt ein festes Regelwerk, welches anhand des Aufbaus des Statements und internen Ranglisten von Zugriffsmethoden eine Anfrage optimiert. Das Vorgehen des RBO ist aufgrund seiner Statik leicht nachzuvollziehen. Der RBO wird von Oracle nicht mehr weiterentwickelt und unterstützt keine neuen Featueres wie bspw. partioned tables oder materialized views. In Oracle 10g ist er weder dokumentiert noch wird er unterstützt Cost Based Optimizer - CBO Der CBO wurde in Oracle 7 eingeführt und nutzt Statistiken über Tabellen, Indizes und Spalten, um Anfragen zu optimieren. Da das Wissen über die Statistiken recht dynamisch ist, ist die Strategie oft schwer nachzuvollziehen. Meist erzeugt der CBO auch ohne Statistiken optimalere Ausführungspläne als der RBO Der CBO unterstützt alle neuen Features von Oracle und wird seit Oracle 10g standardmäßig verwendet. 5 / 15

6 1.4 Ausgabe von Ausführungsplänen Für die Ausgabe von Ausführungsplänen ist die Tabelle PLAN_TABLE zwingend erforderlich. Sollte diese Tabelle nicht existieren, so existiert folgendes Script, um die Tabelle mit den notwendigen Spalten zu erzeugen: $ORACLE_HOME/rdbms/admin/utlxplan.sql Wenn sichergestellt ist, dass die benötigte Tabelle vorhanden ist, kann der Nutzer auf den verwendeten Ausführungsplan zugreifen. Dafür gibt es prinzipiell zwei Methoden: Erzeugen des wahrscheinlichsten Ausführungsplans: EXPLAIN PLAN SET STATEMENT_ID = 'beliebiger Statement Name' FOR SELECT... Anzeigen des Ausführungsplans: SELECT LPAD( ' ', 2 * ( level-1 ) ) OPERATION ' ' OPTIONS ' ' OBJECT_NAME ' ' DECODE( ID, 0, 'Cost = ' POSITION ) "EXECPLAN" FROM PLAN_TABLE WHERE STATEMENT_ID = 'beliebiger Statement Name' CONNECT BY PRIOR ID = PARENT_ID AND STATEMENT_ID = 'beliebiger Statement Name' START WITH ID = 0 Mittels EXPLAIN PLAN wird der Ausführungsplan in die Tabelle PLAN_TABLE geschrieben, den Oracle verwenden würde, falls die Anfrage zu diesem Zeitpunkt gegen die Datenbank ausgeführt werden würde. Da sich jedoch zwischen der Nutzung von EXPLAIN PLAN und der tatsächlichen Anfrage die Statistiken ändern können, muss der dargestellte Ausüfhrungsplan nicht dem tatsächlich verwendetem entsprechen. Den Ausführungsplan der tatsächlich für die Verarbeitung einer Anfrage herangezogen wurde, kann nur nachträglich ausgegeben werden, indem man folgendes Kommando vor der Ausführung der Anfrage eingibt: SET AUTOTRACE ON [EXPLAIN] Das Kommando gilt nur für die Dauer einer Session und erzwingt die Ausgabe des Ausführungsplans nach der Ausführung der Anfrage. 6 / 15

7 2 Hints Hints sind Hilfstellungen an den Optimier. Der Nutzer kann damit das Verhalten des Optimierers Steuern, um so bessere Antwortzeiten für die Anfragen zu erhalten. Sie können nur bei INSERT, UPDATE, DELETE und SELECT verwendet werden: SELECT /* HINT1(.. ) HINT2(.. ) HINT3(.. )... */.. Hints sollte man dann einsetzen, wenn beispielsweise der Datenbestand sehr instabil ist und dementsprechend die Statistiken häufig veraltet sind. Da der Entwickler die Zusammenhänge der Daten oft besser kennt, als das Datenbanksystem können so schlechten Optimierungen vorgebeugt werden. Dennoch muss folgendes beachtet werden: Hints können die Antwortzeit verschlechtern und müssen bei Veränderungen der Datenverteilung von Hand gepflegt werden. Oracle bietet auch an, Statistiken, die bspw. einen guten Ausführungsplan zur Folge haben, zu sperren. Ausserdem kann der Optimierer entscheiden, bestimmte Hints zu ignorieren. 2.1 Wahl des Optimierers RULE erzwingt die Nutzung des RBO, dies ist der einzige Hint, der den RBO zur Folge hat! FIRST_ROWS( X ) der CBO wird angewiesen, einen Ausführungsplan zu erzeugen, mit dem die ersten X Zeilen möglichst schnell zurückgeliefert werden ALL_ROWS Erzeugung eines Ausführungsplans, der alle Ergebniszeilen schnellstmöglich zurückliefert CHOOSE Standard in Oracle: bei Vorhandensein von Statistiken soll der CBO verwendet werden, sonst der RBO 2.2 Zugriffsmethoden FULL table erzwingt einen Full Table Scan auf die Tabelle table ROWID table erzwingt einen Zugriff anhand der RowId auf die Tabelle table 7 / 15

8 Hints zur Steuerung der Verwendung von Indizes: INDEX( table index1 [index2 [..]] ) - Zugriff auf die Tabelle table anhand der Indizes index1, index2,... INDEX( table table( spalte1, spalte2,... ) ) - Zugriff auf die Tabele table anhand eines Indizes über die Spalten spalte1, spalte2,... INDEX_ASC( table [index] ) / INDEX_DESC( table [index] ) - aufsteigendender bzw. absteigendender Scan über den gewählten Index INDEX_FFS( table [index] ) - Fast Full Scan über den Index nur möglich, wenn alle Spalten der WHERE-Klausel im Index vorhanden sind INDEX_JOIN( table [index1] [index2] ) - Optimierer soll Zugriffspfad über zwei Indizes wählen, die dann typischerweise mittels Hash-Join vereint werden NO_INDEX( table [index1] [index2]... ) - Optimierer soll index1, index2,... nicht für den Zugriff auf die Table table heranziehen Cluster Scan: CLUSTER( table ) - Zugriff auf Tabelle table anhand einer RowId die dem Cluster Key im Index entspricht. Betroffene Zeilen befinden sich in benachbarten Blöcken. HASH( table ) - ähnlich der Verwendung von CLUSTER, nur dass statt eines Indizes ein Hash verwendet wird SAMPLE BLOCK: Eigentlich kein Hint, jedoch eine noch fehlende Zugriffsmethode. Die Verwendung veranlasst das DBMS eine zufällige Probe von Daten des auszuführenden Statements zurückzuliefern. Bsp: SELECT * FROM table SAMPLE BLOCK (percent) 8 / 15

9 2.3 Join-Methoden USE_HASH( table1 [table2 [..]] ): Für die kleinste Tabelle wird eine Hash-Tabelle über die Spalten der Join-Bedingung gebildet. Danach werden die weiteren Tabellen gescannt und die Zeilen anhand ihrere Hash-Werte verglichen. Ein Hash-Join ist schneller als ein Merge-Join, sofern die Hash-Tabelle komplett in den Speicher passt. Achtung: die komplette Join-Operation muss abgeschlossen sein, bevor die erste Ergebniszeile zurückgeliefert wird USE_MERGE( table1 [table2 [..]] ): Anhand der Join-Bedingung werden die betroffenen Tabellen sortiert und die entstandenen Ergebnismengen daraufhin übereinandergelegt. Merge-Join ist effektiv bei kleinen Tabellen, jedoch geht der Effekt verloren, sobald ausgelagert werden muss USE_NL( table1 [table2 [..]] ): Mittels verschachtelter Schleifen werden die Tabellen an eine Ergebnismenge angehängt. 2.4 Parallelarbeit PARALLEL( table int int ) / PARALLEL_INDEX( table int int ): Erzwingt die Nutzung von Parallelarbeit für den Zugriff auf die Tabelle table. Der zweite Parameter beschreibt hierbei den Parallelitätsgrad, d.h. die Anzahl der Prozesse je Instanz, die Oracle für den Zugriff verwendet. Der dritte Parameter legt fest, wieviele parallel arbeitende Instanzen Verwendung finden. Die Werte sind abhängig von der Anzahl der verbauten CPUs und der Anzahl der Festplatten. Achtung: PARALLEL ist nicht kompatibel mit dem Hint FIRST_ROWS( X ), da dieser die Nutzung von Indizes favorisiert, PARALLEL allerdings die Nutzung von FTS). PARALLEL_INDEX steuert das Verhalten beim Zugriff auf den Index NOPARALLEL / NOPARALLEL_INDEX: Deaktiviert den parallelen Zugriff auf die Tabelle / den Index. 9 / 15

10 PQ_DISTRIBUTE( table [outer distribution] [innder distribution] ): Dient dem Verbessern der Parallel-Join-Verarbeitung. Folgende Paare sind für die Parameter 2 und 3 gültig: HASH, HASH: günstig bei gleich grossen Tabellen BROADCAST, NONE: alle Zeilen der äußeren Tabelle werden an alle Anfrageserver gesand (günstig bei kleiner äußeren Tabelle) NONE, BROADCAST: alle Zeilen der inneren Tabelle werden an alle Anfrageserver gesand PARTITION, NONE: Anhand der Partitionierung der inneren Tabelle werden die Zeilen der äußeren Tabelle an die Anfrageserver verteilt. Nur verwenden, wenn Anhand des Join-Keys partitioniert wurde und die n*anzahl Prozessoren in etwa der Anzahl der Anfrageserver entspricht) NONE, PARTITION: Äußere Tabelle ist partioniert, sonst siehe PARTITION, NONE NONE, NONE: beide Tabellen müssen anhand der Join-Werte partitioniert sein und jeder Anfrageserver behandlet diese anhand dieser. 2.5 Weitere Hints (NO)REWRITE erlaubt bzw. verbietet die Umschreibung des Statements zur Verwendung von materialized Views ORDERED garantiert die Join-Reihenfolge (von Links nach Rechts) ORDERED_PREDICATES Auswertung nach Reihenfolge innerhalb der Where-Klausel, ist der einzige Hint, der direkt nach WHERE steht STAR erzwingt das Joinen der größten Tabelle zum Schluß und sollte nur verwendet werden, wenn mindestens drei Tabelle gejoint werden. Die anderen beiden sollten Lookuptabellen sein. Dies wird oft bei DWH-Anwendungen verwendet. USE_CONCAT OR-Bedingungen in der WHERE-Klausel sollen durch ein UNION ALL abgebildet werden AND_EQUAL( table index1 index2 [index3 [..]] ) - Zeilen, die in allen Teilergebnissen vorkommen, werden in die Ergebnismenge übernommen. Achtung: Indizes müssen Indizes über genau eine Spalte sein. 10 / 15

11 3 Statistikinformationen 3.1 Statistiken Statistiken werden vom Optimizer herangezogen, um Kosten für Ausführungspläne zu schätzen. Sie Speichern Charakteristika von Tabellen und Indizes wie bpsw. die Anzahl der Tupel, die Anzahl der Blöcke und die durchschnittliche Länge eines Tupels, die Anzahl der Blattknoten und die Höhe eines Baumes. Statistiken müssen regelmäßig aktualisisert werden, um geänderten Datenbeständen gerecht zu werden und den Optimierer gute Entscheidungen treffen zu lassen. 3.2 Histogramme Histogramme beschreiben Ungleichverteilungen innerhalb einer Tabelle und können so Aussagen zur Selektivität einzelner Spalten geben. 3.3 Nutzung von ANALYZE TABLE Um die Statistiken für eine Tabelle zu erzeugen, kann folgendes Statement verwendet werden: ANALYZE TABLE tabelle COMPUTE STATISTICS Allerdings kann das komplette Berechnen unter umständen sehr lange dauern. Um dies zu umgehen, kann mittels folgendem Statement anhand von 5 Prozent der Zeilen eine ungefähre Statistik errechnet werden. Dies ist im allgemeinen auch ausreichend: ANALYZE TABLE tabelle ESTIMATE STATISTICS SAMPLE 5 PERCENT Zum löschen der Statistiken dient folgender Aufruf: ANALYZE TABLE tabelle DELETE STATISTICS 11 / 15

12 3.4 Nutzung von DBMS_STATS Oracle empfiehlt für das Erzeugen von Statistik-Informationen die Verwendung des Datenbankpakets DBMS_STATS. Die folgenden Statements sollen einen Überblick über die Verwendung der Methoden des Pakets DBMS_STATS geben: DBMS_STATS.GATHER_SCHEMA_STATS( 'IN0644', DBMS_STATS.AUTO_SAMPLE_SIZE ); DBMS_STATS.GATHER_SCHEMA_STATS( 'IN0644', ESTIMATE_PERCENT => 25 ); DBMS_STATS.GATHER_TABLE_STATS( 'IN0644', 'DBKUNDE'); DBMS_STATS.GATHER_INDEX_STATS( 'IN0644', 'DBKUNDE_INX'); Es können mittels vorhandener Methoden nicht nur einzeln Statistiken zu einer Tabelle oder zu einem Index erzeugt werden, sondern zu allen Tabellen bzw. Indizes innerhalb eines kompletten Schemas. Desweiteren erlauben verschiedene Funktionen des Pakets auch das kopieren, sichern und wiederherstellen von Statistiken. 12 / 15

13 4 Nutzung von IDEs Die Nutzung von integrierten Entwicklungsumgebungen kann den Entwurf und die Optimierung von Anfragen beschleunigen. So bieten viele IDEs schnellen Zugriff auf Ausführungspläne oder ermöglichen das direkte Editieren von Werten innerhalb der Ergebnismenge. Anhand der hier erwähnten Anwedungen SQL-Developer, welcher mit der Oracle-Client-Installation bereits mitgeliefert wird und der kommerziellen Software PL/SQL-Developer wird gezeigt, welche Schritte nötig sind, um den Ausführungsplan für ein Statement anzuzeigen. Die einzelnen Schritte sind dabei innerhalb der Bilder hervorgehoben 4.1 SQL-Developer 13 / 15

14 4.2 PL/SQL-Developer 14 / 15

15 5 Quellen Oracle Performance Tuning Guide 10g Release 2 (B ) Oracle SQL Tuning Mark Gurry, Wolfgang Gabriel O'Reilly, 2002 Datenbanken: Implementierungstechniken Gunter Saake, Andreas Heuer, Kai-Uwe Sattler mitp, 2005 Oracle 9i für den DBA Effizient konfigurieren, optimieren und verwalten Uwe Herrmann, Dierk Lenz, Günter Unbescheid, Johannes Ahrends Addison-Wesley, / 15