Ezzel a rövid bejegyzéssel szeretném eloszlatni egy félreértést az AWR elemzésével kapcsolatban, amely Oracle Exadata környezetben működő adatbázisokat érint. Közel 10 éve folyamatosan találkozom azzal a kérdéssel: mekkora szerepet játszik az Exadata szoftver a teljesítményben? Vagy más szavakkal: mennyire 'exadáztól' függ az adott adatbázis működése?
Gyakran erre a helyes kérdésre, véleményem szerint, hibás válasz érkezik, amely az AWR statisztikákra hivatkozik. Ezekben a rendszer várakozási idejeit úgy értelmezik, mint a CPU idő és a különböző osztályok várakozási idejének összegét.
Az Exadata megjelenésével az AWR statisztikákban specifikus rendszer várakozások jelentek meg, amelyek az Exadata szoftver működésével kapcsolatosak. Ezek a várakozások általában 'cell' szóval kezdődnek (a cella az Exadata tárolószerver), és a leggyakoribbak között találhatók a következő nevek: 'cell smart table scan', 'cell multiblock physical read' és 'cell single block physical read'.
A legtöbb esetben az ilyen Exadata várakozások aránya a válaszidőben kicsi, ezért nem is kerülnek be a Top10 Foreground Events by Total Wait Time szekcióba (ilyenkor a Foreground Wait Events részben kell őket keresni). Nagy nehezen találtunk ügyfeleinknél egy napra vonatkozó AWR példát, ahol az Exadata várakozások bejutottak a Top10 szekcióba és összesen körülbelül 5%-ot tettek ki:
Esemény
Várakozások
Összes várakozási idő (sec)
Átlagos várakozás
% DB idő
Várakozási osztály
DB CPU
115.2K
70.4
SQL*Net több adat a dblinkből
670,196
5471.5
8.16ms
3.3
Hálózat
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Felhasználói I/O
Szinkron ASM újraelosztás
4,350,012
3481.3
800.30us
2.1
Egyéb
cell multiblock physical read
759,885
2252
2.96ms
1.4
Felhasználói I/O
közvetlen útvonal olvasás
374,368
1811.3
4.84ms
1.1
Felhasználói I/O
SQL*Net üzenet a dblinkből
7,983
1725
216.08ms
1.1
Hálózat
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Felhasználói I/O
közvetlen útvonal olvasás ideiglenes
520,211
808.4
1.55ms
0.5
Felhasználói I/O
elérhető: TM — elosztási ellentmondás
652
795.8
1220.55ms
0.5
Alkalmazás
Az ilyen AWR statisztikákból gyakran olyan következtetéseket vonnak le:
1. Az Exadata varázslat hozzájárulása az adatbázis teljesítményéhez nem magas — nem haladja meg az 5%-ot, így az adatbázis 'rosszul exadázható'.
2. Ha ezt az adatbázist Exadata-ról a klasszikus 'szerver + tároló' architektúrára helyeznénk át, a teljesítmény nem változna jelentősen. Mert ha a tároló háromszor lassabb lenne az Exadata tárolókhoz képest (ami a modern All Flash tárolók esetén alig lehetséges), akkor 5%-ot szorozva hárommal, a várakozási arányok 15%-ra emelkednének — ezt az adatbázis biztosan túlélne!
Mindkét kimenet pontatlan, sőt, torzítja az Exadata szoftverben rejlő ötlet megértését. Az Exadata nem csupán gyors bemeneti-kimenetet biztosít, alapjaiban másként működik, mint a klasszikus "szerver + tároló" architektúra. Ha az adatbázis megfelelően "exadatisálódik" – akkor a SQL-logika a tárolórendszerre kerül át. Storage szerverek Különféle speciális mechanizmusoknak köszönhetően (elsősorban Exadata Storage Indexek, de nem csak) maguk találják meg a szükséges adatokat, és küldik el azokat az DB szervereknek. Ezt elég hatékonyan végzik, ezért az Exadata-jellegű várakozások aránya az összes válaszidőben kicsi.
Hogyan változik ez az arány Exadata nélkül? Milyen hatással lesz ez az adatbázis teljesítményére? A legjobb válaszokat a tesztelés adja. Például az "cell smart table scan" várakozás Exadata nélkül olyan nehéz Table Full Scan-né alakulhat, hogy a bemeneti-kimenet minden válaszidőt felölel, és a teljesítmény drámaian csökken. Ezért helytelen az AWR elemzésekor a kivárások összesített százalékát az Exadata varázsának hozzájárulásaként számítani, és még inkább ezt a százalékot Exadata-n kívüli teljesítmény előrejelzésére használni. Ahhoz, hogy megértsük, mennyire "exadatisálódik" az adatbázis működése, az AWR szekció "Instance Activity Stats" statisztikáit (ott sok statisztika található beszédes nevekkel) kell tanulmányozni és összehasonlítani egymással.
Ahhoz, hogy megértsük, hogyan fog teljesíteni az adatbázis Exadata nélkül, a legjobb, ha egy másolatot készítünk a célarchitektúrára a mentésből, és elemezzük ennek a másolatnak a teljesítményét terhelés alatt. Az Exadata tulajdonosainak általában van lehetőségük erre.
Szerző: Alekszej Strucsenko, az Infósystem Jet DB részlegének vezetője
Forrás: habr.com
