Tällä lyhyellä postauksella haluan hälventää yhden väärinkäsityksen, joka liittyy Oracle Exadatassa toimivien AWR-tietokantojen analysointiin. Lähes 10 vuoden ajan olen jatkuvasti kohdannut kysymyksen: mikä on Exadata Softwaren panos tuottavuuteen? Tai käyttämällä uusia sanoja: kuinka "asiantuntija" on tietyn tietokannan työ?
Usein tähän oikeaan kysymykseen vastataan mielestäni väärin viitaten AWR-tilastoihin. Se esittää järjestelmän odotusmenetelmän, joka käsittelee vasteaikaa prosessorien (DB CPU:iden) toiminta-ajan ja eri luokkien odotusaikojen summana.
Exadatan myötä AWR-tilastoihin ilmestyi erityisiä Exadata Softwaren toimintaan liittyviä järjestelmäodotuksia. Pääsääntöisesti tällaisten odotusten nimet alkavat sanalla "solu" (Exadata Storage -palvelinta kutsutaan soluksi), joista yleisimpiä ovat odotukset itsestään selvillä nimillä "cell smart table scan", "cell multiblock" fyysinen luku" ja "solun yhden lohkon fyysinen luku".
Useimmissa tapauksissa tällaisten Exadata-odotusten osuus kokonaisvastausajasta on pieni, eivätkä ne siksi edes kuulu Top10 Foreground Events by Total Wait Time -osioon (tässä tapauksessa sinun on etsittävä niitä Foreground Waitista Tapahtumat-osio). Löysimme suurella vaivalla esimerkin asiakkailtamme päivittäisestä AWR:stä, jossa Exadatan odotukset sisältyivät Top10-osioon ja olivat yhteensä noin 5 %:
tapahtuma
Odottaa
Kokonais odotusaika (s)
Keskim. odotus
%DB aika
Odota Luokka
DB CPU
115.2K
70.4
SQL*Net enemmän dataa dblinkistä
670,196
5471.5
8.16ms
3.3
verkko
solun yhden lohkon fyysinen luku
5,661,452
3827.6
676.07us
2.3
Käyttäjä I/O
Synkronoi ASM-tasapainotus
4,350,012
3481.3
800.30us
2.1
Muut
solun monilohkoinen fyysinen luku
759,885
2252
2.96ms
1.4
Käyttäjä I/O
suora polku lukea
374,368
1811.3
4.84ms
1.1
Käyttäjä I/O
SQL*Net-sanoma dblinkistä
7,983
1725
216.08ms
1.1
verkko
solun älykkään taulukon skannaus
1,007,520
1260.7
1.25ms
0.8
Käyttäjä I/O
suora polku lukulämpötila
520,211
808.4
1.55ms
0.5
Käyttäjä I/O
enq: TM - kiista
652
795.8
1220.55ms
0.5
Hakemus
Tällaisista AWR-tilastoista tehdään usein seuraavat johtopäätökset:
1. Exadata-magian panos tietokannan suorituskykyyn ei ole suuri - se ei ylitä 5%, ja tietokanta "exadatisoituu" huonosti.
2. Jos tällainen tietokanta siirretään Exadatasta klassiseen "palvelin + array" -arkkitehtuuriin, suorituskyky ei muutu paljon. Koska vaikka tämä matriisi osoittautuisikin kolme kertaa hitaammaksi kuin Exadata-tallennusjärjestelmä (mikä on tuskin mahdollista nykyaikaisissa All Flash -matriisissa), kerrotaan 5 % kolmella, saadaan I/O-odotusten osuus kasvamaan 15 prosenttiin. - Tietokanta selviää varmasti tästä!
Molemmat johtopäätökset ovat epätarkkoja, ja lisäksi ne vääristävät ymmärrystä Exadata Softwaren ideasta. Exadata ei vain tarjoa nopeaa I/O:ta, vaan se toimii täysin eri tavalla kuin klassinen palvelin + taulukkoarkkitehtuuri. Jos tietokannan toiminta on todella "muokattu", SQL-logiikka siirretään tallennusjärjestelmään. Tallennuspalvelimet löytävät useiden erikoismekanismien (ensisijaisesti Exadata Storage Indexes, mutta ei vain) ansiosta tarvittavat tiedot itse ja lähettävät tietokannan palvelimille. He tekevät tämän varsin tehokkaasti, joten tyypillisten Exadatan odotusten osuus kokonaisvastausajasta on pieni.
Miten tämä jako muuttuu Exadatan ulkopuolella? Miten tämä vaikuttaa koko tietokannan suorituskykyyn? Testaus vastaa parhaiten näihin kysymyksiin. Esimerkiksi "solun älykkään taulukon skannauksen" odottaminen Exadatan ulkopuolella voi muuttua niin raskaaksi Table Full Scaniksi, että I/O vie koko vasteajan ja suorituskyky heikkenee dramaattisesti. Tästä syystä on väärin AWR:ää analysoitaessa pitää Exadatan odotusten kokonaisprosenttiosuutta sen taikuuden vaikutuksena suorituskykyyn, ja vielä enemmän käyttää tätä prosenttiosuutta suorituskyvyn ennustamiseen Exadatan ulkopuolella. Ymmärtääksesi kuinka "tarkka" tietokannan työ on, sinun on tutkittava "Instanssiaktiviteettitilastot" -osion AWR-tilastot (tilastoja on paljon itsestään selvillä nimillä) ja vertailla niitä keskenään.
Ja ymmärtääksesi, miltä Exadatan ulkopuolinen tietokanta tuntuu, on parasta tehdä tietokantaklooni kohdearkkitehtuurin varmuuskopiosta ja analysoida tämän kloonin suorituskykyä kuormitettuna. Exadatan omistajilla on yleensä tämä mahdollisuus.
Kirjoittaja: Alexey Struchenko, Jet Infosystemsin tietokantaosaston johtaja
Lähde: will.com