Týmto krátkym príspevkom by som chcel rozptýliť jedno nedorozumenie súvisiace s analýzou databáz AWR bežiacich na Oracle Exadata. Už takmer 10 rokov sa neustále stretávam s otázkou: aký je prínos Exadata Software k produktivite? Alebo pomocou novovytvorených slov: aká „odborná“ je práca konkrétnej databázy?
Často je táto správna otázka, podľa môjho názoru, zodpovedaná nesprávne s odkazom na štatistiky AWR. Predstavuje metódu čakania systému, ktorá spracováva čas odozvy ako súčet prevádzkového času procesorov (DB CPU) a času čakania rôznych tried.
S príchodom Exadata sa v štatistikách AWR objavili špecifické systémové očakávania súvisiace s prevádzkou Exadata Software. Názvy takýchto čakaní spravidla začínajú slovom „bunka“ (server Exadata Storage sa nazýva bunka), z ktorých najbežnejšie sú čakania so samovysvetľujúcimi názvami „skenovanie inteligentnej tabuľky bunky“, „multiblok buniek“. fyzické čítanie“ a „fyzické čítanie jedného bloku bunky“.
Vo väčšine prípadov je podiel takýchto Exadata čakaní na celkovom čase odozvy malý, a preto nespadajú ani do sekcie Top10 Foreground Events by Total Wait Time (v tomto prípade ich treba hľadať v Foreground Wait sekcia Udalosti). S veľkými problémami sme našli príklad denného AWR od našich zákazníkov, v ktorom boli očakávania Exadata zahrnuté v sekcii Top10 a celkovo predstavovali asi 5%:
udalosť
Počká
Celkový čas čakania (s)
Priem. čakanie
%DB čas
Počkajte triedu
DB CPU
115.2K
70.4
SQL * Net viac údajov z dblink
670,196
5471.5
8.16ms
3.3
sieť
jednoblokové fyzické čítanie bunky
5,661,452
3827.6
676.07us
2.3
I/O používateľa
Synchronizácia opätovného vyváženia ASM
4,350,012
3481.3
800.30us
2.1
ostatné
bunkové viacblokové fyzické čítanie
759,885
2252
2.96ms
1.4
I/O používateľa
čítanie priamej cesty
374,368
1811.3
4.84ms
1.1
I/O používateľa
SQL*Net správa od dblink
7,983
1725
216.08ms
1.1
sieť
skenovanie inteligentnej tabuľky buniek
1,007,520
1260.7
1.25ms
0.8
I/O používateľa
priama cesta čítaná tepl
520,211
808.4
1.55ms
0.5
I/O používateľa
enq: TM - spor
652
795.8
1220.55ms
0.5
Využitie
Z takýchto štatistík AWR sa často vyvodzujú tieto závery:
1. Príspevok mágie Exadata k výkonu databázy nie je vysoký - nepresahuje 5% a databáza sa zle „exadatizuje“.
2. Ak sa takáto databáza prenesie z Exadata na klasickú architektúru „server + pole“, výkon sa veľmi nezmení. Pretože aj keď sa ukáže, že toto pole je trikrát pomalšie ako úložný systém Exadata (čo je pre moderné polia All Flash sotva možné), vynásobením 5 % tromi dostaneme zvýšenie podielu I/O čakania na 15 %. - databáza to určite prežije!
Oba tieto závery sú nepresné, navyše skresľujú chápanie myšlienky Exadata Software. Exadata neposkytuje len rýchle I/O, ale funguje zásadne odlišne v porovnaní s klasickou architektúrou server + pole. Ak je operácia databázy skutočne „prispôsobená“, potom sa logika SQL prenesie do úložného systému. Úložné servery si vďaka množstvu špeciálnych mechanizmov (predovšetkým Exadata Storage Indexes, ale nielen) samé nájdu potrebné dáta a odošlú DB na servery. Robia to pomerne efektívne, takže podiel typických čakaní Exadata na celkovom čase odozvy je malý.
Ako sa toto zdieľanie zmení mimo Exadata? Ako to ovplyvní výkon databázy ako celku? Na tieto otázky najlepšie odpovie testovanie. Napríklad čakanie na „skenovanie inteligentnej tabuľky buniek“ mimo Exadata sa môže zmeniť na také ťažké prezeranie tabuľky, že I/O zaberie celý čas odozvy a výkon sa dramaticky zníži. To je dôvod, prečo je nesprávne pri analýze AWR považovať celkové percento očakávaní Exadata za príspevok jeho mágie k výkonu, a ešte viac použiť toto percento na predpovedanie výkonu mimo Exadata. Aby ste pochopili, aká „presná“ je práca databázy, musíte si preštudovať štatistiku AWR v časti „Štatistika aktivity inštancie“ (existuje veľa štatistík so samovysvetľujúcimi názvami) a navzájom ich porovnať.
A aby ste pochopili, ako sa bude cítiť databáza mimo Exadata, je najlepšie vytvoriť klon databázy zo zálohy na cieľovej architektúre a analyzovať výkon tohto klonu pri zaťažení. Majitelia Exadata majú spravidla túto možnosť.
Autor: Alexey Struchenko, vedúci databázového oddelenia Jet Infosystems
Zdroj: hab.com