Со овој краток пост би сакал да отфрлам едно недоразбирање поврзано со анализата на базите на податоци AWR кои работат на Oracle Exadata. Речиси 10 години постојано се соочувам со прашањето: каков е придонесот на Exadata Software за продуктивноста? Или со користење на ново измислени зборови: колку е „експертска“ работата на одредена база на податоци?
Често ова точно прашање, според мое мислење, е погрешно одговорено со повикување на статистиката на AWR. Тој го прикажува методот на системско чекање, кој го третира времето на одговор како збир од времето на работа на процесорите (DB CPU) и времето на чекање на различни класи.
Со доаѓањето на Exadata, специфичните очекувања на системот поврзани со работата на Exadata Software се појавија во статистиката на AWR. Како по правило, имињата на таквите чекања започнуваат со зборот „ќелија“ (серверот Exadata Storage се нарекува ќелија), од кои најчести се чекањата со самообјаснувачки имиња „скенирање на паметни табели на ќелии“, „мултиблок на ќелии физичко читање“ и „физичко читање на еден блок од ќелија“.
Во повеќето случаи, уделот на таквите чекања Exadata во вкупното време на одговор е мал, и затоа тие дури и не спаѓаат во делот Топ 10 Настани во преден план по вкупно време на чекање (во овој случај, треба да ги побарате во Чекање во преден план Дел за настани). Со голема тешкотија, најдовме пример за дневен AWR од нашите клиенти, во кој очекувањата на Exadata беа вклучени во делот Топ10 и вкупно изнесуваа околу 5%:
настанот
Чека
Вкупно време на чекање (сек.)
Просечно чекање
%DB време
Час за чекање
DB процесор
115.2K
70.4
SQL*Net повеќе податоци од dblink
670,196
5471.5
8.16ms
3.3
мрежа
физичко читање на еден блок на ќелија
5,661,452
3827.6
676.07us
2.3
Корисник В/И
Синхронизирајте го ребалансот на ASM
4,350,012
3481.3
800.30us
2.1
други
физичко читање на повеќе блокови на ќелии
759,885
2252
2.96ms
1.4
Корисник В/И
прочитана директна патека
374,368
1811.3
4.84ms
1.1
Корисник В/И
SQL*Net порака од dblink
7,983
1725
216.08ms
1.1
мрежа
клеточно паметно скенирање на маса
1,007,520
1260.7
1.25ms
0.8
Корисник В/И
Директна патека за читање температура
520,211
808.4
1.55ms
0.5
Корисник В/И
enq: TM - расправија
652
795.8
1220.55ms
0.5
апликација
Следниве заклучоци често се извлекуваат од ваквата статистика на AWR:
1. Придонесот на магијата Exadata за перформансите на базата на податоци не е висок - не надминува 5%, а базата на податоци „ексадатизира“ слабо.
2. Ако таквата база на податоци се префрли од Exadata во класичната архитектура „сервер + низа“, тогаш перформансите нема многу да се променат. Затоа што дури и ако оваа низа се покаже дека е три пати побавна од системот за складирање Exadata (што е тешко возможно за современите низи All Flash), тогаш множејќи се 5% со три, добиваме зголемување на уделот на I/O чекање до 15% - базата на податоци сигурно ќе го преживее ова!
И двата заклучоци се неточни, згора на тоа, тие го нарушуваат разбирањето на идејата зад Exadata Software. Exadata не само што обезбедува брз I/O, туку работи фундаментално поинаку во споредба со класичната архитектура на сервер + низа. Ако операцијата на базата на податоци е навистина „ексадаптирана“, тогаш SQL логиката се пренесува во системот за складирање. Серверите за складирање, благодарение на голем број специјални механизми (првенствено Exadata Storage Indexes, но не само), самите ги наоѓаат потребните податоци и ја испраќаат DB до серверите. Тие го прават тоа доста ефикасно, така што уделот на типични чекања Exadata во вкупното време на одговор е мал.
Како ќе се промени ова споделување надвор од Exadata? Како ова ќе влијае на перформансите на базата на податоци како целина? Тестирањето најдобро ќе одговори на овие прашања. На пример, чекањето за „паметно скенирање на клеточна маса“ надвор од Exadata може да се претвори во толку тешко целосно скенирање на табелата што В/И го одзема целото време на одговор и перформансите драматично се намалуваат. Затоа е погрешно, кога се анализира AWR, вкупниот процент од очекувањата на Exadata да се смета како придонес на неговата магија во перформансите, а уште повеќе да се користи овој процент за да се предвидат перформанси надвор од Exadata. За да разберете колку е „точна“ работата на базата на податоци, треба да ја проучите статистиката на AWR од делот „Статистика на активноста на пример“ (има многу статистики со самообјаснувачки имиња) и да ги споредите едни со други.
И за да се разбере како ќе се чувствува базата на податоци надвор од Exadata, најдобро е да се направи клонирање на базата на податоци од резервна копија на целната архитектура и да се анализираат перформансите на овој клон под оптоварување. Сопствениците на Exadata, по правило, ја имаат оваа можност.
автор: Алексеј Струченко, раководител на одделот за бази на податоци на Jet Infosystems
Извор: www.habr.com