Oracle 11g, das Ende des Bind-Peeking-Problems
Meldung vom 01.02.2012
Der Abfrageoptimierer in Oracle 11g ermittelt den optimalen Ausführungsplan bei der Anfrage von Datenbanken. Dabei analysiert er bei dem ersten Aufruf des Cursors die tatsächlich verwendeten Werte der benutzerdefinierten Bind-Variablen als wären sie als Literale angegeben („bind-peeking“). Auf diese Weise kann der Optimizer die Selektivität der WHERE - Klausel ermitteln, als wären anstelle von Bind-Variablen Literale genutzt worden.
Für die optimale Wahl des Cursors bei einem gegebenen Bind-Wert, nutzt die Oracle Datenbank das „Bind-aware Cursor Matching“. Dieses System überwacht den Datenzugriff, welcher von der Anfrage, in Abhängigkeit von den Bind-Werten, durchgeführt wird. Wenn „Bind-Peeking“ stattfindet und ein Histogramm für die Berechnung der Auswahl des Prädikats genutzt wird, welches die Bind-Variable enthält, ist der Cursor markiert als ein bind-sensitive Cursor.
Immer dann wenn ein Cursor dazu bestimmt ist signifikant verschiedene Zugriffspfade abhängig von den Bind-Werten herzustellen, wird dieser Cursor als bind-aware markiert und die Oracle Datenbank wechselt zu „Bind-aware Cursor Matching“, um den Cursor für dieses Statement auszuwählen. Wenn das „Bind-aware Cursor Matching“ aktiviert ist, werden Pläne basierend auf dem Bind-Wert und der Einschätzung der Selektivität des Optimizers ausgewählt. Dank dem Einsatz des „Bind-aware Cursor Matching“ ist es möglich, dass ein SQL-Statement mit einer benutzerdefinierten Bind-Variable abhängig von den Bind-Werten über mehrere Ausführungspläne verfügt.
Wenn Bind-Variablen in einem SQL-Statement genutzt werden ist davon auszugehen, dass Cursor-Sharing beabsichtigt ist und dass verschiedene Aufrufe denselben Ausführungsplan nutzen. Wenn verschiedene Aufrufe des Cursors erheblich von anderen Ausführungsplänen profitieren würden, ist Bind-aware cursor matching notwendig. „Bind Peeking“ funktioniert nicht für alle Clients, sondern nur für eine bestimmte Auswahl.
Dazu folgendes Beispiel:
SELECT avg(e.salary), d.department_name
FROM employees e, departments d
WHERE e.job_id = :job
AND e.department_id = d.department_id
GROUP BY d.department_name;
In diesem Beispiel sind die Werte der Spalte job_id erheblich ungleich verteilt, weil es mehr Sales Representatives als Vice Presidents gibt (job_id = 'AD_VP'). Darum hängt der beste Plan für diese Abfrage von dem Wert der Bind-Variable ab. In diesem Fall ist es effizienter, einen Index zu nutzen wenn job_id gleich AD_VP ist und einen Full Table Scan, wenn die job_id gleich SA_REP ist. Der Optimizer schaut auf den ersten Wert ('AD_VP') und wählt einen Index. Der Cursor wird markiert als bind-sensitive. Wenn die Abfrage beim nächsten Mal durchgeführt wird und der Bind-Wert ist MK_REP (Marketing Representative), wobei dieser Bind-Wert wenig Selektivität besitzt, kann der Optimizer sich dafür entscheiden, den Cursor als bind-aware zu markieren und das Statement mit einem Hard-Parse neu zu parsen, um einen neuen Plan zu generieren, der einen Full Table Scan durchführt.
Die Selektivitätsbereiche, Cursor Informationen (z.B. ob ein Cursor bind-aware oder bind-sensitive ist) und Ausführungsstatistiken sind mittels V$ views für erweitertes Cursor-Sharing verfügbar. Die Ansicht V$SQL_CS_STATISTICS enthält Ausführungsstatistiken für jeden Cursor und kann für das Performance Tuning genutzt werden, indem die Cursor-Ausführungen welche mit verschiedenen Bind-Sets generiert wurden, verglichen werden.
Quelle: http://docs.oracle.com/cd/B28359_01/server.111/b28274/optimops.htm#autoId11
Autor: Thilo Solbrig (Oracle Certified Master)
Sie kennen das Bind-Peeking Problem aus eigener Erfahrung? Warum dem nicht Abhilfe schaffen und auf Oracle 11g upgraden?
Die Firma ASPICON steht Ihnen dabei gern mit Rat und Tat zur Seite!
Ihre Ansprechpartner:
Dirk Melzer und Dirk Richter
Tel.: +49.371.909515-100
Mail: vertrieb@aspicon.de
Zurück
