Probleme mit Cardinality-Feedback

Dieser Tage hat mir mein Bruder mitgeteilt, dass ich die Wendung "Dieser Tage" zu Einleitungszwecken etwas zu sehr strapaziere.

Dann vielleicht: gestern? Gestern also hat Jonathan Lewis in seinem Blog einen Artikel zum Cardinality-Feedback veröffentlicht, der auf einer Frage basiert, die vor einigen Tagen in Oracle-L aufgeworfen wurde - und bei der es darum ging, dass eine Query, die bei der ersten Ausführung eine angemessene Laufzeit aufwies, bei der zweiten Ausführung sehr langsam wurde, was sich auf die Wirkungen des Cardinality-Feedbacks zurückführen ließ. Nun gibt es eine ganze Reihe bekannter Bugs im Zusammenhang mit dem Cardinality-Feedback, aber im Artikel geht es nicht um einen Bug, sondern um eine grundsätzliche Beschränkung des Features.

Zur Klärung der Voraussetzungen noch mal die einführende Erklärung zum Thema aus dem Blog der CBO-Entwicklung (von Allison Lee, nehme ich an):

Cardinality feedback was introduced in Oracle Database 11gR2. The purpose of this feature is to automatically improve plans for queries that are executed repeatedly, for which the optimizer does not estimate cardinalities in the plan properly.

Das klingt zunächst wie eine gute Idee, aber der Herr Lewis konstruiert im Artikel ein relativ einfaches Beispiel dafür, wie der Optimierungsversuch ein unglückliches Ende finden kann - dann nämlich, wenn mehrere Tabellen im Spiel sind, zu denen die Schätzungen des CBOs nicht viel taugen: durch das Cardinality-Feedback wird im Beispiel der initiale Plan verworfen, weil die tatsächliche Satzanzahl für die erste Tabelle im Join um den Faktor 20 höher war als erwartet (2000 statt 100 Iterationen im NL-Join). Leider verschätzt sich der Optimizer bei der Erzeugung des neuen Plans bei der zweiten Tabelle aber um den Faktor 100 (20000 statt 200), so dass der neue Plan noch sehr viel ungünstiger ausfällt als die ursprüngliche Version. Und da Cardinality-Feedback nur einmal berücksichtigt wird, bleibt es dann bei der schlechteren Lösung. Mit einem Cardinality-Hint könnte man in 11.2 in einem solchen Fall gegensteuern und den geeigneteren Hash Join hervorrufen. In 12.1 wird für den Beispiel-Fall ein adaptive Plan erstellt und bei wiederholter Ausführung erhält man dann den gewünschten Hash Join - aber grundsätzlich gibt es das Cardinality-Feedback auch in 12.1 (unter dem Namen "Statistics Feedback"); obwohl es unter Oracles Optimierungsstrategien nicht unbedingt die beliebteste ist...