Oppiva kyselynoptimointi

Oppiva kyselynoptimointi Kustannusperustaisen optimoijan ongelmia ja yksi ratkaisu: Oppiva optimoija. Riku Räsänen Kantamestarit OY riku.rasanen@kantamestarit.fi 1

Sisältö Kustannusperustainen optimointi ja sen ongelmia Yleiskatsaus kustannusperustaiseen optimointiin Ongelmia Kyselyn seuraaminen Staattinen oppiminen Dynaaminen oppiminen Tulevaisuus? 2

Kustannusperustainen optimointi: Pikainen yleiskatsaus SQL on ilmaisuvoimainen kieli, jolla käyttäjä kertoo mitä tietoa käsitellään. Tietokannanhallintajärjestelmän tehtäväksi jää se, miten tietoa käsitellään. SQL-lause voidaan suorittaa useilla eri tavoilla, jotka kaikki palauttavat saman tuloksen, mutta joiden suoritusajoissa saattaa olla valtavia, jopa useiden kertaluokkien eroja. Optimoijan tehtävänä on valita SQL-lauseelle mahdollisimman tehokas suoritussuunnitelma. Kustannusperustainen optimoija (cost-based optimizer, CBO) generoi SQL-lauseelle (periaatteessa) kaikki suoritussuunnitelmien permutaatiot, arvioi kullekin kustannuksen ja valitsee tehokkaimman suoritussuunnitelman. Optimoija analysoi SQL-lauseen ja pyrkii arvioimaan kuinka monta riviä / blokkia suoritussuunnitelman operaatio käyttää. Tähän optimoija tarvitsee tietokannan objekteista kerätyt tilastotiedot, kuten taulun rivien lukumäärän. Lopullinen kustannus on useimmiten eri tekijöiden painotettu summa, yleensä eniten painoa annetaan IO-kustannukselle. 3

Kustannusperustainen optimointi: Predikaatti, kardinaliteetti ja selektiviteetti Kardinaliteetti (pilkunviilajille monikkojen lukumäärä ) ja selektiviteetti ( valitsevuus ) ovat keskeisiä käsitteitä optimoinnissa. Kardinaliteetti kertoo rivien lukumäärän, selektiviteetti kertoo kuinka iso osa riveistä täyttää annetun predikaatin eli ehdon, kuten valintaehdon tai liitosehdon. 4

Kustannusperustainen optimointi on hyvä juttu, mutta ei ongelmaton Kustannusperustainen optimointi on älykäs ratkaisu: Optimoija osaa (teoriassa) ilman käyttäjän apua valita optimaalisen, tai edes hyvän, suoritussuunnitelman SQL-koodaajan ei tarvitse tietää miten optimoijaa huijataan käyttämään tai olemaan käyttämättä indeksejä, missä järjestyksessä taulut pitää nimetä FROM-osassa, jne... Sama sovellus eri datoilla voi vaatia toisessa tapauksessa indeksin, toisessa tauluselauksen käyttöä. Kustannusperustaista optimoijaa käytettäessä ei ole tarvetta tehdä eri SQL-lauseita näille tapauksille. Kustannusperustainen optimoija on kuitenkin altis useille ongelmille. Katsotaan muutamia tarkemmin. 5

Kustannusperustaisen optimonnin ongelmia: Monimutkaiset SQL:t Teoreettinen kustannusperustainen optimoija generoi SQL-lauseelle kaikki suoritussuunnitelmien permutaatiot. Ongelmaksi muodostuu permutaatioiden lukumäärä, joka kasvaa eksponentiaalisesti liitosten lukumäärän kasvaessa [13]. Koska hyvin monimutkaisissa SQL-lauseissa optimointiaika venähtäisi kohtuuttomaksi, optimoijat käyttävät yleensä menetelmiä permutaatioiden määrän vähentämiseksi. Jo varhain on käytetty dynaamista ohjelmointia, jolla voidaan loiventaa eksponentiaalisuuden kerrointa. Tämän tapainen menetelmä on myös käytössä Oraclessa. Oraclessa liitosjärjestys pyritään tekemään kasvavassa suuruusjärjestyksessä, ja optimoijalla on permutaatioille raja-arvo, OPTIMIZER_MAX_PERMUTATIONS. Raja-arvon käyttäminen kuitenkin tarkoittaa, että teoriassa on mahdollista, että optimoija ei löydä tehokkainta suoritussuunnitelmaa. 6

