понедельник, 23 января 2012 г.

Демонстрация возможности консолидации 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;