Með þessari stuttu færslu langar mig að eyða einum misskilningi sem tengist greiningu á AWR gagnagrunnum sem keyra á Oracle Exadata. Í næstum 10 ár hef ég stöðugt staðið frammi fyrir spurningunni: hvert er framlag Exadata Software til framleiðni? Eða með því að nota nýleg orð: hversu „sérfræðingur“ er starf tiltekins gagnagrunns?
Oft er þessari réttu spurningu, að mínu mati, rangt svarað með vísan til AWR tölfræði. Það sýnir kerfisbiðaðferðina, sem meðhöndlar viðbragðstíma sem summan af rekstrartíma örgjörva (DB CPUs) og biðtíma ýmissa flokka.
Með tilkomu Exadata birtust sérstakar kerfisvæntingar tengdar rekstri Exadata hugbúnaðar í tölfræði AWR. Að jafnaði byrja nöfn slíkra bið á orðinu „klefi“ (Exadata Storage þjónninn er kallaður klefi), þar af algengastar eru biðir með sjálfskýrandi nöfnunum „cell smart table scan“, „cell multiblock“ líkamlegur lestur“ og „líkamlegur lestur í einni blokk“.
Í flestum tilfellum er hlutur slíkra Exadata-bíða í heildarviðbragðstímanum lítill og því falla þær ekki einu sinni í Top10 Foreground Events by Total Wait Time (í þessu tilfelli þarftu að leita að þeim í Foreground Wait) Viðburðir hluti). Með miklum erfiðleikum fundum við dæmi um daglegt AWR frá viðskiptavinum okkar, þar sem væntingar Exadata voru með í Top10 hlutanum og námu samtals um 5%:
atburður
Bíður
Heildarbiðtími (sek.)
Meðal bið
%DB tími
Bíddu flokkur
DB CPU
115.2K
70.4
SQL*Net fleiri gögn frá dblink
670,196
5471.5
8.16ms
3.3
Net
frumu einn blokk líkamlegur lestur
5,661,452
3827.6
676.07us
2.3
Notanda I/O
Samstilltu ASM endurjafnvægi
4,350,012
3481.3
800.30us
2.1
Annað
frumu multiblokk líkamleg lesning
759,885
2252
2.96ms
1.4
Notanda I/O
bein leið lesin
374,368
1811.3
4.84ms
1.1
Notanda I/O
SQL*Net skilaboð frá dblink
7,983
1725
216.08ms
1.1
Net
frumu snjallborðskönnun
1,007,520
1260.7
1.25ms
0.8
Notanda I/O
bein leið lesa temp
520,211
808.4
1.55ms
0.5
Notanda I/O
enq: TM - ágreiningur
652
795.8
1220.55ms
0.5
Umsókn
Eftirfarandi ályktanir eru oft dregnar af slíkri AWR tölfræði:
1. Framlag Exadata töfra til frammistöðu gagnagrunnsins er ekki hátt - það fer ekki yfir 5% og gagnagrunnurinn „exadatizes“ illa.
2. Ef slíkur gagnagrunnur er fluttur frá Exadata yfir í klassískan „server + array“ arkitektúr, þá mun frammistaðan ekki breytast mikið. Vegna þess að jafnvel þótt þessi fylking reynist vera þrisvar sinnum hægari en Exadata geymslukerfið (sem er varla mögulegt fyrir nútíma All Flash fylki), þá bíður við að margfalda 5% með þremur aukningu á hlut I/O í 15% - gagnagrunnurinn mun svo sannarlega lifa þetta af!
Báðar þessar ályktanir eru ónákvæmar, þar að auki skekkja þær skilninginn á hugmyndinni á bak við Exadata Software. Exadata veitir ekki bara hraðvirkt I/O, það virkar í grundvallaratriðum öðruvísi miðað við klassískan netþjón + fylkisarkitektúr. Ef gagnagrunnsaðgerðin er sannarlega „aðlöguð“ þá er SQL rökfræðin flutt yfir í geymslukerfið. Geymsluþjónar, þökk sé fjölda sérstakra aðferða (aðallega Exadata Storage Indexes, en ekki aðeins), finna sjálfir nauðsynleg gögn og senda DB til netþjónanna. Þeir gera þetta á nokkuð skilvirkan hátt, þannig að hlutfall dæmigerðra Exadata bið í heildarviðbragðstíma er lítill.
Hvernig mun þessi hlutdeild breytast utan Exadata? Hvernig mun þetta hafa áhrif á frammistöðu gagnagrunnsins í heild? Próf mun best svara þessum spurningum. Til dæmis getur bið eftir „snjallborðskönnun“ utan Exadata breyst í svo þunga Table Full Scan að I/O tekur allan viðbragðstímann og afköst versna verulega. Þess vegna er rangt, þegar AWR er greint, að líta á heildarhlutfall Exadata væntinga sem framlag töfra þess til frammistöðu, og enn frekar að nota þetta hlutfall til að spá fyrir um frammistöðu utan Exadata. Til að skilja hversu „nákvæm“ vinna gagnagrunnsins er þarftu að kynna þér AWR tölfræðina í hlutanum „Tilviksvirkni“ (það er mikið af tölfræði með sjálfskýrandi nöfnum) og bera þær saman.
Og til að skilja hvernig gagnagrunni utan Exadata mun líða, er best að búa til gagnagrunnsklón úr öryggisafriti á markarkitektúrnum og greina árangur þessa klóns undir álagi. Eigendur Exadata hafa að jafnaði þetta tækifæri.
Höfundur: Alexey Struchenko, yfirmaður gagnagrunnsdeildar Jet Infosystems
Heimild: www.habr.com