Godiva, minulý týden jsem měl možnost účasnit se školení, které poskytoval sir. Jonathan Lewis. Jestli u mě na blogu nejste poprvé zajisté jméno znáte. Nebudu hledat ty všechny články, kde jsem ho zmínil, ale minimálně jsem vychvaloval dvě jeho knihy CBO (přesný název Cost-Based Oracle Fundamentals) a Essential Internals for DBAs and Developers. Bohužel obě knihy ač jsou výborné trpí atributem “zastaralý”. Ostatně i sám Lewis to v úvodu CBO knihy píše, že vždy když si nastuduje nějakou verzi Oracle napíše k tomu knihu, že už v době releasu knihy je 2 verze Oracle pozadu. A bohužel tim, že je často řeč na pomezí interních věcí Oracle, které nejsou standardizovány, se vše mění dost podstatně (v porovnáním s knížkama jinýma, kde nás před velkou změnou mezi verzemi chrání SQL standard či snaha o backwards compatibilty). Ono vypadá, že některé věci by mohly zůstat přes všechny verze, protože třeba matematický výpočet selectivity na intervalu zůstane navždy stejný. Ovšem jakmile se přidají do toho histogramy, tak se to od verze od verze dost mění (ve 12c třebas nově větší histogramy >256 bucketu, Top N a hybridní histogram, interni vypocet je trošku jiný…). Tak či tak je to dobrá knížka a jedna z nejlepších o Oracle.
Přednáška byla rozdělat na tři části Designing Optimal SQL, Troubleshooting and Tuning a diskuze. Nejsem způsobilý k tomu, abych mohl recenzovat ani snad komentovat jak někdo vykládá. Prostě vpořádku, vypadá jak typický britský účitel a vykládat dost dobře. Pouze jedna poznámka, co se mi tom hodně líbilo a což jsem od něj tak čakal: Velmi často řiká “možná”, “když budete mít štěstí” atd. Do výkladu vkládá krásnou nestabilitu, nikoliv protože by nevěděl, ale protože ví, že jsou za tim další komplikovaná rozhodnutí CBO, které třebas nemá čas popisovat a které se třeba objevují jen zřídka. Alá: “na pořadí v jakém napíšu tabulky do joinu ve skutečnosti záleží” – nicméně to je na úrovni internal Oracle a je strašně nepravděpodobné, že to někdy někdo z nás uvidí či to bude problém. Lewis sice píše pořadí tabulek ve FROM klauzuli v nějakém specifickém pořadí nicméně důvodem neni performance ale čitelnost.
Fakt luxusní povidání, třebas se mi hodně líbilo jak si dal pozor na to, aby uvedl na pravou míru, že na reverzním indexu je opravdu možné použít operaci “range scan”, ovšem pouze a jenom na equality operátoru, jinak bohužel. Většina knížek se s tim nesere a napíše, že prostě “range scan” neni na možný na reverse indexu. Někde na svém blogu se o tom zminoval. Ostatně většinu věcí co vykládal jsem poznával, že je relativní ke konkrétnímu postu na jeho blogu.
Technologie, co popisoval byly známé. Nicméně jsem si vědom, že je možné někdo nezná, tedy dohledejte si případně – budu jen vyjmenovávat. A na konci, co bylo nového pro mou psa a chci si zapamatovat:
Designing Optimal SQL:
Zmíněné featury: index_join ,index_combine, index rebuild, index coalescence, clusters, data analysis, qb_name, readibility, leading, index, use_nl, use_hash, swap:_joins_inputs, full, no_push_subq, materialize, sql baselines, or explain gather_plan_statistic, adaptive curshor sharing, index_ffs.
A taky ukazoval zjednodušené vzorce pro NL/HASH/MERGE joiny. Bohužel to strašně zjednodušil a zrovna tam by mi zajímalo jaký benefit má nová implementace NL v 11g kdy se lehce prohodilo pořadí v exekučním plánu a přidalo bufferovani, aby se zvednula pravděpodobnost brani bloku z cache.
Pokud je query bloku větší množství tabulek, tak Oracle vezme jednu, přijoinuje druhou, třetí, čvrtou. Občas ale chceme join mezi 1 a 4 a join mezi 2 a 3 a teprve pak najoinovat na sebe výsledky. De-facto rozpadnout jeden query block na dva. Jonathan to nazval dvěma pojmy, které jsem předtím nikdy neslyšel: Left-deep (to co dělá Oracle 1,2,3,4) a Bushy tree (to co se mu snažíme vnutit my pomocí with as, zavorek, redesingu, unnest a no_unnest (1,4)@(2,3)). Další pozoruhodná poznámka byla, že Oracle 12c už je v tomhle chytřejší.
A co si odnáším páč jsem nevěděl:
- table_cached_blocks v dbms_stats u preferencích tabulky lze setnout i tenhle attribut
- index rebuild online – nejde na indexech enforsujícíh PK/UK, dobré vědět. Nadruhou stranu na 11+ Oracle je rebuild potřeba jen vyjmečně a zrovna u PK, kde by se sloupec neměl updatovat vubec, to vubec nevadi
- index rebuild online – vyžaduje stejně lock při applikování journalu (stejně jako při switch dbms_redefinition)
- sys_op_lbid – při mém štěstí jsem tuhle funkce už použil (jednou a nedávno :D), takže jsem věděl, nicméně stojí za připomenutí interní funkce vracící leaf block id z indexu na základě daného rowid
- materialize hint – nemá to ověřené ale temp tabulka je vždy když tabulku z with as odkazujeme více než jednou, což by krásně odpovídalo tomu co dělá star_transformation u které je to tak nějak naznačeno přímo v dokumentaci
- _optimalizer_adaptive_cursor_sharing – ha, zkrytý databázový parametr jak vypnout tuhle featuru Na úrovni statementu by mělo stačit normálně NO_BIND_AWARE hint, který teda Oracle zdokumentoval až ve 12c, pokud se nepletu.
Troubleshooting and Tuning
Zmíněné featury: ASH, session trace, sqlmonitoring, dbms_sqltune, v$sess_time_model , index reverse, cardinality hint, step by step slow processing, hprofiler, pragma udf, no segment indexy, invisible indexy, fixed views, waiting metriky, sql plan statistic, awr, obarvování sql, deklarace funkce with as v 12.1c
Jinak to bylo zajímavé povidání o konci tabulek a hot blokách, že trapných 600 session potkávajících se v library cache na jedno sql může udělat problém. A hodně řešil fixed views a data dictionary pohledy a ukazoval jak jsou napsány obecně a ne vždy se hodí z peformance důvodu – aneb view je query blok (pokud to oracle neztransformuje) optimalizovaný zvlášt a maximálně tam může pushnout predikát, což ne vždy stačí.
A co si odnáším páč jsem nevěděl:
- index reverse – nikdy jsem nad tím nepřemýšlel, ale index reverse pochopitelně ovlivní clustering_factor (česky: nejspíše ho totálně rozmrdá)
- temporary tabulky sice mají na 12c vlastní statistiky pro usery, ale ne by default, navíc jdou setnout do temporary tablespace
- dbms_stats.num_array – musim si zkusit
- mohu sám setnout clustering_factor na indexu
- virtual column + check constraint (+hidden ideálně na 12c) může pomoci exekučnímu plánu. Check je pochopitelně vyčerveněno schválně, protože fakt to Oracle umí i s expression (COOL !)
- pragma udf – uplně jsem na ní zapomněl. PL/SQL funkce volaná z SQL – pomůže to eliminovat overhead na přepinání contextu nez pl/sql a sql engines (ač tomu Lewis řikal lehce jinak). Nicméně na 12.1 je tohle rychlejšejší.
- v$sql_workarea_histogram – luxusni view, neznal jsem
Diskuze
To bylo dost volné řešily se MVIEW Logy, ukazoval parallení exekuci a nějaká menší zmínka o DBMS_REDEFINITION, SQL Baselines a pár nelichotivých poznámek na 12c Na mých slovíčkách ze švédštiny se třebas objevil na 12c nový sloupec neb Oracle přišel na to, že je tam nějaká kolerace, takže si chlapec založil virtuální sloupec a hodil na něj extented statistiky, nicméně lze vypnout a jen nechat Oracle to reportovat.
A co si odnáším páč jsem nevěděl
- treedump indexu bloku jsem nikdy nezkoušel, vypadá zajímavě (eventu nepamatuji)
- Pokud jsem to dobře pochopil, tak rozpartišnování tabulky pujde na 12.2 ONLINE wohowo
- DBMS_REDEFINITION a aplikace journalu – Jonathan o tom mluvil, jako že aplikace journalu muže nějaký čas trvat a vyžaduje LOCK, musim zjistit – do ted jsem si myslel, že po synchronizaci hlavni tabulky, mužu/bude journal ještě pořád sychrnonizován online a obecně mužu dosynchrnizovovát libovolně dokud to neni skoro fresh a pak teprve LOCK.
- 40x ? Jestli jsem slyšel dobře tak overhead na MATERIALIZED VIEW LOG je 40 rekurzivnich selectu – budu muset najit, přijde mi to podezřele vysoké
Bloom filtr – tohle je hroznej chyták, funguje to od Oracle 10g a zdokumentováno to bylo až v 12.1c. Lewis mluvil o tom, že v 11g se to neukazuje v exekučním plánu. Což je možná dobré upřesnit, protože záleží na tom který. Bloom fitr na úrovni filtrování rows při paralelní exekuci je v plánu jen v OTHER/XML na 11.2. Ovšem i na 11.2 je vidět v exekučním plánu pokud je to na úrovni partitions – prostě eliminace partitions na bloom filtru.
Suma sumárum hodně děkuji svému zaměstanavateli za luxusní školení, nevim koho bych na školení raději než Lewise určitě zajímavější než Kyte. Možná ještě zajímavej by byl Julian Dyke (+ a pochopitelně jakákoliv prsatá samička, která třebas ani Oracle nezná ale nosí těsné džíny)
