Oracle Multitenant. Part 3

Хочется подвести некоторые итоги.

Великолепная опция, одна из самых сильных после появления RAC. Отличная интеграция со snapshot, которые можно использовать для test систем вместе flahback database  - я не успел про это написать, но это здорово.

IDC написала отличный отчет, где понятным для руководства языком поясняются достоинства опции. Я не писал о том, что управлять одной базой вместе 10 гораздо легче, все кто читают этот блог,  это знают лучше меня, но повторить руководству может быть и не лишним.

Оказалось, что совсем недавно был замечательный семинар по теме Multitenant, но презентаций оттуда я найти не могу. Надеюсь, их скоро выложат.  Update 1. Презентации уже доступны!

Теперь немного о достигнутых заказчиками результатах  - опции уже год и они должны быть. В отчете IDC на странице 10  приводится такой: компания смогла уменьшить buffer cache на 25% при сохранении того же performance. Сейчас нет ничего дешевле оперативной памяти и покупать EE опцию чтобы уменьшить buffer cache это…<придумайте сравненение сами>

Единственный результаты которые я нашел - это тест Oracle. Консалидация 252 баз данных на T5.


Насколько я понял, сравнили две конфигурации - каждая БД в вирутальной машине (не указано, какая именно это была технологи, Zones или LDOM) с конфигурацией  Multitenant.

Во-первых, сразу сделал вывод что кол-во TPS больше в Multitenant. Конечно есть накладные расходы виртуальных машин, но они же не 50%.  Не могу понять, как у них это получилось.

Во-вторых, в случае Multitenant  уменьшилось кол-во Storage IOPS необходимых для достижения того же кол-ва TPS. Это возможно только если базам данных в виртуальных машинах не хватало памяти под buffer cache.  Те оба результата были получены с помощью зажимая кэша баз данных в виртуальных машинах? Более подробных реультатов тестов нет, ничего сказать нельзя.

Но самое главное, давайте посмотрим на стоимость решения. Предположим мы консолидировали БД которые использовали Partitining и Tuning and Diagnostic Pack.

Считаем по price list, процессорные лицензии:

Вариант с Multitenant:

EE        Partitioning      Diagnostic     Tuning      Multitenant               Cores    Core F
47,500 +   11,500        + 7,500        + 5,000      + 17,500      = 89K * 128   *    0.5  =    $5, 696, 000

Вариант с множеством VM
47,500 +   11,500        + 7,500        + 5,000                           =  71, 500 * 192 * 0.5  =  $ 6, 864, 000

Больше  $1M в терминах прайс листа!  Конечно не стоит забывать, что данная экономия возникла при консолидации 252  баз данных. Хотелось бы увидеть более приближенный к жизни пример консолидации ~ 4-12 баз данных. Экономика может сильно отличаться в этом случае.

Отличная опция, DBA даже не нужно изучать что такое виртуализация, а с Exadata и про железо   и  storage знать ничего не нужно -)


6 комментариев:

  1. Дмитрий - супер обзор,
    А последий вывод - это не шутка, это тенденция.

    ОтветитьУдалить
  2. Уже выложил!

    http://www.igormelnikov.com/2014/06/oracle-multitenant-option.html

    ОтветитьУдалить
  3. Дмитрий,
    материалы нашего семинара по Multitenant уже доступны в блоге Игоря Мельникова.
    Спасибо за обзор.
    Борис.

    ОтветитьУдалить
  4. Игорь, Борис - спасибо, сообщение обновил.

    ОтветитьУдалить
  5. >>>сравнили две конфигурации - каждая БД в вирутальной машине (не указано, какая именно это была технологи, Zones или LDOM) с конфигурацией Multitenant.


    сравнивались, как я понял конфигурации Multitenant и «просто много баз в одном разделе» <- это видимо в понимании oracle означает виртуализацию )


    >>>вывод что кол-во TPS больше в Multitenant.
    >>>в случае Multitenant уменьшилось кол-во Storage IOPS


    Три основных фактора победы Multitenant в данном тесте:


    1. Multitenant база делала лограйтером на 100.000 IOPs меньше чем просто много баз вместе. В варианте Multitenant лограйтер начал лепить коммиты от разных PDBs в пачки по аж 38 штук. Что помешало использовать BATCH commit во всех индивидуальных базах для такого же эффекта неизвестно. Батчевые коммиты отменили в 12c? Или результаты красивые не получались?


    2. Удалось сэкономить память двумя основными способами. 150Гб честной экономии от существенно меньшего количесва background процессов (почти 10 тысяч штук в случае «плохой» консолидации) и 150Гб от непонятно почему ужавшегося Shared Pool. Не от того ли он ужался почти в 5 раз что все (или большинство из 252 баз) использовали одни и те же sql-выражения и курсоры? Как часто такое случается при консолидации 252 разных баз? Сэкономленная память пошла на увеличение Buffer Pool (как раз +300Гб получилось) -> меньше чтений с диска -> больше TPS приложению


    3. В варианте Multitenant сильно меньше background процессов, в случае плохой консолидации они приводили к потреблению отмеренных им 68% CPU вот в такой пропорции: 40 %user + 28 %sys. В случае Multitenant пропорция была другой: 58 %user + 10 %sys, естественно что пользовательским сессиям досталось больше процессора в случае Multitenant. Большой вопрос, конечно, почему Solaris не может нормально переключать контекст между жалкими 10ю тысячами процессов и уходит в 30% SYS =) думаю другая ОС справилась бы лучше )


    Итого: 1. много лограйтер IOPs можно было победить и в простом варианте. 2. Если не шулерствовать с shared Pool экономия памяти получается 150-200Гб по деньгам не так дорого для двух-терабайтной машины. 3. очевидно, есть какие-то проблемы с context-switching в solaris —> можно решить уйдя в другую ОС


    >>>Больше $1M в терминах прайс листа!


    Опция конечно хорошая и возможно она найдет еще своих пользователей, только вот экономический эффект от нее может не быть таким красивым )


    подробности теста тут —> http://www.oracle.com/technetwork/database/multitenant/learn-more/oraclemultitenantt5-8-final-2185108.pdf

    ОтветитьУдалить
    Ответы
    1. Иван, спасибо за ссылку - очевидно я не смог найти ее из за бана в Гугле -). Если посмотреть на конфигурацию, используемую в тесте, там 1/3 баз данных имела размер 1Gb, другая - 5Gb, третья - 15Gb. Вряд ли это слишком реалистическая ситуация у заказчиков. На мой взгляд, Oracle хотел продемонстрировать техническую возможно поместить 252 БД в одну. Также они пишу что все базы были одинаковыми - очевидно за счет это нагрузка складывалась так хорошо. На самом деле заказчикам все равно на сколько будет там записей LGWR - нужно чтобы было не хуже чем в оригинале и стоило дешевле.

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

      Удалить