С тази кратка публикация бих искал да разсея едно недоразумение, свързано с анализа на AWR бази данни, работещи на Oracle Exadata. В продължение на почти 10 години непрекъснато се изправям пред въпроса: какъв е приносът на Exadata Software за производителността? Или използвайки новоизмислени думи: колко „експертна“ е работата на определена база данни?
Често на този правилен въпрос според мен се отговаря неправилно по отношение на статистиката на AWR. Той представя метода на системно изчакване, който третира времето за реакция като сбор от времето за работа на процесорите (DB CPU) и времето за изчакване на различни класове.
С появата на Exadata в AWR статистиката се появиха специфични системни очаквания, свързани с работата на софтуера Exadata. По правило имената на такива изчаквания започват с думата „клетка“ (сървърът Exadata Storage се нарича клетка), от които най-често срещаните са изчаквания с разбираеми имена „cell smart table scan“, „cell multiblock“ физическо четене“ и „физическо четене на единичен блок на клетка“.
В повечето случаи делът на такива чакания на Exadata в общото време за отговор е малък и поради това те дори не попадат в секцията Top10 Foreground Events by Total Wait Time (в този случай трябва да ги търсите в Foreground Wait раздел Събития). С голяма трудност открихме пример за ежедневен AWR от нашите клиенти, в който очакванията на Exadata бяха включени в раздела Top10 и общо възлизаха на около 5%:
събитие
коледари
Общо време на изчакване (сек)
Средно изчакване
%DB време
Изчакайте клас
DB процесор
115.2K
70.4
SQL*Нет повече данни от dblink
670,196
5471.5
8.16ms
3.3
мрежа
физическо четене на единичен блок на клетка
5,661,452
3827.6
676.07us
2.3
Потребителски I/O
Синхронизиране на баланса на ASM
4,350,012
3481.3
800.30us
2.1
Други
клетъчно многоблоково физическо четене
759,885
2252
2.96ms
1.4
Потребителски I/O
директен път четене
374,368
1811.3
4.84ms
1.1
Потребителски I/O
SQL*Net съобщение от dblink
7,983
1725
216.08ms
1.1
мрежа
клетъчно интелигентно сканиране на таблица
1,007,520
1260.7
1.25ms
0.8
Потребителски I/O
директен път четене темп
520,211
808.4
1.55ms
0.5
Потребителски I/O
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 може да се превърне в толкова тежко пълно сканиране на таблица, че I/O отнема цялото време за реакция и производителността се влошава драстично. Ето защо е погрешно, когато се анализира AWR, да се разглежда общият процент на очакванията на Exadata като принос на неговата магия към производителността и още повече да се използва този процент за прогнозиране на производителността извън Exadata. За да разберете колко „точна“ е работата на базата данни, трябва да проучите статистиката на AWR в раздела „Статистика на активността на екземпляра“ (има много статистики с имена, които се обясняват сами по себе си) и да ги сравните една с друга.
И за да разберете как ще се чувства база данни извън Exadata, най-добре е да направите клонинг на база данни от резервно копие на целевата архитектура и да анализирате производителността на този клонинг при натоварване. Собствениците на Exadata, като правило, имат тази възможност.
Автор: Алексей Струченко, ръководител на отдела за бази данни Jet Infosystems
Източник: www.habr.com