Sa maikling post na ito, nais kong iwaksi ang isang hindi pagkakaunawaan na may kaugnayan sa pagsusuri ng mga database ng AWR na tumatakbo sa Oracle Exadata. Sa loob ng halos 10 taon, palagi akong nahaharap sa tanong: ano ang kontribusyon ng Exadata Software sa pagiging produktibo? O gamit ang mga bagong likhang salita: gaano ka "eksperto" ang gawain ng isang partikular na database?
Kadalasan ang tamang tanong na ito, sa palagay ko, ay sinasagot nang mali sa pagtukoy sa mga istatistika ng AWR. Ipinapakita nito ang paraan ng paghihintay ng system, na tinatrato ang oras ng pagtugon bilang kabuuan ng oras ng pagpapatakbo ng mga processor (DB CPU) at ang oras ng paghihintay ng iba't ibang klase.
Sa pagdating ng Exadata, lumitaw ang mga partikular na inaasahan ng system na nauugnay sa pagpapatakbo ng Exadata Software sa mga istatistika ng AWR. Bilang isang patakaran, ang mga pangalan ng naturang mga paghihintay ay nagsisimula sa salitang "cell" (ang Exadata Storage server ay tinatawag na isang cell), kung saan ang pinaka-karaniwan ay ang mga paghihintay na may mga self-explanatory na pangalan na "cell smart table scan", "cell multiblock". pisikal na pagbasa" at "cell single block na pisikal na pagbasa".
Sa karamihan ng mga kaso, ang bahagi ng naturang Exadata na paghihintay sa kabuuang oras ng pagtugon ay maliit, at samakatuwid ay hindi sila nahuhulog sa Top10 Foreground Events ayon sa seksyon ng Total Wait Time (sa kasong ito, kailangan mong hanapin ang mga ito sa Foreground Wait. Seksyon ng mga kaganapan). Sa sobrang kahirapan, nakakita kami ng isang halimbawa ng pang-araw-araw na AWR mula sa aming mga customer, kung saan ang mga inaasahan ng Exadata ay kasama sa seksyong Top10 at sa kabuuan ay humigit-kumulang 5%:
pangyayari
Naghihintay
Kabuuang Oras ng Paghihintay (seg)
Avg Maghintay
%DB oras
Wait Class
DB CPU
115.2K
70.4
SQL*Net higit pang data mula sa dblink
670,196
5471.5
8.16ms
3.3
network
cell single block physical read
5,661,452
3827.6
676.07us
2.3
User I/O
I-sync ang rebalance ng ASM
4,350,012
3481.3
800.30us
2.1
iba
cell multiblock pisikal na basahin
759,885
2252
2.96ms
1.4
User I/O
direktang landas na binasa
374,368
1811.3
4.84ms
1.1
User I/O
SQL*Net na mensahe mula sa dblink
7,983
1725
216.08ms
1.1
network
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
User I/O
direktang landas basahin ang temp
520,211
808.4
1.55ms
0.5
User I/O
enq: TM - pagtatalo
652
795.8
1220.55ms
0.5
application
Ang mga sumusunod na konklusyon ay madalas na nakuha mula sa naturang mga istatistika ng AWR:
1. Ang kontribusyon ng Exadata magic sa pagganap ng database ay hindi mataas - hindi ito lalampas sa 5%, at ang database ay "exadatizes" nang hindi maganda.
2. Kung ang naturang database ay ililipat mula sa Exadata patungo sa klasikong "server + array" na arkitektura, kung gayon ang pagganap ay hindi magbabago nang malaki. Dahil kahit na ang array na ito ay lumabas na tatlong beses na mas mabagal kaysa sa Exadata storage system (na halos hindi posible para sa modernong Lahat ng mga array ng Flash), pagkatapos ay pag-multiply ng 5% sa tatlo ay makakakuha tayo ng pagtaas sa bahagi ng I/O na naghihintay sa 15% - ang database ay tiyak na makakaligtas dito!
Pareho sa mga konklusyong ito ay hindi tumpak, bukod pa rito, binabaluktot nila ang pag-unawa sa ideya sa likod ng Exadata Software. Ang Exadata ay hindi lamang nagbibigay ng mabilis na I/O, ito ay gumagana sa panimula na naiiba kumpara sa klasikong server + array architecture. Kung ang pagpapatakbo ng database ay tunay na "exadapted", pagkatapos ay ang SQL logic ay ililipat sa storage system. Ang mga server ng imbakan, salamat sa isang bilang ng mga espesyal na mekanismo (pangunahin ang mga Exadata Storage Index, ngunit hindi lamang), hanapin ang kinakailangang data mismo at ipadala ang DB sa mga server. Ginagawa nila ito nang mahusay, kaya maliit ang bahagi ng karaniwang paghihintay ng Exadata sa kabuuang oras ng pagtugon.
Paano magbabago ang bahaging ito sa labas ng Exadata? Paano ito makakaapekto sa pagganap ng database sa kabuuan? Ang pagsubok ang pinakamahusay na makakasagot sa mga tanong na ito. Halimbawa, ang paghihintay para sa isang "cell smart table scan" sa labas ng Exadata ay maaaring maging isang napakabigat na Table Full Scan na ang I/O ay tumatagal ng buong oras ng pagtugon at ang pagganap ay bumababa nang husto. Iyon ang dahilan kung bakit mali, kapag sinusuri ang AWR, na isaalang-alang ang kabuuang porsyento ng mga inaasahan ng Exadata bilang kontribusyon ng magic nito sa performance, at higit pa sa paggamit ng porsyentong ito para mahulaan ang performance sa labas ng Exadata. Upang maunawaan kung gaano "eksakto" ang gawain ng database, kailangan mong pag-aralan ang mga istatistika ng AWR ng seksyong "Mga Stats ng Aktibidad ng Instance" (maraming istatistika na may mga pangalang nagpapaliwanag sa sarili) at ihambing ang mga ito sa isa't isa.
At para maunawaan kung ano ang mararamdaman ng isang database sa labas ng Exadata, pinakamahusay na gumawa ng clone ng database mula sa isang backup sa target na arkitektura at pag-aralan ang pagganap ng clone na ito sa ilalim ng pagkarga. Ang mga may-ari ng Exadata, bilang panuntunan, ay may ganitong pagkakataon.
May-akda: Alexey Struchenko, pinuno ng departamento ng database ng Jet Infosystems
Pinagmulan: www.habr.com