Сравнительная таблица функционльных возможностей СУБД Oracle на Exadata

Частенько приходят запросы о некой таблице со сравнением производительности Exadata Database Machine и оборудованием некого другого вендора. При этом вендор может быть любой (IBM, HP, Cisco ...), а состав сравниваемого оборудования не определен. Для человека подкованного знаниями специфики работы приложений на СУБД Oracle и уникальным функционалом работы СУБД Oracle на Exadata очевидно, что такую таблицу с конкретными числовыми показателями составить невозможно. Хотя бы потому, что выигрышь в производительности часто основан не на "железных" технических характеристиках (хотя у Exadata они и выдающиеся), а уникальных функциональных возможностях СУБД Oracle на Exadata и способностях приложения их использования.

Вот собственно почему была составлена таблица с перечнем функциональных возможностей определяющих преимущества в производительности при использовании Exadata. Верятно неполная. При необходимости буду корректировать.

Функциональная возможность	Exadata	не Exadata
Специальный протокол передачи информации между СУБД Oracle и СХД – iDB, позволяющий СУБД передавать широкий набор команд и дополнительной информации, используемой на уровне СХД для выполнения операций ускоряющих работу СУБД.	ДА	НЕТ
Процессоры в СХД Exadata для выполнения команд СУБД Oracle и других сервисных операций интегрированных с алгоритмами СУБД.	168 ядер ЦПУ на FULL Rack	НЕТ
Smart Flash Cache – интегрированное с СУБД кэширование данных на уровне СХД, использующее алгоритмы, связанные с особенностями работы СУБД Oracle и дополнительную информацию, поступающую со стороны СУБД через протокол iDB	ДА	НЕТ
Smart Scan – быстрое сканирование данных с возможностью фильтрации строк и выборки столбцов на уровне СХД, используя условия исполняемого SQL. Позволяет распараллелить первичную обработку данных между процессорными мощностями СХД и существенно сократить объем возвращаемых данных	До 100 Гигабайт/сек	НЕТ
Гибридное поколоночное сжатие (Hybrid Columnar Compression) позволяющее не только сократить физическому пространству для хранения данных, но и совместно с Smart Scan существенно ускорить их обработку при сканированиях.	ДА	НЕТ
Smart Flash Log – ускорение и стабилизация времени записи в журнальный файл СУБД Oracle. Технология позволяет использовать интегрированные преимущества динамической и флэш-памяти.	ДА	НЕТ
IO Resource Manager – поддержка приоритетности выполнения операций ввода/вывода, выполняемых системными процессами, критичными для стабильности работы СУБД и её производительности.	ДА	НЕТ
IO Resource Manager – поддержка приоритетности выполнения операций ввода/вывода критичными для бизнеса процессами приложения и ограничения влияния на производительность второстепенных процессов приложения.	ДА	НЕТ

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

Smart Cache для пессимистов

В своем сообщении о Smart Flash Cache я уже писал, что в подавляющем большинстве случаев Вам нет необходимости создавать на флэш-картах дисковые группы для размещения на них редо-логов.  Всё объяснялось достаточно просто – запись на дисковую подсистему происходит гораздо быстрее, чем во флэш-память за счет динамической памяти выполняющей для контролера роль обычного дискового кэша.

Правила, которые пока подтверждались на нагрузочных тестах. Вот, например, тест банковской OLTP на X2-8.  Суммарные показатели с двух узлов:

• Avg log file parallel write:  0.75ms
• physical read total IO requests/sec:  7,037.32
• physical write total IO requests/sec:  6,212.48
• Total I/O requests/sec: 13,249.80

13.2K IOPS - не бог весть, какая нагрузка для Exadata DBM, способной обработать до 1.5M IOPS, т.е. в 100 раз больше. Но это нагрузка реального приложения в пиковый момент, способная “согнуть в дугу” даже High End дисковые массивы.  

Конечно, у каждого правила есть исключения. Если их не видел на практике, то завсегда можно домыслить J По крайней мере мне часто задают вопрос, а что будет, если 512MB кэш динамической памяти контроллера переполнится из-за интенсивной прокачки данных. Вполне допускаю такой вариант, например, когда помимо OLTP нагрузки происходит интенсивное последовательное чтение. Хотя … хотелось бы всё же увидеть.

В общем, даже для пессимистов, которые могут не доверять вышеприведенным данным, в новой версии Exadata Storage Software 11.2.2.4.0 появилась возможность Smart Flash Log.

Ячейка Exadata умная, а потому умеет идентифицировать операции по записи редо.  Попросту с сих пор в Smart Flash Cache выделается некая область, которая содержит последние записи Redo Log.  Это не значит, что запись Redo теперь ведется только туда – нет, принципы не поменялись. Это страховка.  Запись Redo ведется параллельно в Flash Cache и на диск. Смысл?  - Куда быстрее запишет. Сразу после этого ответ об успехе возвращается процессу LGWR.

