Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » SQL Anywhere Server - SQL-Benutzerhandbuch » Abfrageverarbeitung » Abfragen optimieren und ausführen » Ausführungspläne lesen » Grafische Pläne lesen

 

Performanceanalyse mittels grafischem Plan mit Statistiken

Sie können den grafischen Plan mit Statistik verwenden, um Datenbank-Performanceprobleme zu identifizieren. Detaillierte Feldbeschreibungen des grafischen Plans mit Statistik finden Sie unter Knotenstatistiken-Feldbeschreibungen und Optimiererstatistiken-Feldbeschreibungen.

Abfrageausführungsprobleme erkennen

Sie können Datenbankoptionen und andere globale Einstellungen anzeigen, die sich auf die Abfrageausführung bei den Stamm-Operatorknoten auswirken.

Selektivitätsperformance überprüfen

Die Selektivität eines Prädikats (bedingter Ausdruck) ist der Prozentsatz von Zeilen, die die Bedingung erfüllen. Die geschätzte Selektivität von Prädikaten liefert die Informationen, auf denen der Optimierer seine Kostenschätzungen aufbaut. Eine genaue Selektivitätsschätzung ist für die ordnungsgemäße Funktion des Optimierers ausschlaggebend. Wenn der Optimierer beispielsweise versehentlich ein Prädikat für höchst selektiv hält (z.B. eine Selektivität von 5%), das Prädikat jedoch sehr viel weniger selektiv ist (z.B. 50%), dann kann die Performance darunter leiden. Auch wenn Selektivitätsschätzungen nicht immer präzise sind, kann ein außergewöhnlich großer Fehler auf ein Problem hinweisen.

Wenn Sie feststellen, dass die Selektivitätsinformationen für einen Schlüsselabschnitt Ihrer Abfrage nicht stimmen, können Sie möglicherweise CREATE STATISTICS verwenden, um eine neue Reihe von Statistiken für die Spalte(n) zu generieren. In seltenen Fällen können Sie explizite Selektivitätsschätzungen vorgeben, obwohl dieses Vorgehen zu Problemen führen kann, wenn die Statistiken später aktualisiert werden.

Selektivitätsstatistiken werden nicht angezeigt, wenn die Abfrage als eine Bypass-Abfrage festgelegt ist. Weitere Hinweise zu Bypass-Abfragen finden Sie unter So funktioniert der Optimierer und Explizite Selektivitätsschätzungen.

Indikatoren für eine schlechte Selektivität treten an folgenden Stellen auf:

  • RowsReturned, tatsächlich und geschätzt   RowsReturned ist die Anzahl der Zeilen in der Ergebnismenge. Die RowsReturned-Statistik wird in der Tabelle für den Stammknoten an der Spitze der Struktur angezeigt. Wenn die geschätzte Zeilenanzahl deutlich von der tatsächlichen Zeilenanzahl abweicht, ist möglicherweise die Selektivität von den diesem Knoten oder dieser Unterstruktur zugeordneten Prädikaten falsch.

  • Prädikat-Selektivität, tatsächlich und geschätzt   Suchen Sie nach dem Subheader Predicate, um die Prädikat-Selektivitäten einzusehen. Hinweise zum Lesen der Prädikatinformationen finden Sie unter Selektivität im grafischen Plan anzeigen.

    Wenn das Prädikat für eine Basisspalte gilt, für die kein Histogramm vorhanden ist, kann das Problem eventuell behoben werden, indem durch die Ausführung einer CREATE STATISTICS-Anweisung ein Histogramm erstellt wird. Weitere Hinweise finden Sie unter CREATE STATISTICS-Anweisung.

    Wenn der Selektivitätsfehler weiterhin Probleme bereitet, könnten Sie eine Benutzerselektivitätsschätzung mit dem Prädikat im Abfragetext angeben.

  • Estimate source (Quelle der Schätzung)   Die Quelle der Selektivitätsschätzungen ist ebenso unter dem Prädikat-Subheader im Fensterausschnitt Statistik aufgelistet.

    Wenn die Quelle einer Prädikat-Selektivitätsschätzung Guess (Annahme) ist, hat der Optimierer keine verwertbaren Informationen, um die Filtermerkmale dieses Prädikats zu ermitteln, was möglicherweise auf ein Problem hinweist (wie z.B. ein fehlendes Histogramm). Falls die Quelle für die Schätzung Index und die Selektivitätsschätzung falsch ist, kann das Problem durch einen unausgeglichenen Index verursacht sein. In so einem Fall kann es vorteilhaft sein, den Index mit der Anweisung REORGANIZE TABLE zu defragmentieren. Weitere Hinweise finden Sie unter REORGANIZE TABLE-Anweisung.