Kustannusperustaisen optimonnin ongelmia: Tilastot Optimaalisen suoritussuunitelman valitsemiseen optimoija tarvitsee mahdollisimman tarkat tilastot. Mitä tarkemmat tilastot, sitä parempi (ainakin teoriassa!). Tilastot eivät kuitenkaan aina ole ajan tasalla, eivätkä aina riittävän tarkkoja. Pahimmissa tapauksissa esimerkiksi histogrammien tarkkuus ei riitä kuvaamaan tarpeeksi tarkasti sarakkeen arvojen jakaumissa olevia piikkejä / reikiä, jolloin kardinaliteettiarvioihin syntyy virhettä... ja monimutkaisissa SQL-lauseissa virheillä on taipumusta kertautua. 7

Kustannusperustaisen optimonnin ongelmia: Tilastot (jatkoa...) Yksinkertainen esimerkki (tarkat tilastot, mutta ei histogrammeja): SELECT * FROM dd_objects obj WHERE owner = 'SYS'; --------------------------------------------------------------- Id Operation Name Rows --------------------------------------------------------------- 0 SELECT STATEMENT 2853 1 TABLE ACCESS BY INDEX ROWID DD_OBJECTS 2853 * 2 INDEX RANGE SCAN IDX_DDOBJ_OWNER 2853 --------------------------------------------------------------- Histogrammien kanssa: ------------------------------------------------ Id Operation Name Rows ------------------------------------------------ 0 SELECT STATEMENT 21606 * 1 TABLE ACCESS FULL DD_OBJECTS 21606 ------------------------------------------------ 8

Kustannusperustaisen optimonnin ongelmia: Korrelaatio Esimerkki (taulussa täydelliset tilastot ja kyselyssä käytetyissä sarakkeissa indeksit ja frekvenssihistogrammit): SELECT object_id FROM dd_objects WHERE owner = 'SYS' AND object_type = 'SYNONYM'; ------------------------------------------------ Id Operation Name Rows ------------------------------------------------ 0 SELECT STATEMENT 8759 * 1 TABLE ACCESS FULL DD_OBJECTS 8759 ------------------------------------------------ Toteutunut: Rows Row Source Operation ------- ----------------------------- 6 TABLE ACCESS FULL DD_OBJECTS 9

Kustannusperustaisen optimonnin ongelmia: Korrelaatio (jatkoa...) Miksi optimoija tekee näin ison virheen (8759 vs. 6)? Optimoija tietää kyllä, että SYS omistaa 21526 objektia ja että objekteista 18539 on synonyymejä, mutta...... optimoijalla ei ole mitään tilastoa, joka kertoisi sarakkeiden OWNER ja OBJECT_TYPE välisestä korrelaatiosta. Niinpä optimoija tekee tyypillisen oletuksen, että predikaatit OWNER='SYS' ja OBJECT_TYPE='SYNONYM' ovat toisistaan riippumattomia ja yksinkertaisesti kertoo näiden valitsevuudet keskenään. ROUND (((21526 / 45562) * (18539 / 45562)) * 45562 ) = 8759 10

Kustannusperustaisen optimonnin ongelmia: Korrelaatio (jatkoa...) Korrelaatio-ongelma ( independence of predicates ) [2] on hankala, koska se on riippuvainen datasta: Ongelma esiintyy usein luonnollisessa datassa Ongelmatapaukset, kuten esimerkin tapaus, voidaan ratkaista esim. SQL-vihjeillä (hints). Tämä tarkoittaisi, että jokainen tapaus pitäisi koodata erikseen mutta...... sama sovellus voi eri dataseteillä sisältää erilaisia korrelaatioita ja...... vaikka joku jaksaisi väsätä ko. SQL:t, Library Cache kuormittuisi periaattessa samanlaisilla SQL-lauseilla. Optimoijalla pitäisi olla keino ratkaista tämä ongelma OPTIMIZER_DYNAMIC_SAMPLING tasolta 4 alkaen auttaa, mutta ei ratkaise kaikkia ongelmia 11

