

Prijavite se ili ako nemate nalog registrujte se.
Prikaži opcije









Dok sam u više navrata čitao kako pojedini administratori Oracle baze podataka bacaju drvlje i kamenje na CBO (Cost Based Optimizer), mislio sam da oni nisu pravilno konfigurisali bazu ili da imaju neprikladan hardware (premalo RAM-a i slabi CPU resursi), jer zaboga - kako CBO, kojeg Oracle diže u nebesa i sa garancijom stoji iza svog tehnološkog čeda, može POGREŠNO da “naredi” bazi kako da pristupa podacima!? E, pa može! I nisu ti administratori bez razloga kukali na pogrešno funkcionisanje CBO-a …
To tvrdim iz ličnog iskustva, jer sam se iznenadio i iskreno začudio, kako CBO mijenja svoju ćud.
Instalirali mi zadnji 10.2.0.4 patch (zakrpa), u kojem su bili ispravljeni neki bugovi iz prethodnih verzija, ali se ispostavilo da i ova zakrpa ima rupu - i to više njih. Najočiglednije je bilo drastično povećanje vremena potrebnog za izvršavanje pojedinih aplikacija. Npr. jedan batch job, koji normalno bude gotov za pola sata, odjednom treba 6 sati da završi posao. Mnogi SQL upiti su u odnosu na prije trošili nenormalno puno CPU resursa ili su bjesomučno radili Full Table Scan umjesto Index Range Scan.
Provjerili smo hardware, da nije nešto crklo - sve je bilo u redu. System administratori nisu ništa mijenjali na nivou operativnog sistema. Jedino na šta smo sumnjali je bio taj zadnji patch 10.2.0.4, a kako se ispostavilo - tu je i ležao “problem”.
Nakon DETALJNOG čitanja pratećih informacija vezanih za 10.2.0.4 patch, pronašao sam par zanimljivih stvari vezanih za CBO i nedokumentovane parametre. Slijedi copy-paste sa objašnjenjem:
“To enable a new native full outer join implementation in the database, a user has to set the following underscore parameter:
_optimizer_native_full_outer_join =force
You can set this parameter for the system or for a specific session.
Besides dramatically improving the performance of a full outer join, the new implementation fixes a variety of issues, for examples a variety of ORA-942 (table or view doesn’t exists) and ORA-4331 (unable to allocate string bytes of shared memory) errors.
This issue is tracked with Oracle bug 6322672.”
Aha - znači CBO sad drugačije posmatra full outer join. I ne samo to, nego i ostale kompleksne join kombinacije. Npr. za bug 7189447 pod naslovom “Wrong results when view merging applied to query” predlažu “zavaravanje” CBO-a korištenjem Optimizer Hinta “NO_MERGE“, kako bi Cost Based Optimizeru rekli da ne radi to onako kako on misli da treba, nego malo drugačije:
“Wrong results are possible when the connecting condition of a subquery refers to an aggregating column of a group-by view. The problem is that the column is not recognized as a correlating column and consequently the view is merged when it should not be.
Workaround:
Add a NO_MERGE hint to the subquery block to prevent it from being merged or set “_complex_view_merging”=FALSE
at the system level.”
I tako postavim ja te nedokumentovane parametre na nivou baze:
alter system set “_complex_view_merging”=FALSE scope=spfile sid=’*';
alter system set “_optimizer_native_full_outer_join”=FORCE scope=spfile sid=’*';
kad gle čuda!!!!
Onaj batch job odjednom ne treba više 6 sati, nego 20-30 minuta, a killer-SQL upiti se ponašaju kao mirne ovce dok pasu na livadi.
Dakle, postavlja se pitanje - da li uvijek slijepo vjerovati Cost Based Optimizeru ili ga pokušati “prevariti” nedokumentovanim parametrima?
Ko zna kako će se CBO ponašati nakon nove zakrpe i kako će ti parametri uticati na CBO…
Blogodak je vaš pogled na domaću blogosferu. Prijavite se i napravite sopstvenu listu blogova koje pratite.