Jos kysely tekee isoon tauluun ”full table scanin”, niin voisi tutkia uuden indeksin luontimahdollisuutta. Joskus voi olla, että indeksiä ei kannata luoda esim. vain yhtä ad-hoc-kyselyä varten. Tutki tuolloin mahdollisuutta, jos indeksin voisi/kannattaisi luoda lennosta, tehdä kyselyn ja lopuksi poistaa tuo väliaikainen indeksi. Indeksi voi välillä viedä enemmän tilaa kuin itse taulu. Onko tauluilla indeksejä tarvittava/riittävä/sopiva määrä?
Tarkista ensiksi miltä suoritussuunnitelma (execution plan) näyttää ja että indeksejä hyödynnetään kyselyssä.
Indeksit ovat vähän ”kaksteränen miekka”, jos niitä on paljon tai liikaa, niin lisäykset ja päivitykset voi hidastua ja jos niitä on vähän tai ei lainkaan, niin kyselyt ovat turkasen hitaita.
Jos taulussa on vähän sarakkeita, niin tutki voisiko taulu olla pelkästään nopea iot-taulu (index only table).
Jos taulu on pieni, lookup-/kooditaulu (staattinen ja esim. kohtuu pieni kooditaulu), niin voisiko se olla ”kiipattuna” muistiin?
Jos taulu on todella iso ja siihen tulee esim. ”tikettimäistä” detailji-dataa pitkin päivää todella suuria määriä, niin kannattaisiko se partitioida? Tuolloin partitioitujen taulujen ja indeksien hallintaan (add, drop, truncate jne.) tulisi kiinnittää riittävää huomiota.
Haasteet indeksien suhteen voi olla suuremmat, jos yhden ja saman systeemin (hybridi) tulee palvella sekä OLTP- että DW- tai DSS-tarpeita.
Jos kyselyssä on monen taulun ”joini” ja se on hidas, niin voisi tarkistaa, että kaikkien liitosten (joinien) perusehdot (FK => PK) ovat koodattuna kyselyn where-ehtoon. Lisäksi voisi tarkistaa, että mukana on kaikki tarvittavat perusrajaukset (code = ’Y’). Ei kuitenkaan vakioina vaan bind-muuttujien avulla esitettynä.
Jos indeksejä on paljon joissakin tauluissa, niin voisi ehkä tutkia niiden käyttöä (käytetäänkö ao. taulun indeksejä?) ja poistaa turhat indeksit käytöstä.
Myös indeksien tiivistämiseen kannattaa kiinnittää huomiota.
Jos indeksi on konkatenoitu, niin varmista että indeksi-sarakkeet ovat indeksissä oikeassa/tehokkaassa järjestyksessä.
Jos kysely on edelleen hidas, niin tutki voidaanko se ajaa ”parallelina”, viemättä kuitenkaan kaikkia resursseja muilta kyselyiltä ja toiminnoilta.
Varmistu myös, että ”kysely” löytyy eka suorituksen jälkeen cachestä (esim. käytä bindeja), koska ”hard parse” on usein suoritettaville kyselyille hidasta. Tuolloin (”hard parse”) kysely jäsennetään aina uudestaan ja uudestaan kun sitä kutsutaan.
Jos indeksin (b-puu) lehtitasossa on 20%:ia tyhjää tilaa suhteessa lehtitason kokonaistilaan, niin indeksille voisi ajaa uudelleenluonnin (rebuild). Isoille tauluille uudelleenluonti voi tietysti kestää kauan.
Varmista myös, että instanssisi parametrissa db_file_multiblock_read_count on riittävän suuri lohkon kerrannainen.
Varmistu, että instanssisi pga_aggerate_target on riittävän suuri, että erilaiset toiminnot (esim. lajittelu) tehtäisiin pääosin muistissa. Levy-I/O on hidasta.
Jos kyselyt hidastui jonkun upgraden tai versiovaihdon jälkeen, niin yritä riittävän äkkiä selvittää hitauden syy. Mitä muutoksia systeemiin on tehty verrattuna siihen kun se viimeksi toimi OK? Tämä voi tietysti välillä olla aika kinkkistäkin.
Jos systeemi on sellainen, että kanta käytetään joidenkin batch-tarpeiden takia alhaalla esim. aamuyöstä ja systeemi on hidas muutaman tunnin ajan aamusta, niin tutki mahdollisuutta viedä keskeisten taulujen dataa valmiiksi select-lauseilla muistiin, ennen aamun järjestelmän käytön alkamista. Näin saatetaan tällaisen järjestelmän käyttö saada sujumaan hyvin jo heti aamusta alkaen.
Jos kysely on edelleen hidas, niin voitaisiinko se jakaa järkeviin osiin, jotta yksi tai useampi kyselyn osa voisi tehdä kannasta otoksen raporttia varten.
Jos kysely on edelleen hidas, niin tutki mahdollisuutta, voitaisiinko joku sen osa rakentaa PL/SQL:n avulla esim. temppi-tauluun, joka sitten linkattaisiin tarvittaviin muihin tauluihin. Ohjelma voi myös kokonaan tehdä poiminnan kontrolloidusti ja nopeasti halutuista tauluista esim. BO-raportointia varten.
Jos kysely on edelleen hidas, niin tutki mahdollisuutta voitaisiinko sitä varten rakentaa materialisoitu näkymä.
Jos kysely on edelleen hidas, niin tutki voitaisiinko siihen laittaa vihje. Vihjeiden koodaamista tulisi viimeiseen asti välttää.
Varmista, että ”tuotantoonsiirtomenettely” on sellainen, että se ei kovin helposti salli hitaiden SQL:n siirtoa testistä ja kehityksestä tuotantoon. Osallistu ”tuotantosiirtomenettelyn” kehittämiseen jos mahdollista. ”Tuotantoonsiirtomenettely” ei saisi käytännössä olla sellainen, että se sallii ”aisan yli potkimisen”. ”Aisan yli potkimisella” tarkoitan sitä, että menettely on kirjattu toimivaksi eri tavalla kuin sitä tosiasiassa käytetään eli menettely esim. sallii siirtymisen suoraan kehitykseen ilman kunnollista testaamista testin puolella jne. Tuolloin tuotantoon voi vahingossa ja/tai herkemmin siirtyä hidasta SQL:ää (testi => kehitys => integraatio => laatu => tuotanto).
Varmista, että tietokanobjekteistasi on ajettu riittävän tuoreet tilastot. Jos ei ole mahdollisuutta eikä aikaa ajaa tauluille täysiä tilastoja, koska aamu ja järjestelmän käyttö jo pukkaa päälle, niin löytyisikö joku sopiva estimaatioprosentti, jota voitaisiin käyttää tilastojen luonnin yhteydessä, jotta taulujen käsittely olisi kuitenkin riittävän nopeaa?
Jos systeemin käyttö on päiväsaikaan OLTP- ja yöaikaan batch-tyyppistä, niin kannattaisiko yötä varten asettaa hieman erilaiset instanssin parametrit käyttöön ja svitsata ne taas takaisin eräajojen loputtua. Edellä mainitut haasteet, tilastojen ajaminen ja instanssin viilaaminen erilaisia tarpeita varten, voivat tietysti olla suuremmat 24/7 systeemeille.
Varmistu ja laske lisäksi että levyltä löytyy tilaa ko. uusille indekseille.
Varmistu, että käytössäsi on riittävän hyvä ja kattava työväline erilaisten DBA-tyyppisten töiden hoitamiseksi. Aika paljon käytetään Toadia, mutta muitakin välineitä löytyy myös esim. avoimen ”maailman” puolelta - http://en.wikipedia.org/wiki/Comparison_of_database_tools. Jos manageerattavanasi on useita eri kantamoottorimerkkejä niin voisi ehkä varmistua, että väline on riittävän kattava.
Eri indeksityyppejä voi opiskella manuaalista ja mm. teoriaankin liittyen löytyy hyvää lukemista.
SQL-kielen syntaksia voit opetella kirjasta - SQL – opas (Hovi), Docendo (2004)
Lue ja tutki myös kirjaa tietokantojen suunnittelusta ja indeksoinnista - Tietokantojen suunnittelu ja indeksointi (Hovi, Huotari, Lahdenmäki), Docendo (2005)
Lisäksi tietovarastoista ja BI-puolelta löytyy kirja - Tietovarastot ja Business Intelligence (Hovi, Hervonen, Koistinen)
Aika ajoin kannattaa vilkasta ja tutkia löytyykö ed.m. kirjoista uudet versiot ja jos tarvis, niin hankkia ne.
Lisäksi kultakin kantamoottorin valmistajalta löytyy omat SQL- ja DBA-manuaalinsa.
Tutustu myös tarvittaessa IBM:n erilaisiin ”red-bookeihin” halutulta alueelta. Täältä voi löytyä myös tosi kiinnostavaa lukemista.
Lue myös SQL-kirjoitus ”Ke 18.3.2009 - SQL:n virittämisen perusteista –
suoritussuunnitelma, set autotrace
on ja tkprof. Kts. Liitteestä 2 Performance Checklist kommenttimme kuhunkin virityksen tsekkilistan kohtaan liittyen.”
Lue myös Jusun PL/SQL-vinkit.
Huom! Tutki ja tsekkaa myös PL/SQL-koodiesimerkit.