Демонстрация возможности консолидации OLTP и DW на Exadata

Коллеги из Польши сделали видео, в котором демонстрируют возможности одновременного эксплуатации OLTP и DW приложений на Oracle Exadata Database Machine. Подчеркну – базы данных для разных приложений используют одни и те же дисковые устройства. Возможно ли это при использовании пусть самого “навороченного”, но обычного дискового массива?!!!

Основные моменты.  Конфигурация Quarter Rack (2 узла СУБД + 3 ячейки Exadata). Для тестов и диагностики используются инструменты Dominic Giles: Swingbench (текстовая версия CharBench), Database Time Monitor и CPU Monitor.

Производится проверка работы I/O Resource Manager как при задаче распределения нагрузки между несколькими БД (Видео №1 и №2), так и между группами сессий внутри одной БД (№3 и №4). Тесты №1 и №3 запускались без активного I/O Resource Manager, а №2 и №4 уже с активными IORM.

Привожу видео и кратко сценарий каждого: основные важные моменты.(Видео смотреть в самом лучшем качестве!)

Часть 1 (6:09): Приложения  OLTP и DW на одной системе, но на разных БД

•  В тесте используются 4 x OLTP БД + 1 x DW БД
•  На DW будут выполняться два аналитических запроса;
•  Размер самых больших таблиц, которые вовлечены при выполнении аналитических запросов: SALES ~390GB, CUSTOMERS ~467GB;
•  Проверка, что план IO Resource Manager не активен на ячейках Exadata;
•  Производится запуск аналитических запросов;
•  После запуска нагрузка на дисковую систему ячеек держится на уровне ~5GB/s;
•  Практически нет нагрузки на ЦПУ на узлах – доступ к данным происходит через cell smart scan;
•  Производится запуск OLTP генератора;
•  Крайне нестабильная работа OLTP – TPS резко прыгает;
•  Нагрузка на ЦПУ узлов незначительно возрастает:
•  Нагрузка на систему хранения практически не меняется;
•  После завершения работы OLTP генератора смотрим показатели TPS: 100-150;

Часть 2 (7:46): Активация IORM с приоритетом OLTP приложений (разные БД)

• · Активация I/O Resource manager;

     o   План IORM
     -   LEVEL 1: edb 75%, fdb 5%, gdb 5%, hdb: 5% 
                                       -  LEVEL 2: adb 80% 
                                      -   LEVEL 3: other 10%

•    Запуск аналитического запроса на DW
•      Следим за объем I/O на ячейках  ~5GB/s
•         На графике загрузки БД ожидание: “cell smart table scan” – осуществляется перенос вычислительной нагрузки на уровень системы хранения;
•  Производится запуск нагрузки OLTP;
•   Демонстрируется статистика ячеек Exadata, которая показывает суммарное ожидание IO запросов от DW в очереди IORM;
•    OLTP приложения демонстрируют стабильную работу и более высокие показатели транзакций в минуту TPM (реально в этот момент происходит стабильный рост, стабилизация на одном уровне произойдет позже ~50K TPM);
•       Возрастает потребление ЦПУ на серверах СУБД за счет увеличения количества OLTP транзакций и резко снижается нагрузка на дисковую систему - большие запросы от DW ограничены с помощью IORM;
•       На статистике с ячеек видно, что ограничение касается только запросов от DW;
•    Оба OLTP генератора завершают свою работу, после чего сразу же увеличивается нагрузка на дисковую систему – запросы от DW больше не имеют ограничений для выполнения;
•        Сравнение средних значений: ~ 110TPS без использования IORM vs ~640TPS с использованием IORM;
•    Шестикратное увеличение в TPS  и что не менее важно – стабильные показатели нагрузки;

Часть 3 (5:46): DWH и OLTP на одной БД без IORM

·         Показатели  теста

o   Размер самых больших таблиц, которые вовлечены при выполнении аналитического отчета: SALES ~390GB, CUSTOMERS ~467GB;

o   Установки для генератора нагрузки OLTP charbench: Users=200, MinDelay = 2, MaxDelay = 2

·         Деактивация плана IORM на ячейках;

·         Запуск двух тяжелых SQL;

·         На ячейках возникает интенсивная нагрузка – общий объем чтения данных составляет ~5GB/s;

·         На графике мониторинга СУБД видно, что основная ожидание это Smart Scan;

·         Запускается генератор OLTP нагрузки;

·         На СУБД события ожидания записи в logfile (log file sync) составляют порядка 50%;

·         Нагрузка на дисковую подсистему ячеек осталась той же;

·         Нагрузка OLTP крайне нестабильна и составляет порядка 10K TPM;

·         Среднее значение за тест ~150TPS;

Часть 4 (9:44):DWH и OLTP на одной БД  c IORM

·         Данные и параметры теста такие де как и в видео 3;

·         Создаём и активизируем план Resource Manager на стороне СУБД:

o   Три группы: OLTP_SOEA1_CGROUP, DWH_SH_CGROUP, DWH_SH1_CGROUP;

o   План:

§  LEVEL 1: OLTP_SOEA1_CGROUP 99%;

§  LEVEL 2: DWH_SH1_CGROUP  90%, DWH_SH_CGROUP 5%, OTHER 5%;

·         Активизируем IORM на ячейках Exadata (план тот же как и в видео №3) – для того, что бы работал план IORM внутри одной БД, требуется активизация плана на уровне ячеек Exadata;

o   План IORM

§   LEVEL 1: edb 75%, fdb 5%, gdb 5%, hdb: 5%

§   LEVEL 2: adb 80%

§   LEVEL 3: other 10%

·         Реально для adb выделены ресурсы на уровне 2 только, но так, как нагрузка на другие БД не подаётся, то это не имеет значения;

·         Запуск двух аналитических отчетов;

·         Как и на предыдущих видео, объем чтения с дисков ~5GB/s – идут smart scans;

·         Запуск генератора OLTP нагрузки;

·         Нагрузка на ЦПУ узлов возрастает;

·         Нагрузка на дисковую систему падает;

·         OLTP показывает нагрузку от 45K до 75K TPM и ~1.2K TPS

·         Статистика с ячеек Exadata показывает, что задержек в очередях выполнения запросов I/O для группы OLTP нет, но есть задержки в очередях для запросов других групп ;

·         Для групп SH1 и SH разница простоя запроса в очередях отличается на порядок – у SH приоритет перед SH1;

·         После завершения OLTP нагрузки, как и на предыдущих тестах, происходит резкий рост нагрузки на ячейки;

·         Сравнение производительности OLTP без активного плана IORM  с тем, когда IORM активен: среднее - 150 TPS vs 1300TPS;