Cache-Performance überprüfen

Wenn die Anzahl der Cache-Lesevorgänge (CacheRead) und die der Cachetreffer (CacheHits) gleich sind, befinden sich alle Objekte, die bei dieser SQL-Anweisung verarbeitet werden, im Cache. Wenn es mehr Cache-Lesevorgänge als Cachetreffer gibt, zeigt dies, dass der Datenbankserver Tabellen- oder Indexseiten vom Plattenspeicher liest, weil sie sich noch nicht im Cache des Datenbankservers befinden. Unter bestimmten Umständen, z.B. bei Hash-Joins, ist dies zu erwarten. In anderen Fällen, wie z.B. bei Nested-Loops-Joins, kann ein schlechtes Cachetreffer-Verhältnis darauf hinweisen, dass nicht genügend Cache (Pufferpool) vorhanden ist, um die Abfrage effizient auszuführen. In diesem Fall ist es sinnvoll, die Cachegröße des Datenbankservers zu erhöhen.

Weitere Hinweise zur Cacheverwaltung finden Sie unter Die Cachegröße erhöhen.

Ineffiziente Indizes identifizieren

Häufig ist auch mit Abfrageausführungsplänen nicht eindeutig ersichtlich, ob die Performance durch Indizes gesteigert werden könnte. Manche der auf Scans basierenden Algorithmen, die in SQL Anywhere verwendet werden, bieten eine hervorragende Performance für viele Abfragen, ohne dass Indizes verwendet werden.

Weitere Hinweise zu Indizes und Performance finden Sie unter Indizes effizient verwenden und Indexberater.

Probleme mit der Datenfragmentierung identifizieren

Die tatsächlichen und geschätzten Werte Runtime und FirstRowRunTime sind in den Stammknoten-Statistiken enthalten. Nur RunTime wird im Abschnitt Verzweigungsstatistiken angezeigt, wenn für diesen Knoten ein Wert vorhanden ist.

Die Interpretation von RunTime hängt vom Statistikabschnitt ab, in dem der Wert angezeigt wird. In Knotenstatistiken ist RunTime die kumulative Zeit, die der Operator für das Ausführen nur dieses Knoten aufgewendet hat. In Verzweigungsstatistiken stellt RunTime die Gesamt-Ausführungszeit dar, die der Operator für das Ausführen der Unterstruktur unmittelbar unterhalb dieses Knotens aufgewendet hat. Daher sind RunTime und FirstRowRunTime bei den meisten Operatoren voneinander unanhängige Messwerte, die separat analysiert werden sollten:

FirstRowRunTime ist die Zeit, die benötigt wird, um die erste Zeile des Zwischenergebnisses von diesem Knoten zu liefern.

Wenn RunTime eines Knotens für einen Table-Scan oder einen Index-Scan höher als erwartet ist, können Sie die Performance möglicherweise verbessern, indem Sie die REORGANIZE TABLE-Anweisung ausführen. Sie können die Systemprozeduren "sa_table_fragmentation()" und "sa_index_density()" verwenden, um festzustellen, ob die Tabelle oder der Index fragmentiert ist.

Weitere Hinweise finden Sie unter REORGANIZE TABLE-Anweisung und Tabellen-Fragmentierung reduzieren.

Weitere Hinweise zu den im Plan verwendeten Codewörtern finden Sie unter Abkürzungen im Ausführungsplan.