AWR: насколько «экзадатится» работа базы данных?

Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом AWR баз данных, работающих на Oracle Exadata. Почти 10 лет я постоянно сталкиваюсь с вопросом: каков вклад Exadata Software в производительность? Или с использованием новообразованных слов: насколько «экзадатится» работа той или иной базы данных?

Часто на этот правильный вопрос, на мой взгляд, дается неверный ответ со ссылкой на статистику AWR. В ней представлен метод системных ожиданий, трактующий время отклика как сумму времени работы процессоров (DB CPU) и времени ожиданий различных классов.

С появлением Exadata в статистике AWR появились специфичные системные ожидания, связанные с работой Exadata Software. Как правило названия таких ожиданий начинаются со слова “cell” (ячейкой называется Exadata Storage сервер), из них чаще всего встречаются ожидания с говорящими названиями “cell smart table scan”, “cell multiblock physical read” и “cell single block physical read”.

В большинстве случаев доля таких Exadata-ожиданий в общем времени отклика мала, и поэтому они даже не попадают в секцию Top10 Foreground Events by Total Wait Time (в этом случае их нужно искать в разделе Foreground Wait Events). Мы с большим трудом обнаружили у наших заказчиков пример суточного AWR, в котором Exadata-ожидания попали в секцию Top10 и в сумме составили около 5%:

Из подобной AWR статистики часто делают такие выводы:

1. Вклад магии Exadata в производительность базы данных не высок — не превышает 5 %, а база данных «экзадатится» плохо.

2. Если такую базу перенести с Exadata на классическую архитектуру «сервер + массив», то производительность изменится не сильно. Потому что даже если этот массив окажется втрое медленнее системы хранения Exadata (что едва ли возможно для современных All Flash массивов), то умножив 5% на три мы получим увеличение доли ожиданий ввода-вывода до 15% ­— такое база данных наверняка переживет!

Оба этих вывода неточные, более того они искажают понимание идеи, заложенной в Exadata Software. Exadata не просто обеспечивает быстрый ввод-вывод, она работает принципиально иначе по сравнению с классической архитектурой «сервер + массив». Если работа базы данных действительно «экзадатится» — то на систему хранения переносится SQL-логика. Storage серверы благодаря ряду специальных механизмов (в первую очередь Exadata Storage Indexes, но не только) сами находят нужные данные и пересылают DB северам. Они делают это достаточно эффективно, поэтому доля характерных Exadata-ожиданий в общем времени отклика мала. 

Как изменится эта доля вне Exadata? Как это скажется на производительности базы данных в целом? Лучше всего на эти вопросы ответит тестирование. Например, ожидание “cell smart table scan” вне Exadata может превратиться в такой тяжелый Table Full Scan, что ввод-вывод займет все время отклика и производительность ухудшится драматически. Именно поэтому неправильно при анализе AWR считать суммарный процент ожиданий Exadata вкладом ее магии в производительность и тем более использовать этот процент для прогнозирования производительности вне Exadata. Чтобы понять насколько «экзадатится» работа базы нужно изучать статистики AWR секции “Instance Activity Stats” (там много статистик с говорящими названиями) и сравнивать их между собой.

А чтобы понять, как будет себя чувствовать база данных вне Exadata, лучше всего сделать из бекапа клон базы на целевой архитектуре и проанализировать производительность этого клона под нагрузкой. Такая возможность у обладателей Exadata, как правило, есть.

Автор: Алексей Струченко, руководитель направления БД «Инфосистемы Джет»