Как я и говорил ранее, в обычной ситуации запись быстрей будет произведена через дисковый контроллер, но если он по каким-то причинам перегружен, занята память его кэша, то быстрей запись будет произведена во флэш память. Учитывая высокую пропускную способность флэш, нам гарантировано, что время записи не выйдет за определенные пределы. Этот механизм абсолютно прозрачен для СУБД и реализуется на уровне ячейки.

Надёжность данных в флэш? - Просто! В связи с тем, что ASM обеспечивает избыточность, то любая запись в redo будет параллельно производится в 2 или 3 ячейки. Т.е. сохранность записи в флэ-кэш будет обеспечиваться стандартными механизмами Oracle.

Однако, на текущий момент есть одна непонятность  -   в одних источниках сказано, что эта фича активизирована по умолчанию, а в другие требуют ручной активизации на ячейке.

P.S. Не доверяйте теоретикам, никогда не работавших с реальной Exadata и порой выдающих желаемое за действительное. Верьте фактам и цифрам.

Oracle анонсировал 1000-ю инсталляцию Exadata!

27 июня Oracle анонсировал 1000 инсталляцию Oracle Exadata Database Machine у своих клиентов. На текущий момент Exadata используется в 23 различных отраслях в 67 странах мира.
По данным одного из моих коллег у конкурента Exadata в области корпоративных хранилищ Teradata за 30 лет работы 1000 заказчиков и 2500 инсталляций.
1000 инсталляций за чуть более чем 3 года для принципиально нового продукта ... по моему, неплохо А? ;)

http://www.oracle.com/us/corporate/press/422468

Такой большой и очень умный

Многие многоопытные администраторы баз данных Oracle, рассуждая о возможном использовании флэш модулей, расположенных на ячейках Экзадаты, демонстрируют действительно незаурядные фантазии ;) Я попробую показать, что лучше всего эти модули использовать именно так, как по умолчанию их кон фигурируют инженеры Oracle, т.е. как Smart Flash Cache. Но сначала всё-таки давайте узнаем, что же это такое.

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

Когда размер имеет значение

Всем известно, что все современные процессоры имеют несколько уровней кэш. Самые производительные оснащаются КЭШем сразу трёх уровней. Что бы показать тенденцию рассмотрим процессор Intel Xeon X7560, используемый в Exadata модели X2-8.

Уровень	Размер	Латентность (циклы)
L1	32+32 KB на ядро	4
L2	256 KB на ядро	9
L3	24 MB всего (3 МБ на ядро)	63

Вывод из этого прост и вполне очевиден – чем дальше уровень кэш от места, где непосредственно используются данные, тем более медленная, а значит, дешевая память в нем используется. Но главное, все же ни в этом – разница в размерах этих КЭШей составляет порядок.

Если сопоставить размеры оперативной памяти в серверах базы данных с размером Flash Cache на ячейках Exadata, то мы получим следующее:

Модель	Конфигурация	Размер RAM	Размер Flash Cache
X2-8	FULL	2TB	5.3TB
X2-2	FULL	768GB	5.3TB
X2-2	HALF	384GB	2.6TB
X2-2	QUARTER	192GB	1.1TB

Учитывая, что размер буферов СУБД для OLTP приложений в таких конфигурациях вряд ли будет превышать 20-30% от общего размера памяти, мы как раз и получаем те самые доказанные практикой соотношения в порядок. При этом, следуя приведенным выше канонам стоимость памяти на основе FLASH существенно дешевле динамической памяти, используемой в серверах БД.

В этой связи не совсем понятно, какой смысл приобретать high-end дисковые массивы с кэш из дорогой динамической памяти, максимальный размер которой измеряется сотнями гигабайт, что сопоставимо с конфигурируемым размером кэша буферов?! С моей точки зрения в таких случаях гораздо эффективней потратить деньги на увеличение оперативной памяти серверов, а в дисковом массиве оставить размер кэш, который покроет потребности для обеспечения быстрых операций записи.

Но вернемся в к Экзадате, которая следуя “классическим канонам”  кэширования, имеет правильный кэш.  Вторая отличительная особенность этого кэш угадывается в его названии - SMART FLASH CACHE.

Почему кэш SMART?

Строя интеллектуальный сторадж, который умеет обращаться с сохраняемой на нём информации ни как с обезличенным набором битов и байтов, а как с данными СУБД Oracle, было трудно отказаться от соблазна “интеллектуализировать” и алгоритм кэширования.

