[Oracle, Администрирование баз данных] AWR: насколько «экзадатится» работа базы данных?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом 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%:EventWaitsTotal Wait Time (sec)Avg Wait% DB timeWait ClassDB CPU
115.2K
70.4
SQL*Net more data from dblink670,1965471.58.16ms3.3Networkcell single block physical read5,661,4523827.6676.07us2.3User I/OSync ASM rebalance4,350,0123481.3800.30us2.1Othercell multiblock physical read759,88522522.96ms1.4User I/Odirect path read374,3681811.34.84ms1.1User I/OSQL*Net message from dblink7,9831725216.08ms1.1Networkcell smart table scan1,007,5201260.71.25ms0.8User I/Odirect path read temp520,211808.41.55ms0.5User I/Oenq: TM - contention652795.81220.55ms0.5ApplicationИз подобной 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, как правило, есть.Автор: Алексей Струченко, руководитель направления БД «Инфосистемы Джет»
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление проектами] Обучение пользователей в эпоху коронавируса
- [Тестирование IT-систем, PostgreSQL, IT-инфраструктура, Администрирование баз данных] Моделирование отказоустойчивых кластеров на базе PostgreSQL и Pacemaker
- [Высокая производительность, Восстановление данных, Администрирование баз данных, Резервное копирование, Хранение данных] Путеводитель по резервному копированию баз данных
- [Oracle, SQL] Oracle. Про View
- [Open source, PostgreSQL, Администрирование баз данных] Знакомство с pg_probackup. Первая часть
- [Информационная безопасность, PostgreSQL, Администрирование баз данных] Реализация ролевой модели доступа с использованием Row Level Security в PostgreSQL
- [Big Data, Машинное обучение] Спасти рядового датасайнтиста. Как работать над компьютерным зрением, чтобы сделать проект и не потерять себя
- [PostgreSQL, Программирование, SQL, Администрирование баз данных] PostgreSQL Antipatterns: уникальные идентификаторы
- Доступен Solaris 11.4 SRU24
- [Oracle] Автоматизированное получение отчетности OBIEE клиентом
Теги для поиска: #_oracle, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_exadata, #_awr, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_oracle, #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:58
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом 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%:EventWaitsTotal Wait Time (sec)Avg Wait% DB timeWait ClassDB CPU 115.2K 70.4 SQL*Net more data from dblink670,1965471.58.16ms3.3Networkcell single block physical read5,661,4523827.6676.07us2.3User I/OSync ASM rebalance4,350,0123481.3800.30us2.1Othercell multiblock physical read759,88522522.96ms1.4User I/Odirect path read374,3681811.34.84ms1.1User I/OSQL*Net message from dblink7,9831725216.08ms1.1Networkcell smart table scan1,007,5201260.71.25ms0.8User I/Odirect path read temp520,211808.41.55ms0.5User I/Oenq: TM - contention652795.81220.55ms0.5ApplicationИз подобной 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, как правило, есть.Автор: Алексей Струченко, руководитель направления БД «Инфосистемы Джет» =========== Источник: habr.com =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_oracle, #_administrirovanie_baz_dannyh ( Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 23:58
Часовой пояс: UTC + 5