Názor ke článku Problémy optimalizace SQL dotazů a jejich teoretická řešení od Ivan Brezina - O adaptivni optimizer se Oracle pokusil v verzi...

O adaptivni optimizer se Oracle pokusil v verzi 12c, aby to posleze ve verzi 18c nechali by default vypnute. Ta myslenka ze by se databaze adaptivne prizpusobovala zatezi je hezka ale bohuzel to vede casto k nestabilite celeho systemu.
Takze kdyz shrnu problemy ktere verze 12c prinesla:

- adaptivni plany. Ono je hezke za jizdy preklopit nested-loop na hash join. Pokud do ale vyzaduje narocnou udrzbu metadatat, tak ze to casto ani nevyplati
- adaptivni statistiky. background job se snazi analyzovat jiz spustene plany, hledat korelovane sloupce a vytvaret statistiky nad n-ticemi sloupcu. Bohuzel nikomu nedoslo, ze tech n-tic muze byt opravdu hodne a ze prochazeni temito statistikami muze zamestnat optimizer na hodne dlouho.
- adaptivni statistiky (jeste jednou ve 12.1) epicky fail, kdy Oracle nedokaze ulozit extended statistiky v dictionary cache a pokazde je musi behem parsovani nacitat znovu z disku
- cardinality feedback. ono je tezke rozhodnout jestli je lepsi exec plan ktery ma prumerny cas zpracovani 2 sec (a 10 sec v nejhorsim pripade). Zatimto jiny ma prumerny cas zpracovani 3 sec ve vsech pripadech. Muze se stat, ze data skew u jednoho uzivatele rozbije exec plan pro vsechny ostatni. Pokud se exec plan zmeni nekolikrat za hodinu tak se muze stat, ze to nakonec cele dokonverguje k nejakemu uplne pitomemu planu.
- exec plan directives. ono to zni hezky, ze by spusteni exec planu po sobe zanechalo metadata, ktera by se mohla hodit pri dalsi optimalizaci. Proc je to ale v XML formatu a co delat, kdyz je tech direktiv obludne mnozstvi?

- Co se povedlo a s cim nejsou problemy je buffered nested loop, kdy si jednotlive casti exec planu nepredavaji jen jednu radku ale buffer s vetsim mnozstim dat.