Kustannusperustaisen optimonnin ongelmia: Liitokset Liitoksissa optimoija turvautuu usein oletuksiin. Esimerkki: SELECT * FROM dd_objects obj JOIN dd_users usr ON (obj.owner# = usr.user_id); ------------------------------------------------- Id Operation Name Rows ------------------------------------------------- 0 SELECT STATEMENT 45649 * 1 HASH JOIN 45649 2 TABLE ACCESS FULL DD_USERS 17 3 TABLE ACCESS FULL DD_OBJECTS 45649 ------------------------------------------------- Rows Row Source Operation ------- --------------------------------------------------- 27132 HASH JOIN (cr=2387 pr=0 pw=0 time=520974 us) 17 TABLE ACCESS FULL DD_USERS (cr=3 pr=0 pw=0 time=487 us) 45649 TABLE ACCESS FULL DD_OBJECTS (cr=2384 pr=0 pw=0 time=593837 us) Pieleen lähes kertoimella 0,5. DD_OBJECTS-taulussa on PUBLICkäyttäjän omistamia objekteja, mutta PUBLIC-käyttäjää ei ole DD_USERS-taulussa. 12

Kustannusperustaisen optimonnin ongelmia: Liitokset (jatkoa...) Sekoitetaan mukaan korrelaatio ja optimoija turvautuu arvauksiin: SELECT * FROM dd_objects obj JOIN dd_users usr ON (obj.owner# = usr.user_id) WHERE usr.username = 'OUTLN'; ---------------------------------------------------------------- Id Operation Name Rows ---------------------------------------------------------------- 0 SELECT STATEMENT 1427 1 TABLE ACCESS BY INDEX ROWID DD_OBJECTS 2853 2 NESTED LOOPS 1427 * 3 TABLE ACCESS FULL DD_USERS 1 * 4 INDEX RANGE SCAN IDX_DDOBJ_OWNER# 2853 ---------------------------------------------------------------- Rows Row Source Operation 7 TABLE ACCESS BY INDEX ROWID DD_OBJECTS (cr=10 pr=0 pw=0 time=614 us) 9 NESTED LOOPS (cr=7 pr=0 pw=0 time=3294 us) 1 TABLE ACCESS FULL DD_USERS (cr=4 pr=0 pw=0 time=274 us) 7 INDEX RANGE SCAN IDX_DDOBJ_OWNER# (cr=3 pr=0 pw=0 time=176 us) Iso arviointivirhe, tosin suoritussuunnitelma on vielä hyvä. Mutta ongelmia seuraa... 13

Kustannusperustaisen optimonnin ongelmia: Virheiden kasautuminen Ja jotta asiat eivät olisi liian helppoja, arviointivirheet voivat kasautua pahimmillaan jopa eksponentiaalisesti [3]. Tarpeeksi monta liitosta, muutamat epätarkat tilastot, hieman korrelaatiota ja suoritussuunnitelma, jonka ensimmäiset vaiheet ovat optimaalisia ei olekaan enää optimaalinen suoritussuunnitelman loppuvaiheessa. Jos optimoijan arvioimat välitulosten koot heittävät liikaa, liitosten selektiviteettien laskeminen tuottaa yhä enemmän satunnaisia tuloksia ja johtaa huonojen access pathien ja liitosmenetelmien käyttöön. 14

Kustannusperustaisen optimonnin ongelmia: Virheiden kasautuminen (jatkoa) Esimerkki (laajennetaan edellistä kyselyä yhdellä liitoksella): SELECT * FROM dd_objects obj JOIN dd_users usr ON (obj.owner# = usr.user_id) JOIN sys_col$ scol ON (obj.object_id = scol.obj#) WHERE usr.username = 'OUTLN'; ----------------------------------------------------------------- Id Operation Name Rows ----------------------------------------------------------------- 0 SELECT STATEMENT 1509 * 1 HASH JOIN 1509 2 TABLE ACCESS BY INDEX ROWID DD_OBJECTS 2853 3 NESTED LOOPS 1427 * 4 TABLE ACCESS FULL DD_USERS 1 * 5 INDEX RANGE SCAN IDX_DDOBJ_OWNER# 2853 6 TABLE ACCESS FULL SYS_COL$ 48294 ----------------------------------------------------------------- Rows Row Source Operation ------- --------------------------------------------------- 42 HASH JOIN (cr=389 pr=0 pw=0 time=5072 us) 7 TABLE ACCESS BY INDEX ROWID DD_OBJECTS (cr=7 pr=0 pw=0 time=719 us) 9 NESTED LOOPS (cr=5 pr=0 pw=0 time=2517 us) 1 TABLE ACCESS FULL DD_USERS (cr=3 pr=0 pw=0 time=245 us) 7 INDEX RANGE SCAN IDX_DDOBJ_OWNER# (cr=2 pr=0 pw=0 time=101 us) 48294 TABLE ACCESS FULL SYS_COL$ (cr=382 pr=0 pw=0 time=434775 us) 15

Kustannusperustaisen optimonnin ongelmia: Virheiden kasautuminen (jatkoa) Edellinen SQL-lause, pakotettuna vihjeillä käyttämään indeksejä ja nested loopsia. Optimoijan riviarviot pysyvät samana, mutta: ------------------------------------------------------------------- Id Operation Name Rows ------------------------------------------------------------------- 0 SELECT STATEMENT 1509 1 TABLE ACCESS BY INDEX ROWID SYS_COL$ 1 2 NESTED LOOPS 1509 3 NESTED LOOPS 1427 * 4 TABLE ACCESS FULL DD_USERS 1 5 TABLE ACCESS BY INDEX ROWID DD_OBJECTS 2853 * 6 INDEX RANGE SCAN IDX_DDOBJ_OWNER# 2853 * 7 INDEX RANGE SCAN IDX_SYSCOL_3 10 ------------------------------------------------------------------- Rows Row Source Operation ------- --------------------------------------------------- 42 TABLE ACCESS BY INDEX ROWID SYS_COL$ (cr=29 pr=0 pw=0 time=613 us) 50 NESTED LOOPS (cr=25 pr=0 pw=0 time=22296 us) 7 NESTED LOOPS (cr=12 pr=0 pw=0 time=793 us) 1 TABLE ACCESS FULL DD_USERS (cr=4 pr=0 pw=0 time=238 us) 7 TABLE ACCESS BY INDEX ROWID DD_OBJECTS (cr=8 pr=0 pw=0 time=469 us) 7 INDEX RANGE SCAN IDX_DDOBJ_OWNER# (cr=4 pr=0 pw=0 time=89 us) 42 INDEX RANGE SCAN IDX_SYSCOL_3 (cr=13 pr=0 pw=0 time=313 us) Consistent reads: 29 vs 389, CPU time: 613us vs 5072 us. 16

Yksi ratkaisu ongelmiin: Oppiva optimoija Ongelmia siis on olemassa. Edellä esitettyihin ongelmiin on esitetty ratkaisuja, yksi niistä on oppiva optimoija: Oppiva optimoija seuraa kyselyn suoritusta ja saamastaan palautteesta pystyy korjaamaan tekemiään virheitä. Oppivat optimoijat ovat prototyyppiasteella, eikä tämä esitys kerro mistään tuotteesta. Tarkoitus on tarkastella joidenkin alustavien oppivien optimoijien prototyyppien toimintaa. 17

Kyselyn seuraaminen Oppivan optimoijan tarvitseman palautteen kerääminen tapahtuu kyselyä seuraamalla. Ideassa sinänsä ei ole mitään uutta, ensimmäiset maininnat kyselyn seuraamisesta löytyvät vähintäänkin 80-luvulta [6], ellei aiemmin. Kyselyä seurataan lisäämällä suoritussuunnitelmaan erillinen seurantaoperaatio. Käytännössä seurantaoperaatio kannattanee kytkeä suoraan varsinaisiin operaatioihin. Yksinkertaisin seurattava yksikkö on kardinaliteetti: Kuinka monta riviä operaatioon menee sisään, kuinka monta riviä tulee ulos ja näistä voidaan laskea myös operaation todellinen selektiviteetti. Myös muita yksiköitä voidaan seurata: tauluselauksessa blokkien lukumäärää, operaation käyttämää CPU-aikaa tai muistitila jne. Yksinkertaisuuden vuoksi tässä esityksessä käytetään vain kardinaliteettia. 18

Kyselyn seuraaminen (jatkoa...) Kyselyn seuraamisen kuorma ei välttämättä ole suuri. Pelkkä kardinaliteetin seuraaminen toteutuu yksinkertaisella laskurin kasvattamisella, kuten myös useimpien muiden tarkkailtavien tietojen. Kyselyn seuraaminen voidaan jopa laajentaa suoraan tilastojen keräämiseksi [8]. Full-tablescanin aikana voitaisiin analysoida taulun blokkien lukumäärä, rivin keskimääräinen pituus ja jopa (tosin jo näkyvällä lisäkustannuksella) sarakkeiden eri arvojen lukumäärät ja pienimmät ja suurimmat arvot. Indeksien kohdalla indeksin korkeus saadaan joka kerta kun indeksiä käytetään. Tilastoja ei tietenkään tarvitse kerätä joka suorituskerralla. 19

Staattinen oppiminen Seurannassa käytetyt laskurit kertovat suoraan, kuinka hyviä optimoijan arviot olivat. Tätä tietoa voidaan melko helposti käyttää hyväksi staattisessa oppimisessa. Tauluselauksessa laskurit kertovat taulun rivimäärän Helppo laajentaa myös laskemaan mm. taulun blokit, rivin keskimääräisen pituuden jne... Predikaattien kanssa laskurit kertovat ko. predikaatin selektiviteetin Tauluselaus valintaehdolla antaa kaksi tärkeää tietoa: taulun todellisen kardinaliteetin ja accesspredikaattien selektiviteetin Ideaa voidaan käyttää valitsevuuden osalta myös indeksin kautta haettaessa. Tällöin voidaan lisäksi aina tarkistaa mm. indeksin korkeus. Taulun rivimäärää ei tietenkään saada. 20

Staattinen oppiminen (jatkoa...) Tarkastellaan seuraavaa (kuvitteellista) kyselyä: SELECT * FROM asiakas WHERE ika BETWEEN 18 AND 25; Esimerkki (kuvitteellinen), jos optimoija valitsee full-tablescanin: Vaihe kard (arvio) kard (tod.) sel (arvio) sel (tod.) FILTER (access) 200 000 40 000 0,0666 0,0114 TABLESCAN (full) 3 000 000 3 500 000 - - Tauluselauksen aikana suorituksessa selattiin 3 500 000 riviä läpi, joista 40 000 täytti valintaehdon ika BETWEEN 18 AND 25. Kuinka näitä havaintoja voidaan käyttää? 21

Staattinen oppiminen (jatkoa...) Havaitut arvot tallennetaan tietohakemistoon ja näitä arvoja käytetään seuraavalla kerralla, kun kysely optimoidaan. Havaitut arvot kannattanee tallentaa korjauskertoimina, ei absoluuttisina arvoina [5] Tietokantaobjektien korjauskertoimet on helppo tallentaa...... mutta selektiviteetit voidaan tallentaa myös operaatiokohtaisesti Edellisen kalvon esimerkissä FILTER-operaation selektiviteetti predikaatille ika BETWEEN 18 AND 25 voidaan tallentaa Myös liitoksille ja muille operaatioille voidaan tallentaa selektiviteettien korjauskertoimet Vaatii puumuotoisen datan (vähän kuin suoritussuunnitelma) kirjaamista tietohakemistoon 22

Staattinen oppiminen (jatkoa...) Pienten arviointivirheiden kohdalla ei tarvitse kirjata mitään Kursori voidaan invalidoida, jos havaitaan merkittävä arviointivirhe. Näin voidaan reagoida arviointivirheeseen seuraavalla suorituskerralla. Optimointivaiheessa tietohakemistosta luetaan varsinaiset tilastotiedot ja korjauskertoimet. Optimoija muodostaa kustannusarvion käyttäen tilastotietoja ja korjauskertoimia Huom: Oracle 10:n SQL-profiilit ovat hieman sukua staattiselle oppimiselle. 23

Dynaaminen oppiminen Staattinen oppiminen on hyödyllistä, jos SQL-lause suoritetaan useita kertoja, mutta ei auta ajossa olevaan kyselyyn. Raskas kysely saattaa lisäksi olla ainutkertainen, eikä näin ollen hyödytä tulevaisuudessakaan. Sen sijaan järkevämpää olisi, jos vakavan arviointivirheen havaitsemisen jälkeen kyselyn suoritussuunnitelmaa voitaisiin vaihtaa ajon aikana, eli käyttää dynaamista optimointia [1,4,7,9]. Dynaaminen optimointi ei ole ongelmatonta: Milloin arviointivirhe on vakava? Muuttuisiko suoritussuunnitelma havaituilla arvoilla? Olisiko uudelleenoptimoitu suoritussuunnitelma tehokkaampi? Paljonko uudelleenoptimointi vie aikaa? Entä rivien putkitus (pipelining) käyttäjälle?!?! 24

Dynaaminen optimointi: Valvontapisteet Suorituksen valvonta ja uudelleenoptimointipäätös tehdään valvontapisteessä [4]. Valvontapiste on periaatteessa erillinen operaattori suoritussuunnitelmassa Valvontapisteet sijoitetaan suoritussuunnitelmassa paikkaan, jossa uudellenoptimointi voidaan tehdä. Käytännössä tarvitaan erilaisia valvontapisteitä. 25

Dynaaminen optimointi: Passiivinen valvontapiste Yksinkertaisin valvontapiste on passiivinen valvontapiste (lazy checkpoint). Sijoitetaan välittömästi materialisaatiopisteen (MP) jälkeen. MP syntyy, kun SQL-lauseen suorituksessa tehdään ns. blokkaava operaatio, jonka täytyy valmistua ennen kuin yhtään riviä voidaan putkittaa kyselypuussa eteenpäin. Yleisin esimerkki materialisaatiopisteestä on SORT-operaatio. MP takaa riskittömän uudelleenoptimointipaikan, sillä MP:n välitulos on välttämätön kyselyn etenemisen kannalta, eikä käyttäjälle ole välitetty vielä yhtään riviä. Välituloksen valmistuttua voidaan tutkia, montako riviä välituloksessa on ja arvioida, olisiko uudelleenoptimointi kannattavaa. Optimoijalla on käytettävissä välituloksen tarkka rivimäärä 26

Dynaaminen optimointi: Passiivinen valvontapiste (jatkoa...) Jos päädytään uudelleenoptimoimaan koko välitulos voidaan heittää pois ja suorittaa uudelleen tai käyttää hyväksi kuten väliaikaista taulua. Luonnollisia MP:itä syntyy aika ajoin (mm. SORT-operaatioita aiheuttavat MERGE JOIN, ORDER BY, GROUP BY, DISTINCT...), mutta MP voidaan myös pakottaa. 27

Esimerkki: Dynaaminen optimointi: Passiivinen valvontapiste (jatkoa...) join (hash) Valvontapiste join (merge) table access (full) OSTOPAIKAT sort sort Arvioitu kardinaliteetti: 100000 Havaittu todellinen: 100 table access (full) ASIAKKAAT table access (full) KUITIT 28

Dynaaminen optimointi: Passiivinen valvontapiste (jatkoa...) Uudelleenoptimoitaessa harkittavia suoritussuunnitelmia: join (hash) join (nested loops) join (nested loops) table access (full) OSTOPAIKAT join (nested loops) index range scan index range scan index range scan table access (full) TEMPORARY index range scan table access (full) OSTOPAIKAT table access (by index rowid) ASIAKKAAT table access (by index rowid) KUITIT table access (by index rowid) KUITIT 29

Dynaaminen optimointi: Passiivinen valvontapiste (jatkoa...) Passiivisen valvontapisteen ongelma? Koko välitulos on materialisoitava ennen tarkistuksia. Välitulos voi olla erittäin iso......ja silloin kirjoitetaan levylle......ja reagointi arviointivirheisiin on hidasta Vaikka välitulos pysyisi muistissa, reagointi tapahtuu vasta kun koko välitulos on materialisoitu. 30

Dynaaminen optimointi: Aktiiviset valvontapisteet Arviointivirheisiin voidaan reagoida nopeammin. Asetetaan suoritussuunnitelmaan aktiiviinen valvontapiste (eager checkpoint), jolle annetaan läpikulkevien rivien ylä- ja/tai alaraja. Uudelleenoptimointi käynnistetään jos: VP:llä on yläraja ja rivejä on kulkenut lävitse yli raja-arvon Huom! Optimoijalla ei ole käytettävissä tarkkaa rivimäärää! Raja-arvo kannattaa yrittää valita siten, että raja-arvon kohdalla suoritussuunnitelma vaihtuisi. VP:llä on alaraja ja VP:lle rivejä syöttävä operaatio (row-source) päättyy Mitä jos suoritussuunnitelmassa on putkitusta? Miten estetään, ettei käyttäjä näe samaa riviä useammin kuin kerran? 31

Dynaaminen optimointi: Aktiivinen valvontapiste ilman kompensaatiota Yksinkertaisimmillaan innokas valvontapiste voidaan sijoittaa puussa materialisaatiopisteen alle. Ylärajan ylittyessä uudelleenoptimointi aiheuttaa materialisaatiopisteen alla olevan puunosan uudelleen suorittamisen. Valvontapisteen ei tarvitse sijaita välittömästi materialisaatiopisteen alla. Valvontapisteen alla olevien materialisaatiopisteiden välituloksia voidaan käyttää uudelleenoptimoinnissa... jos ne ovat vielä olemassa. Etuja: Haittoja: Helppo sijoittaa Ei ongelmia putkituksen kanssa Vaatii materialisaatiopisteen Mahdollisesti iso osa suoritussuunnitelmaa voidaan joutua heittämään hukkaan 32

Dynaaminen optimointi: Aktiivinen valvontapiste ilman kompensaatiota (jatkoa) join (merge) join (hash) sort sort join (hash) table access (full) OSTOPAIKAT Join (nested loops) table access (full) OSTOPAIKAT table access (full) ASIAKKAAT table access (full) KUITIT table access (full) ASIAKKAAT table access (full) KUITIT Tämän osan välitulos (kerätty materialisaatiopisteeseen) heitetään pois ja koko kysely suoritetaan uudestaan 33

Dynaaminen optimointi: Aktiivinen puskuroitu valvontapiste Toinen tapa sijoittaa innokas arviointipiste on käyttää puskurointia. Valvontapisteen yhteyteen sijoitetaan puskuri, jolle määritetään ylä- ja/tai alaraja. Valvontapisteen läpi kulkevat rivit puskuroidaan, eikä niitä välitetä vielä eteenpäin. Putkitettu suoritus pysähtyy hetkeksi. Jos puskuri täyttyy (overflow) tai puskuria syöttävä operaattori päättyy (underflow) ennen kuin puskuri on täysi, tarkistetaan, tarvitseeko uudelleenoptimoida. Overflow:n tapauksessa puskuria syöttävä operaattori pysäytetään. Uudelleenoptimoitaessa overflow-tapauksessa puskurin sisältämä välitulos heitetään pois ja suoritussuunnitelma puskurin alla suoritetaan uudestaan. Jos uudelleenoptimointia ei tehdä, rivit luetaan ensin puskurista ja sitten puskuria syöttävältä operaattorilta. 34

Dynaaminen optimointi: Aktiivinen puskuroitu valvontapiste (jatkoa) Etuja: Haittoja: Ei vaadi materialisaatiopistettä Ei putkitusongelmaa Nopea reagointi Iso osa suoritussuunnitelmaa voidaan joutua suorittamaan uudestaan Puskurin mielellään mahduttava muistiin (kokorajoitukset) Putkitetussa suorituksessa voi syntyä latenssi Latenssi syntyy, jos puskuri täyttyy hitaasti. Esimerkkeinä tauluselaus, hajautettu kysely, iso puskuri... Tapahtuu normaalissa suorituksessa ilman uudelleenoptimointia 35

Dynaaminen optimointi: Aktiivinen kompensoitu valvontapiste Jos putkitettu suoritus on välttämätöntä ja latensseja ei suvaita, voidaan käyttää kompensointia. Kompensoinnissa rivit voidaan putkittaa käyttäjälle, mutta mikäli kysely uudelleenoptimoidaan ja suoritetaan uudestaan, tulosjoukosta poistetaan käyttäjälle jo palautetut rivit. Käyttäjälle palautettaville riveille generoidaan yksilöllinen tunniste (huom: ROWID tai riville generoitu hash-arvo ei välttämättä riitä) Tunniste tallennetaan aputauluun (hash-rakenne ehkä paras) Uudelleenoptimoinnin tapahtuessa tulosjoukolle tehdään ANTI- JOIN aputauluun, jolloin tulosjoukosta poistetaan käyttäjälle jo palautetut rivit. 36

Etuja: Haittoja Dynaaminen optimointi: Aktiivinen kompensoitu valvontapiste (jatkoa...) Nopea reagointi Ei tarvitse puskurointia tai materialisaatiopistettä Välitön putkitus mahdollista Tarvitaan tilaa aputaululle Palautettujen rivien tunnisteiden generointi ja tallennus aiheuttaa kuormaa Koko kysely voidaan joutua suorittamaan uudestaan Täysin putkitetussa suorituksessa ei ole välituloksia, joita voidaan käyttää uudelleenoptimoinnin jälkeen hyväksi Anti-join aiheuttaa lisäkuormaa 37

Dynaaminen optimointi: Aktiivinen kompensoitu valvontapiste (jatkoa...) select statement INSERT TEMP (rivitunnisteen generointi ja tallennus) select statement anti-join TEMPORARY (rivitunnisteet) join (nested loops) join (hash) index range scan table access (by index rowid) ASIAKKAAT index range scan table access (by index rowid) KUITIT table access (full) ASIAKKAAT table access (full) KUITIT 38

Dynaaminen optimointi: Muita menetelmiä? Edellä esitetyt eivät tietenkään ole ainoita mahdollisia tapoja uudelleenoptimoida, ja uusia mekanismeja kehitetään (kuten [1]). Progressiivinen uudelleenoptimointi on kuitenkin perinteisen optimoijan laajennus ja sinänsä helppo toteuttaa. Täysin toisenlainen lähestyminen on River/Eddies-tyylinen jatkuva optimointi [9], mutta se vaatisi koko optimoijan & SQL-suorituskoneen uudelleenkirjoittamisen, mikä ei ole ainakaan lyhyellä tähtäimellä todennäköistä. 39

Tulevaisuus? Tuleeko oppiva optimoija Oracleen? Arvaus: Tulee, ehkä joskus. Jotakin viitettä tämän suuntaisesta löytyy jo nyt, jos näin halutaan tulkita. Esimerkiksi 9i:stä lähtien käytössä on näkymä V$SQL_PLAN_STATISTICS [10,11], jonka sisältö on aivan kuin edellä esitetyssä seurantaoperaatiossa. Myös Tom Kyteä lainaten: The optimizer, in looking at: [SQL-statement] has NO CLUE as to the correlation between the various columns. there are no statistics in 9i and before that would help it -- it is a very difficult problem actually.... I can say in a future release of the database -- things like this will be solvable without the use of hinting (Toiveajattelua?) 40

Tulevaisuus? (jatkoa...) Onko oppivalle optimoijalle tarvetta? Kyllä: Tietokannat kasvavat ja tulevat monimutkaisemmiksi. Kymmenien taulujen liitokset ovat olleet jo arkipäivää. Alussa mainitut ongelmat pysyvät edelleen. Muut menetelmät (mm. moniulotteiset histogrammit ja dynamic sampling) eivät ole myöskään täydellisiä, eivätkä kata kaikkea oppivan optimoijan toiminnallisuutta Helpottaa koodaajan & DBA:n työtä tämäkin... jos toimii hyvin ja luotettavasti. 41

Tulevaisuus? (jatkoa...) Onko oppiva optimoija ns. hopealuoti? There is no such thing as free lunch Automatiikasta seuraa lisäkuormaa Automatiikka ei ehkä aina toimi, jolloin suorituskyky voi huonontua tai kaikkia ongelmatapauksia ei havaita Ei korjaa huonoa taulusuunnittelua (osan kyllä, mutta ei kaikkia tapauksia) Ei ole älykäs: Ei ymmärrä huonoa SQL:ää Käyttäjä, joka pyytää karteesisen liitoksen, saa karteesisen liitoksen Monimutkainen toteuttaa... buginen? Optimaalinen staattisesti optimoitu suoritussuunnitelma on silti tehokkain 42

Yhteenveto Kustannusperustaisessa optimoinnissa on useita ongelmia, kuten korrelaatio, oletukset ja tilastojen epätarkkuus, joiden takia optimoija ei pysty aina valitsemaan optimaalista suoritussuunnitelmaa. Yksi tapa ratkaista nämä ongelmat on seurata kyselyn suoritusta ja oppia siten tehdyistä virheistä. Oppiminen voi tapahtua staattisesti, jolloin havainnot kirjataan tietohakemistoon. Suoritussuunnitelmaa voidaan myös muuttaa dynaamisesti ajon aikana, jolloin voidaan reagoida välittömästi tehtyihin arviointivirheisiin. 43

Kiitos Riku Räsänen Kantamestarit OY riku.rasanen@kantamestarit.fi 44

Lähteet 1. Babu S., Bizarro P. ja DeWitt D., Proactive re-optimization. Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data, 2005, sivut 107 118. 2. Christodoulakis S., "Implications of certain assumptions in database performance evaluation". ACM Transactions on Database Systems, Volume 9, Issue 2 (1984), sivut 163-186. 3. Ioannidis Y. E. ja Christodoulakis S., "On the propagation of errors in the size of join results". ACM SIGMOD Record, Proceedings of the 1991 ACM SIGMOD International Conference on Management of Data, osa 20, 1991, sivut 268 277. 4. Markl V., Raman V., Simmen D., Lohman G., Pirahesh H. ja Cilimdzic M., Robust query processing through progressive optimization. Proceedings of the 2004 ACM SIGMOD International Conference on Management of Data, 2004, sivut 659 670. 5. Stillger M., Lohman G., Markl V. ja Kandil M., "LEO - DB2's LEarning Optimizer." VLDB 2001, Proceedings of 27th International Conference on Very Large Data Bases, 2001, sivut 19 28. 45

Lähteet (jatkoa...) 6. Yu C., Lilien L., Guh K., Templeton M., Brill D. ja Chen A., "Adaptive techniques for distributed query optimization." Proceedings of the Second International Conference on Data Engineering, Los Angeles, CA, 1986, sivut 86 93. 7. Kabra N. ja DeWitt D. J., Efficient mid-query re-optimization of suboptimal query execution plans. Proceedings of the 1998 ACM SIGMOD International Conference on Management of Data, 1998, sivut 106 117. 8. Zhu Q., Dunkel B., Soparkar N., Chen S., Schiefer B. ja Lai T., A piggyback method to collect statistics for query optimization in database management systems. Proceedings of the 1998 Conference of the Centre for Advanced Studies on Collaborative Research, 1998, sivu 25. 9. Avnur R. ja Hellerstein J. M., "Eddies: continuously adaptive query processing." Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, 2000, sivut 261-272. 46

Lähteet (jatkoa...) 10. Oracle Database Reference 10g Release 1 (10.1) 11. Oracle Database Performance Tuning Guide 10g Release 1 (10.1) 12. Metalink note 68992.1: Predicate Selectivity 13. Metalink note 73489.1: Effect of Number of tables on Join Order Permutations 14. Metalink note 212809.1: Limitations of the Oracle Cost Based Optimizer 47