Ячейки Exadata относятся к кэшированию данных избирательно, отдавая приоритет блокам, к которым с большой вероятностью потребуется повторный доступ. Здесь работают во многом похожие алгоритмы на те, которые определяют правила сохранения данных в КЭШе буферов экземпляра СУБД.

Поэтому данные, которые читаются большими порциями, кэшироваться не будут, если только на уровне сегмента не определить атрибут CELL_FLASH_CACHE KEEP. Всё очень знакомо, неправда ли? "Издревле" подобной операцией пользовались для того, что бы закрепить блоки определенного сегмента в КЭШе экземпляра самой СУБД.

CREATE TABLE pt (c1 number)

  PARTITION BY RANGE(c1)

   (PARTITION p1 VALUES LESS THAN (100)

     STORAGE (CELL_FLASH_CACHE DEFAULT),

    PARTITION p2 VALUES LESS THAN (200)

     STORAGE (CELL_FLASH_CACHE KEEP));

ALTER INDEX tkbi STORAGE (CELL_FLASH_CACHE NONE);

У CELL_FLASH_CACHE  может быть три значения, по названиям которых можно угадать политики, которые они определяют - KEEP, NONE, DEFAULT.  А еще есть хинты…

Я не буду в подробностях вдаваться во все тонкости работы SMART FLASH CACHE, скажу лишь, что эффективность его работы действительно потрясающая.

Посмотрите на AWR отчеты Ваших OLTP систем и найдите время, которое тратится на одиночную операцию чтения. Сколько? На практике испытаний с использованием high end дисковых массивов знаю, что эта величина чаще всего крутится около значения в 5мс. (Ну и где эффект быстрого, но “маленького” КЭШ этих дорогих железок?)

А теперь давайте глянем на пример тяжелого испытания OLTP системы на Exadata X2-8. Около 15 тысяч одновременных сессий с СУБД, выполняющих около 4M logical reads/с при 14K IOPS для всей СУБД.

Пусть Вас не вводит в заблуждение число 1мс – если не округлять, то у нас получится 6192с/7445684 = 0.83мc. (Посчитал и понял, что пример неудачный :) - чаще всего этот показатель составляет около 0.7мс)

Не почувствовать разницу легко, если она почти на порядок :)

А еще флэш память Exadata ячеек можно сконфигурировать как диски ASM… И в этом месте у администраторов СУБД Oracle начинают чесаться руки. 

“Иногда лучше молчать, чем говорить” (с) <- это я про себя.

Сразу следуют вполне естественные предложения:

-          “А давайте на ASM Flash-дисках разметим редологи!”

-          “А можно создать на нем табличное пространство для горячих объектов?”

-          “А что если туда забабахать Database Smart Flash Cache?”

-          …

Всё это конечно можно, но зачем? Oracle создал действительно сбалансированную конфигурацию вплоть до тонкостей. Не трогайте ничего, до тех пор, пока действительно не будете понимать, к каким последствиям приведут Ваши действия.

И все же?! А что если редологи туда? В ответ приведу данные из того же отчета. Cессии на экземпляре генерировали redo порядка 6МБ/с.

А если посчитаем без округлений: 2126c/3458313 = 0.61мс!!!

- Ууупс! А чего так быстро? А всё дело в другом КЭШе :) В обычном кэше, который есть на большинстве дисковых контроллеров. На дисковых контроллерах, которые находятся в каждой ячейке Exadata есть КЭШ из динамической памяти размером 512МБ. Итого 512МБ * 14 ячеек = 7ГБ на конфигурацию FULL. Оказывается вполне достаточно, что бы покрыть потребности в записи такого объема redo (стоит учесть, что второй узел в этом тесте генерировал почти столько же redo).

 И только не нужно меня убеждать в том, что скорость записи на FLASH будет превосходить скорость записи в динамическую память :)

Поехали дальше… 

Как на счет табличного пространства с горячими объектами? Наверное, будет работать быстрее, чем с FLASH CACHE, но только до тех пор, пока FLASH CACHE не разогреется. Относительно времени жизни экземпляра СУБД Oracle это преимущество будет несоизмеримо мало, а после кратковременной эйфории начинется глубокое похмелье - на FLASH дисках данные же нужно дублировать! В результате для горячих объектов будет использоваться в два раза больше дорогой FLASH памяти, что существенно снижает эффективность ее использования. Этого мы добивались?

Ну а желание разместить на FLASH дисках ячеек Database Smart Flash Cache легко бьется другим конём – давайте подумаем и сопоставим время, которое необходимо для обращения к FLASH-карте размещенной в слоте PCI из самой ячейки Exadata со временем, которое необходимо для обращения к ней же с внешнего сервера БД. Огромная разница в латентности при практически совпадающем функционале.

Еще варианты будут?