Tímto krátkým příspěvkem bych chtěl objasnit jedno nedorozumění související s analýzou databází AWR běžících na Oracle Exadata. Již téměř 10 let se často setkávám s otázkou: jaký je příspěvek Exadata Software k výkonu? Nebo, s použitím novotvarů: jak moc je výkon nějaké databáze "exadatizován"?
Na tuto správnou otázku, dle mého názoru, často odpovídají nesprávně s odkazem na statistiky AWR. Obsahují metodu systémového čekání, která vykládá čas odezvy jako součet doby práce procesorů (DB CPU) a doby čekání různých tříd.
S příchodem Exadata se ve statistikách AWR objevila specifická systémová čekání spojená s Exadata Software. Obvykle názvy takových čekání začínají slovem "cell" (což označuje server Exadata Storage), nejčastěji se vyskytující čekání mají výstižné názvy jako "cell smart table scan", "cell multiblock physical read" a "cell single block physical read".
Ve většině případů je podíl těchto Exadata čekání na celkové době odezvy malý, a proto se ani nedostanou do sekce Top10 Foreground Events by Total Wait Time (v tomto případě je potřebné je hledat v sekci Foreground Wait Events). S velkým úsilím jsme u našich zákazníků našli příklad denní AWR, ve kterém se Exadata čekání dostala do sekce Top10 a celkově tvořila přibližně 5 %:
Událost
Čekání
Celkový čas čekání (sekundy)
Průměrné čekání
% DB času
Třída čekání
DB CPU
115,2K
70.4
SQL*Net more data from dblink
670,196
5471.5
8,16 ms
3.3
Síť
cell single block physical read
5,661,452
3827.6
676,07 µs
2.3
User I/O
Sync ASM rebalance
4,350,012
3481.3
800,30 µs
2.1
Jiné
cell multiblock physical read
759,885
2252
2,96 ms
1.4
User I/O
direct path read
374,368
1811.3
4,84 ms
1.1
User I/O
SQL*Net message from dblink
7,983
1725
216,08 ms
1.1
Síť
cell smart table scan
1,007,520
1260.7
1,25 ms
0.8
User I/O
direct path read temp
520,211
808.4
1,55 ms
0.5
User I/O
enq: TM — contention
652
795.8
1220,55 ms
0.5
Aplikace
Z takové AWR statistiky se často vyvozují následující závěry:
1. Příspěvek magie Exadata k výkonu databáze není vysoký — nepřesahuje 5 %, a databáze "exadatizuje" špatně.
2. Pokud by se taková databáze převedla z Exadata na klasickou architekturu "server + pole", výkon se zásadně nezmění. Protože i kdyby toto pole bylo třikrát pomalejší než systém ukládání Exadata (což je stěží možné pro moderní All Flash pole), pak vynásobením 5% třemi dostaneme zvýšení podílu čekání na vstup/výstup na 15% — takovou databázi určitě přečká!
Oba tato vyjádření jsou nepřesná, navíc zkreslují porozumění myšlence, kterou Exadata Software přináší. Exadata nezajišťuje pouze rychlou I/O operaci, ale funguje zásadně jinak ve srovnání s klasickou architekturou „server + pole“. Pokud databáze skutečně „exadatizuje“, pak se SQL-logika přesune na úložný systém. Storage servery díky řadě speciálních mechanismů (především Exadata Storage Indexes, ale nejen těmto) samy nacházejí potřebná data a přenášejí je na DB servery. Dělají to dost efektivně, proto podíl charakteristických Exadata čekání v celkovém času odezvy je malý.
Jak se tento podíl změní mimo Exadata? Jak to ovlivní výkon databáze jako celku? Nejlépe na tyto otázky odpoví testování. Například čekání „cell smart table scan“ mimo Exadata se může proměnit v tak těžké Full Table Scan, že I/O zabere celý čas odezvy a výkon se dramaticky zhorší. Právě proto je nesprávné při analýze AWR počítat celkový procentuální podíl čekání Exadata jako příspěvek její magie k výkonu a tím méně používat toto procento pro predikci výkonu mimo Exadata. Abyste pochopili, jak moc je práce databáze „exadatizována“, musíte prostudovat statistiky AWR sekce „Instance Activity Stats“ (tam je spousta statistik s výstižnými názvy) a srovnávat je mezi sebou.
Abychom pochopili, jak se databáze bude cítit mimo Exadata, je nejlepší udělat z backupu klon databáze na cílové architektuře a analyzovat výkon tohoto klonu pod zátěží. Taková možnost obvykle mají vlastníci Exadata.
Autor: Alexey Struchenko, vedoucí oddělení DB „Infosystemy Jet“
Zdroj: habr.com
