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.
Sie können Datenbankoptionen und andere globale Einstellungen anzeigen, die sich auf die Abfrageausführung bei den Stamm-Operatorknoten auswirken.
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.
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.
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.
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.
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |