Ezzel a rövid bejegyzéssel egy, az Oracle Exadatán futó AWR adatbázisok elemzésével kapcsolatos félreértést szeretnék eloszlatni. Közel 10 éve folyamatosan szembesülök azzal a kérdéssel: mi az Exadata Software hozzájárulása a termelékenységhez? Vagy újonnan alkotott szavakkal: mennyire „szakértő” egy adott adatbázis munkája?
Erre a helyes kérdésre véleményem szerint gyakran helytelenül válaszolnak az AWR statisztikákra hivatkozva. Bemutatja a rendszer várakozási metódusát, amely a válaszidőt a processzorok (DB CPU-k) működési idejének és a különböző osztályok várakozási idejének összegeként kezeli.
Az Exadata megjelenésével az Exadata Software működésével kapcsolatos sajátos rendszerelvárások jelentek meg az AWR statisztikákban. Az ilyen várakozások neve általában „cella” szóval kezdődik (az Exadata Storage szervert cellának hívják), amelyek közül a leggyakoribb a „cell smart table scan”, „cell multiblock” magától értetődő elnevezésű várakozás. fizikai olvasás” és „cella egyetlen blokk fizikai olvasása”.
A legtöbb esetben az ilyen Exadata-várakozások aránya kicsi a teljes válaszidőben, ezért nem is esnek a 10 legjobb előtérbeli esemény a teljes várakozási idő szerint szekcióba (ebben az esetben az Előtérben várakozóban kell keresni őket Események szakasz). Nagy nehezen találtunk példát ügyfeleink napi AWR-re, amelyben az Exadata elvárások a Top10 szekcióban szerepeltek, és összesen körülbelül 5%-ot tettek ki:
esemény
Vár
Teljes várakozási idő (mp)
Átl. várakozás
%DB idő
Várj osztály
DB CPU
115.2K
70.4
SQL*További adat netezése a dblinkből
670,196
5471.5
8.16ms
3.3
Hálózat
cella egyblokkos fizikai olvasása
5,661,452
3827.6
676.07us
2.3
Felhasználói I/O
Szinkronizálja az ASM újraegyensúlyozását
4,350,012
3481.3
800.30us
2.1
Más
cella többblokkos fizikai olvasása
759,885
2252
2.96ms
1.4
Felhasználói I/O
közvetlen elérési út olvasása
374,368
1811.3
4.84ms
1.1
Felhasználói I/O
SQL*Net üzenet a dblinktől
7,983
1725
216.08ms
1.1
Hálózat
cella intelligens asztali szkennelés
1,007,520
1260.7
1.25ms
0.8
Felhasználói I/O
közvetlen útvonal olvasási hőm
520,211
808.4
1.55ms
0.5
Felhasználói I/O
enq: TM - versengés
652
795.8
1220.55ms
0.5
Alkalmazás
Az ilyen AWR statisztikákból gyakran a következő következtetéseket vonják le:
1. Az Exadata magic hozzájárulása az adatbázis teljesítményéhez nem magas - nem haladja meg az 5%-ot, és az adatbázis rosszul „exadatizál”.
2. Ha egy ilyen adatbázist áthelyezünk az Exadatából a klasszikus „szerver + tömb” architektúrába, akkor a teljesítmény nem sokat fog változni. Mert még ha ez a tömb háromszor lassabbnak bizonyul is, mint az Exadata tárolórendszer (ami a modern All Flash tömböknél aligha lehetséges), akkor 5%-ot hárommal megszorozva azt kapjuk, hogy az I/O várakozások aránya 15%-ra nő. - az adatbázis ezt biztosan túléli!
Mindkét következtetés pontatlan, ráadásul torzítja az Exadata Software mögött rejlő gondolat megértését. Az Exadata nem csak gyors I/O-t biztosít, hanem alapvetően másként működik, mint a klasszikus szerver + tömb architektúra. Ha az adatbázis-művelet valóban „kidolgozott”, akkor az SQL logika átkerül a tárolórendszerbe. A tárolószerverek számos speciális mechanizmusnak köszönhetően (elsősorban Exadata Storage Indexek, de nem csak) maguk keresik meg a szükséges adatokat, és elküldik a DB-t a szervereknek. Ezt meglehetősen hatékonyan teszik, így a tipikus Exadata-várakozások aránya kicsi a teljes válaszidőben.
Hogyan változik ez a megosztás az Exadatán kívül? Hogyan befolyásolja ez az adatbázis egészének teljesítményét? A tesztelés ad legjobb választ ezekre a kérdésekre. Például az Exadatán kívüli „cella intelligens tábla vizsgálatra” való várakozás olyan nehéz Table Full Scansá válhat, hogy az I/O a teljes válaszidőt lefoglalja, és a teljesítmény drámaian romlik. Éppen ezért helytelen az AWR elemzésekor az Exadata elvárások teljes százalékát úgy tekinteni, mint a varázslatos hozzájárulást a teljesítményhez, és még inkább ezt a százalékot az Exadatán kívüli teljesítmény előrejelzésére használni. Ahhoz, hogy megértsük, mennyire „pontos” az adatbázis működése, tanulmányozni kell a „Példánytevékenység-statisztikák” rész AWR statisztikáit (sok statisztika van magától értetődő névvel), és össze kell hasonlítani őket egymással.
Annak megértéséhez, hogy az Exadatán kívüli adatbázis hogyan fog érezni magát, a legjobb, ha adatbázisklónt készít a célarchitektúrán lévő biztonsági másolatból, és elemzi a klón teljesítményét terhelés alatt. Az Exadata-tulajdonosok általában rendelkeznek ezzel a lehetőséggel.
Szerző: Alexey Struchenko, a Jet Infosystems adatbázis-osztályának vezetője
Forrás: will.com