Šiuo trumpu įrašu norėčiau išsklaidyti vieną nesusipratimą, susijusį su AWR duomenų bazių, veikiančių Oracle Exadata, analize. Jau beveik 10 metų nuolat susiduriu su klausimu: koks Exadata Software indėlis į produktyvumą? Arba naudojant naujai sukurtus žodžius: kiek „ekspertas“ yra konkrečios duomenų bazės darbas?
Dažnai į šį teisingą klausimą, mano nuomone, atsakoma neteisingai, remiantis AWR statistika. Jame pateikiamas sistemos laukimo metodas, kuris atsako laiką traktuoja kaip procesorių (DB CPU) veikimo laiko ir įvairių klasių laukimo laiko sumą.
Atsiradus Exadata, AWR statistikoje atsirado specifiniai sistemos lūkesčiai, susiję su Exadata Software veikimu. Paprastai tokių laukimų pavadinimai prasideda žodžiu „ląstelė“ (Exadata Storage serveris vadinamas langeliu), iš kurių dažniausiai yra laukimas su savaime suprantamais pavadinimais „cell smart table scan“, „cell multiblock“. fizinis skaitymas“ ir „ląstelių vieno bloko fizinis skaitymas“.
Daugeliu atvejų tokių Exadata laukimų dalis bendrame atsakymo trukme yra nedidelė, todėl jie net nepatenka į 10 populiariausių priekinio plano įvykių pagal bendrą laukimo laiką skyrių (tokiu atveju jų reikia ieškoti priekinio plano laukimo skyriuje skyrių „Įvykiai“). Su dideliais sunkumais radome savo klientų kasdieninio AWR pavyzdį, kuriame Exadata lūkesčiai buvo įtraukti į Top10 skyrių ir iš viso sudarė apie 5 %:
renginys
Laukia
Bendras laukimo laikas (sek.)
Vid. palauk
%DB laikas
Palauk klasė
DB CPU
115.2K
70.4
SQL*Surinkite daugiau duomenų iš dblink
670,196
5471.5
8.16ms
3.3
tinklas
ląstelės vieno bloko fizinis skaitymas
5,661,452
3827.6
676.07us
2.3
Vartotojo I/O
Sinchronizuoti ASM perbalansavimą
4,350,012
3481.3
800.30us
2.1
kitas
ląstelių kelių blokų fizinis skaitymas
759,885
2252
2.96ms
1.4
Vartotojo I/O
tiesioginio kelio skaitymas
374,368
1811.3
4.84ms
1.1
Vartotojo I/O
SQL*Net pranešimas iš dblink
7,983
1725
216.08ms
1.1
tinklas
ląstelių išmaniojo stalo nuskaitymas
1,007,520
1260.7
1.25ms
0.8
Vartotojo I/O
tiesioginis kelias skaitymo temp
520,211
808.4
1.55ms
0.5
Vartotojo I/O
enq: TM – ginčas
652
795.8
1220.55ms
0.5
taikymas
Iš tokios AWR statistikos dažnai daromos šios išvados:
1. Exadata magijos indėlis į duomenų bazės našumą nėra didelis - neviršija 5%, o duomenų bazė blogai "eksadatizuoja".
2. Jei tokia duomenų bazė iš Exadata bus perkelta į klasikinę "serveris + masyvas" architektūrą, našumas labai nepasikeis. Nes net jei šis masyvas pasirodys tris kartus lėtesnis nei Exadata saugojimo sistema (kas šiuolaikiniams „All Flash“ masyvams vargu ar įmanoma), tada 5% padauginus iš trijų gauname I/O laukimo dalies padidėjimą iki 15%. - duomenų bazė tai tikrai išgyvens!
Abi šios išvados yra netikslios, be to, jos iškreipia Exadata Software idėjos supratimą. „Exadata“ ne tik užtikrina greitą I/O, bet ir veikia iš esmės kitaip nei klasikinė serverio + masyvo architektūra. Jei duomenų bazės veikimas yra tikrai „pritaikytas“, SQL logika perkeliama į saugojimo sistemą. Saugyklos serveriai daugybės specialių mechanizmų (pirmiausia Exadata Storage Indexes, bet ne tik) dėka patys susiranda reikiamus duomenis ir siunčia DB į serverius. Jie tai daro gana efektyviai, todėl tipiškų Exadata laukimų dalis bendrame atsakymo trukme yra nedidelė.
Kaip pasikeis šis bendrinimas už Exadata ribų? Kaip tai paveiks visos duomenų bazės veikimą? Testavimas geriausiai atsakys į šiuos klausimus. Pavyzdžiui, laukimas „ląstelių išmaniosios lentelės nuskaitymas“ už „Exadata“ ribų gali virsti tokiu sunkiu visos lentelės nuskaitymu, kad įvestis / išvestis užima visą atsako laiką, o našumas smarkiai pablogėja. Štai kodėl neteisinga analizuojant AWR bendrą Exadata lūkesčių procentą laikyti jos magišku indėliu į našumą, o juo labiau naudoti šį procentą našumui prognozuoti už Exadata ribų. Norint suprasti, koks „tikslus“ yra duomenų bazės darbas, reikia išstudijuoti „Egzempliorių veiklos statistikos“ skyriaus AWR statistiką (statistikos su savaime suprantamais pavadinimais yra daug) ir palyginti ją tarpusavyje.
Ir norint suprasti, kaip jausis duomenų bazė, nepriklausanti „Exadata“, geriausia sukurti duomenų bazės kloną iš atsarginės kopijos tikslinėje architektūroje ir išanalizuoti šio klono našumą esant apkrovai. „Exadata“ savininkai, kaip taisyklė, turi tokią galimybę.
Autorius: Aleksejus Struchenko, Jet Infosystems duomenų bazės skyriaus vadovas
Šaltinis: www.habr.com