Tímto krátkým příspěvkem bych rád rozptýlil jedno nedorozumění související s analýzou AWR databází běžících na Oracle Exadata. Již téměř 10 let se neustále setkávám s otázkou: jaký je přínos Exadata Software k produktivitě? Nebo pomocí nově vytvořených slov: jak „expertní“ je práce konkrétní databáze?
Často je tato správná otázka, podle mého názoru, zodpovězena nesprávně s odkazem na statistiky AWR. Představuje metodu čekání systému, která zachází s dobou odezvy jako součtem provozní doby procesorů (DB CPU) a čekací doby různých tříd.
S příchodem Exadata se ve statistikách AWR objevila specifická systémová očekávání související s provozem Exadata Software. Názvy takových čekání zpravidla začínají slovem „cell“ (server Exadata Storage se nazývá buňka), z nichž nejběžnější jsou čekání se samozřejmými názvy „cell smart table scan“, „cell multiblock“. fyzické čtení“ a „fyzické čtení jednoho bloku buňky“.
Ve většině případů je podíl takových Exadata čekání na celkové době odezvy malý, a proto nespadají ani do sekce Top10 Foreground Events by Total Wait Time (v tomto případě je musíte hledat v Foreground Wait sekce Akce). S velkými obtížemi jsme našli příklad denního AWR od našich zákazníků, ve kterém byla očekávání Exadata zařazena do sekce Top10 a celkově činila asi 5 %:
událost
Čeká
Celková doba čekání (s)
Prům. čekání
%DB čas
Počkejte třídu
DB CPU
115.2
70.4
SQL*Net více dat z dblink
670,196
5471.5
8.16ms
3.3
Síť
buňka jeden blok fyzické čtení
5,661,452
3827.6
676.07us
2.3
Uživatelský vstup/výstup
Rebalance synchronizace ASM
4,350,012
3481.3
800.30us
2.1
Ostatní
buněčné multiblok fyzické čtení
759,885
2252
2.96ms
1.4
Uživatelský vstup/výstup
přímá cesta čtení
374,368
1811.3
4.84ms
1.1
Uživatelský vstup/výstup
SQL*Net zpráva z dblink
7,983
1725
216.08ms
1.1
Síť
skenování chytré tabulky buněk
1,007,520
1260.7
1.25ms
0.8
Uživatelský vstup/výstup
přímá cesta čtení tepl
520,211
808.4
1.55ms
0.5
Uživatelský vstup/výstup
enq: TM - spor
652
795.8
1220.55ms
0.5
editaci videa
Z těchto statistik AWR 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 se špatně „exadatizuje“.
2. Pokud se taková databáze přenese z Exadata na klasickou architekturu „server + pole“, pak se výkon příliš nezmění. Protože i když se ukáže, že toto pole je třikrát pomalejší než úložný systém Exadata (což je u moderních polí All Flash jen stěží možné), vynásobením 5 % třemi získáme zvýšení podílu I/O čekání na 15 %. - databáze to určitě přežije!
Oba tyto závěry jsou nepřesné, navíc zkreslují chápání myšlenky Exadata Software. Exadata neposkytuje pouze rychlé I/O, ale funguje zásadně odlišně ve srovnání s klasickou architekturou server + pole. Pokud je databázová operace skutečně „přizpůsobená“, pak se logika SQL přenese do úložného systému. Storage servery si díky řadě speciálních mechanismů (především Exadata Storage Indexes, ale nejenom) samy najdou potřebná data a pošlou DB na servery. Dělají to docela efektivně, takže podíl typických čekání Exadata na celkové době odezvy je malý.
Jak se toto sdílení změní mimo Exadata? Jak to ovlivní výkon databáze jako celku? Na tyto otázky nejlépe odpoví testování. Například čekání na „skenování inteligentních tabulek buněk“ mimo Exadata se může změnit na tak těžké prohledávání tabulky, že I/O zabere celou dobu odezvy a výkon se dramaticky sníží. To je důvod, proč je nesprávné při analýze AWR považovat celkové procento očekávání Exadata za příspěvek jeho magie k výkonu, a ještě více používat toto procento k předpovídání výkonu mimo Exadata. Abyste pochopili, jak „přesná“ je práce databáze, musíte si prostudovat statistiky AWR v sekci „Statistiky činnosti instance“ (existuje spousta statistik se samozřejmými názvy) a vzájemně je porovnat.
A abyste pochopili, jak se bude cítit databáze mimo Exadata, je nejlepší vytvořit klon databáze ze zálohy na cílové architektuře a analyzovat výkon tohoto klonu při zatížení. Majitelé Exadata tuto možnost zpravidla mají.
Autor: Alexey Struchenko, vedoucí databázového oddělení Jet Infosystems
Zdroj: www.habr.com