Týmto krátkym príspevkom by som rád objasnil jedno nedorozumenie spojené s analýzou AWR databáz bežiacich na Oracle Exadata. Už takmer 10 rokov sa pravidelne stretávam s otázkou: aký je prínos Exadata Software na výkonnosť? Alebo s použitím novotvarov: do akej miery sa „exadatuje“ práca tej či onej databázy?
Často na túto správnu otázku, podľa môjho názoru, prichádza nesprávna odpoveď, zvyčajne s odkazom na štatistiku AWR. Obsahuje metódu systémových čakacích časov, ktorá interpretuje čas odozvy ako súčet času práce procesorov (DB CPU) a času čakania rôznych tried.
S príchodom Exadata sa v štatistike AWR objavili špecifické systémové čakacie časy spojené s prácou Exadata Software. Zvyčajne názvy takýchto čakacích časov začínajú slovom "cell" (článkom sa nazýva Exadata Storage server), pričom najčastejšie sa vyskytujú čakacie časy s výstižnými názvami "cell smart table scan", "cell multiblock physical read" a "cell single block physical read".
V drvivej väčšine prípadov podiel týchto Exadata-čakaní na celkovom čase odozvy je malý, a preto sa ani nedostanú do sekcie Top10 Foreground Events by Total Wait Time (v tomto prípade ich treba hľadať v sekcii Foreground Wait Events). S veľkým úsilím sme u našich zákazníkov objavili príklad denných AWR, v ktorom Exadata-čakania zasiahli sekciu Top10 a v súhrne predstavovali približne 5%:
Udalosť
Čakania
Celkový čas čakania (sec)
Priemerné čakanie
% DB čas
Trieda čakania
DB CPU
115.2K
70.4
SQL*Net ďalšie údaje z dblink
670,196
5471.5
8.16ms
3.3
Sieť
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Používateľ I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Iné
cell multiblock physical read
759,885
2252
2.96ms
1.4
Používateľ I/O
priamy path read
374,368
1811.3
4.84ms
1.1
Používateľ I/O
SQL*Net správa z dblink
7,983
1725
216.08ms
1.1
Sieť
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Používateľ I/O
priamy path read temp
520,211
808.4
1.55ms
0.5
Používateľ I/O
enq: TM — contention
652
795.8
1220.55ms
0.5
Aplikácia
Z takejto AWR štatistiky sa často robia nasledujúce závery:
1. Prínos mágie Exadata na výkonnosť databázy nie je vysoký — nepresahuje 5 %, a databáza sa "exadatuje" zle.
2. Ak by sa takáto databáza presunula z Exadata na klasickú architektúru "server + diskový systém", výkonnosť by sa nezmenila výrazne. Pretože aj keby sa ukázalo, že tento diskový systém je trikrát pomalší ako systém ukladania Exadata (čo je sotva možné pre moderné all-flash disky), vynásobením 5% tromi dostaneme zvýšenie podielu čakaní na vstup a výstup až na 15% — takúto databázu určite zvládne!
Obidva tieto výstupy sú nepresné, navyše skresľujú chápanie myšlienky, ktorá je zakotvená v Exadata Software. Exadata nielen zabezpečuje rýchly vstup-výstup, ale funguje zásadne inak v porovnaní s klasickou architektúrou „server + pole“. Ak je práca databázy naozaj „exadatujúca“, potom sa na systém ukladania prenáša SQL-logika. Storage servery vďaka rade špeciálnych mechanizmov (predovšetkým Exadata Storage Indexes, ale nielen) samy nachádzajú potrebné údaje a prenášajú ich DB serverom. Robia to dostatočne efektívne, preto podiel charakteristických Exadata čakacích období v celkovom čase odozvy je malý.
Ako sa tento podiel zmení mimo Exadata? Ako to ovplyvní výkon databázy ako celku? Najlepšie odpovede na tieto otázky dá testovanie. Napríklad čakanie „cell smart table scan“ mimo Exadata sa môže zmeniť na taký ťažký Table Full Scan, že vstup-výstup zaberie celý čas odozvy a výkon sa dramaticky zhorší. Preto je nesprávne pri analýze AWR počítať celkový percentuálny podiel čakacích období Exadata ako príspevok jej mágie do výkonu a už vôbec tento percentuálny podiel používať na predpovedanie výkonu mimo Exadata. Aby ste pochopili, ako veľmi je práca databázy „exadatujúca“, potrebujete skúmať štatistiky AWR sekcie „Instance Activity Stats“ (tam je veľa štatistík s výstižnými názvami) a porovnávať ich medzi sebou.
Aby ste pochopili, ako sa bude databáza cítiť mimo Exadata, je najlepšie vytvoriť z backupu kópiu databázy na cieľovej architektúre a analyzovať výkon tejto kópie pod zaťažením. Takáto možnosť je zvyčajne dostupná pre vlastníkov Exadata.
Autor: Alexey Struchenko, vedúci oddelenia DB „Infosystemy Jet“
Zdroj: habr.com
