Per ĉi tiu mallonga afiŝo mi ŝatus dispeli unu miskomprenon rilate al la analizo de AWR-datumbazoj funkcianta sur Oracle Exadata. Dum preskaŭ 10 jaroj, mi konstante alfrontis la demandon: kia estas la kontribuo de Exadata Programaro al produktiveco? Aŭ uzante ĵus kreitajn vortojn: kiom "sperta" estas la laboro de aparta datumbazo?
Ofte ĉi tiu ĝusta demando, laŭ mi, estas malĝuste respondita rilate al AWR-statistiko. Ĝi prezentas la sisteman atendmetodon, kiu traktas respondtempon kiel la sumon de la funkciada tempo de procesoroj (DB CPUoj) kaj la atendotempo de diversaj klasoj.
Kun la apero de Exadata, specifaj sistemaj atendoj ligitaj al la funkciado de Exadata Programaro aperis en AWR-statistiko. Kiel regulo, la nomoj de tiaj atendoj komenciĝas per la vorto "ĉelo" (la servilo Exadata Storage nomiĝas ĉelo), el kiuj la plej oftaj estas atendoj kun la mem-klarigeblaj nomoj "ĉela inteligenta tablo-skanado", "ĉela multibloko". fizika legado" kaj "ĉela ununura bloko fizika legado".
Plejofte, la parto de tiaj Exadata-atendoj en la tuta responda tempo estas malgranda, kaj tial ili eĉ ne falas en la sekcion Top10 Foreground Events by Total Wait Time (en ĉi tiu kazo, vi devas serĉi ilin en la Foreground Wait). Sekcio Eventoj). Kun granda malfacileco, ni trovis ekzemplon de ĉiutaga AWR de niaj klientoj, en kiu Exadata-atendoj estis inkluditaj en la Top10-sekcio kaj entute sumiĝis al ĉirkaŭ 5%:
okazaĵo
Atendas
Tuta Atenda Tempo (sec)
Meze Atendu
%DB tempo
Atendu Klaso
DB CPU
115.2K
70.4
SQL*Net pli da datumoj de dblink
670,196
5471.5
8.16ms
3.3
reto
ĉelo ununura bloko fizika legado
5,661,452
3827.6
676.07us
2.3
Uzanto I/O
Sinkronigi ASM-reekvilibron
4,350,012
3481.3
800.30us
2.1
aliaj
ĉela multibloka fizika legado
759,885
2252
2.96ms
1.4
Uzanto I/O
rekta vojo legita
374,368
1811.3
4.84ms
1.1
Uzanto I/O
SQL*Reta mesaĝo de dblink
7,983
1725
216.08ms
1.1
reto
ĉela inteligenta tablo-skanado
1,007,520
1260.7
1.25ms
0.8
Uzanto I/O
rekta vojo legi temp
520,211
808.4
1.55ms
0.5
Uzanto I/O
enq: TM - disputo
652
795.8
1220.55ms
0.5
Apliko
La sekvaj konkludoj ofte estas desegnitaj de tia AWR-statistiko:
1. La kontribuo de Exadata-magio al datumbaza rendimento ne estas alta - ĝi ne superas 5%, kaj la datumbazo "eksadatiĝas" malbone.
2. Se tia datumbazo estas translokigita de Exadata al la klasika arkitekturo "servilo + tabelo", tiam la agado ne multe ŝanĝiĝos. Ĉar eĉ se ĉi tiu tabelo montriĝas trioble pli malrapida ol la stoksistemo Exadata (kio apenaŭ eblas por modernaj All Flash-tabeloj), tiam multiplikante 5% per tri ni ricevas pliigon de la parto de I/O-atendoj ĝis 15% - la datumbazo certe postvivos ĉi tion!
Ambaŭ ĉi tiuj konkludoj estas malprecizaj, krome, ili distordas la komprenon de la ideo malantaŭ Exadata Programaro. Exadata ne nur provizas rapidan I/O, ĝi funkcias fundamente malsame kompare kun la klasika arkitekturo servilo + tabelo. Se la datumbaza operacio estas vere "eksadaptita", tiam la SQL-logiko estas translokigita al la stokadsistemo. Stokaj serviloj, danke al kelkaj specialaj mekanismoj (ĉefe Exadata Stokado-Indeksoj, sed ne nur), mem trovas la necesajn datumojn kaj sendas la DB al la serviloj. Ili faras tion sufiĉe efike, do la parto de tipaj Exadata atendoj en la tuta respondtempo estas malgranda.
Kiel ĉi tiu akcio ŝanĝiĝos ekster Exadata? Kiel ĉi tio influos la agadon de la datumbazo entute? Testado plej bone respondos ĉi tiujn demandojn. Ekzemple, atendi "ĉelan inteligentan tablon-skanadon" ekster Exadata povas iĝi tiel peza Table Full Scan, ke I/O okupas la tutan respondtempon kaj agado malpliiĝas draste. Tial estas malĝuste, kiam oni analizas AWR, konsideri la totalan procenton de Exadata-atendoj kiel la kontribuon de ĝia magio al rendimento, kaj eĉ pli uzi ĉi tiun procenton por antaŭdiri rendimenton ekster Exadata. Por kompreni kiom "preciza" la laboro de la datumbazo estas, vi devas studi la AWR-statistikon de la sekcio "Instance Activity Stats" (estas multaj statistikoj kun memklarigeblaj nomoj) kaj kompari ilin unu kun la alia.
Kaj por kompreni kiel sentos datumbazo ekster Exadata, plej bone estas fari datumbazan klonon de sekurkopio sur la cela arkitekturo kaj analizi la agadon de ĉi tiu klono sub ŝarĝo. Posedantoj de Exadata, kutime, havas ĉi tiun ŝancon.
Aŭtoro: Alexey Struchenko, estro de la datumbaza sekcio de Jet Infosystems
fonto: www.habr.com