12-05-2013 door: Patrick Diks
Bij het analyseren van een ongunstige plankeuze door de Oracle optimizer liep ik laatst tegen een situatie aan waar er een cardinaliteit van één in het plan stond waar er tienduizenden verwacht waren.
De index statistieken waren redelijk in lijn met het verwachte aantal rijen, waarom dan toch de misser in het plan?
Het euvel bleek in een histogram te huizen. De statistieken werden in de nacht berekend en er kwamen op de dag nieuwe records in de tabel die met de betreffende query weer opgehaald werden voor verwerking aan de hand van een jobid.
Het (frequency) histogram bevatte bijvoorbeeld de aantallen records voor jobid 100 t/m 120 en die dag werd job 121 gedraaid.
De optimizer ziet bij een bind peek in de hard parse het nieuwe jobid en denkt dat deze niet in de tabel voorkomt omdat deze boven de maximale high_value in het histogram ligt.
In de verdere berekening wordt hierdoor met één gerekend wat het ongunstige plan veroorzaakt heeft.
Hoewel dit gedrag redelijk natuurlijk volgt uit de informatie uit de statistieken vraag ik me toch af of er wel een situatie is waar dit positief uitwerkt. Er moeten wel heel vaak niet bestaande gegevens opgevraagd worden wil een plan dat hiervan uitgaat het gemiddeld winnen van een plan dat uit gaat van wel bestaande rijen.