Selle lühikese postitusega tahaksin hajutada ühe arusaamatuse, mis on seotud Oracle Exadatas töötavate AWR-andmebaaside analüüsiga. Olen peaaegu 10 aastat seisnud pidevalt silmitsi küsimusega: milline on Exadata tarkvara panus tootlikkusesse? Või kasutades uusi sõnu: kui "ekspert" on konkreetse andmebaasi töö?
Sageli vastatakse sellele õigele küsimusele minu arvates AWR statistikale viidates valesti. See esitab süsteemi ootemeetodi, mis käsitleb reaktsiooniaega protsessorite (DB CPU-de) tööaja ja erinevate klasside ooteaja summana.
Exadata tulekuga ilmusid AWR-i statistikasse konkreetsed Exadata Tarkvara toimimisega seotud süsteemiootused. Reeglina algavad selliste ootamiste nimed sõnaga "cell" (Exadata Storage serverit nimetatakse lahtriks), millest levinumad on ootamised iseenesestmõistetavate nimedega "cell smart table scan", "cell multiblock" füüsiline lugemine” ja „lahtri ühe ploki füüsiline lugemine”.
Enamasti on selliste eksadataootuste osatähtsus kogu reageerimisajast väike ja seetõttu ei kuulu need isegi 10 parimat esiplaanisündmust kogu ooteaja järgi sektsiooni (sel juhul tuleb neid otsida esiplaanil ooteajast Sündmuste jaotis). Suure vaevaga leidsime oma klientidelt igapäevase AWR-i näite, milles Exadata ootused olid Top10 sektsioonis ja kokku moodustasid umbes 5%:
sündmus
Ootab
Kokku ooteaeg (s)
Keskmine ooteaeg
%DB aeg
Oota klass
DB protsessor
115.2K
70.4
SQL* Võrgutage dblinkilt rohkem andmeid
670,196
5471.5
8.16ms
3.3
võrk
lahtri üheploki füüsiline lugemine
5,661,452
3827.6
676.07us
2.3
Kasutaja I/O
Sünkrooni ASM-i tasakaalustus
4,350,012
3481.3
800.30us
2.1
Muu
raku mitmeploki füüsiline lugemine
759,885
2252
2.96ms
1.4
Kasutaja I/O
otsetee lugemine
374,368
1811.3
4.84ms
1.1
Kasutaja I/O
SQL*Neti sõnum dblinkilt
7,983
1725
216.08ms
1.1
võrk
raku nutika tabeli skannimine
1,007,520
1260.7
1.25ms
0.8
Kasutaja I/O
otsetee lugemise temp
520,211
808.4
1.55ms
0.5
Kasutaja I/O
enq: TM – vaidlus
652
795.8
1220.55ms
0.5
taotlus
Sellisest AWR-statistikast tehakse sageli järgmised järeldused:
1. Exadata maagia panus andmebaasi jõudlusesse ei ole suur - see ei ületa 5% ja andmebaas "eksadatiseerub" halvasti.
2. Kui selline andmebaas viia Exadatast klassikalisele “server + massiiv” arhitektuurile, siis jõudlus palju ei muutu. Sest isegi kui see massiiv osutub kolm korda aeglasemaks kui Exadata salvestussüsteem (mis on tänapäevaste kõigi Flash-massiivide puhul vaevalt võimalik), siis korrutades 5% kolmega saame I/O-oote osakaalu suurenemise 15%-ni. - andmebaas elab selle kindlasti üle!
Mõlemad järeldused on ebatäpsed, pealegi moonutavad arusaamist Exadata tarkvara ideest. Exadata ei paku ainult kiiret I/O-d, vaid töötab põhimõtteliselt erinevalt võrreldes klassikalise serveri + massiivi arhitektuuriga. Kui andmebaasi toiming on tõeliselt "kohandatud", kantakse SQL-i loogika üle salvestussüsteemi. Salvestusserverid leiavad tänu mitmetele erimehhanismidele (peamiselt Exadata Storage Indexes, kuid mitte ainult) ise vajalikud andmed ja saadavad andmebaasi serveritesse. Nad teevad seda üsna tõhusalt, nii et tüüpiliste Exadata ootamiste osakaal kogu reageerimisajast on väike.
Kuidas see jagamine väljaspool Exadatat muutub? Kuidas see mõjutab andmebaasi kui terviku toimivust? Nendele küsimustele annab kõige paremini vastuse testimine. Näiteks võib väljaspool Exadatat "lahtri nutika tabeli skannimise" ootamine muutuda nii raskeks tabeli täielikuks skannimiseks, et I/O võtab kogu reageerimisaja ja jõudlus halveneb järsult. Seetõttu on AWR-i analüüsimisel vale pidada Exadata ootuste koguprotsenti selle võlu panusesse jõudlusesse ja veelgi enam kasutada seda protsenti toimivuse ennustamiseks väljaspool Exadatat. Et mõista, kui “täpne” andmebaasi töö on, tuleb uurida rubriigi “Instant Activity Stats” AWR statistikat (selgete nimedega statistikat on palju) ja võrrelda neid omavahel.
Ja selleks, et mõista, kuidas Exadatast väljaspool asuv andmebaas end tunneb, on kõige parem teha andmebaasi kloon sihtarhitektuuri varukoopiast ja analüüsida selle klooni jõudlust koormuse all. Exadata omanikel on reeglina see võimalus.
Autor: Aleksei Struchenko, Jet Infosüsteemide andmebaasiosakonna juhataja
Allikas: www.habr.com