Die Möglichkeiten des Plan-Managements sind in aktuellen Oracle-Releases bekanntlich recht umfangreich: neben den historischen Stored Outlines gibt es SQL Plan Baselines, SQL Profiles und SQL Patches. Jede dieser Techniken hat ihre Anwendungsbereiche - und ihre Beschränkungen. Franck Pachot beschäftigt sich in seinem jüngsten Artikel mit SQL Profiles und untersucht die Frage, wieso ein Profile für eine einzelne Tabelle mehrere OPT_ESTIMATE Hints enthalten kann (die die Cardinality-Schätzungen des Optimizers modifizieren). Zur Erinnerung noch mal eine minimale Definition für SQL Profiles: sie sind eine Sammlung von ergänzenden Hints, die der Optimizer für eine Query anlegt, wenn man ihm die Zeit lässt, seine Arbeit in Ruhe durchzuführen - statt unter dem üblichen OLTP-Zeitdruck; für Data Warehouse Systeme (oder wie man die Nicht-OLTP-Systeme sonst einordnen mag) kann das eine ziemlich gut Idee sein, wenn das Parsen gegenüber der Ausführung einer Query kaum ins Gewicht fällt. Aber zurück zum Artikel: durch einen Blick ins CBO-Trace wird klar, dass das mehrfache Erscheinen der Hints den unterschiedlichen Transformationen geschuldet ist, die der Optimizer im Rahmen seiner Optimierungsversuche durchspielt. Ausgehend von dieser Beobachtung kommt der Herr Pachot zu folgendem Schluss:
That observation brings me to the following: what happens to your profiles when you upgrade to a version that brings new optimizer transformations? The optimizer will compare some plans with adjusted cardinalities, compared with some plans with non-adjusted cardinalites. And that is probably not a good idea.In my opinion, SQL Profiles are just like hints: a short term workaround that must be documented and re-evaluated at each upgrade.
Und das würde ich grundsätzlich unterschreiben - wobei ich mir vorstellen könnte, dass es Umgebungen gibt, in denen es sinnvoll wäre, wenn man dem Optimizer grundsätzlich mehr Zeit zum Nachdenken gibt; aber das wäre wieder ein anderes Feature.
Keine Kommentare:
Kommentar veröffentlichen