OOW. Заключение

Многие говорят, что это был самый интересный OpenWorld за последнее время. Наверное. Очень много анонсов. Для меня это  был уникальный OOW, поскольку я получил возможность поговорить сразу с разработчиками как Oracle так и IBM. Это очень интересно, когда  технические специалисты аргументируют свое видение стратегии.  

Но у этого OpenWorld есть и еще очень важная для меня лично часть. Те, кто давно читает блог наверняка помнят пост про золушку. Тогда очень многие стали говорить, что я "нападаю" на Oracle. Напомню вкратце, что речь шла о том, что при небольшом количестве дисков при двойном зеркалировании есть достаточно высокая вероятность потери данных.  И что мы видим сейчас - выходит Database Appliance, в котором.. применяется тройное зеркалирование. Это было совершенно очевидное решение проблемы. В best practice по Exadata с недавних пор настоятельно рекомендуют  использовать тройное зеркалирование.

Я писал что сжатие базы данных  в 10 раз - это просто маркетинг.   Что это зависит от данных и в большей степени достигается только когда данные пресортированы. Читайте:
"There’s no question that HCC can give you much better results than basic compression – but it’s important to note that the data patterns and basic content make a big difference to how well the data can be compressed."

Я написал, что стратегии Oracle по cloud немного странная. Нет вполне очевидных на сегодняшний день вещей.  Пожалуйста, в этот OpenWorld целый день был выделен cloud, вышел EM12 (Cloud edition), уже не говоря о cloud.oracle.com

И наконец в комментариях к этому посту я уж совсем стал заговариваться и рассказывать что у  Exadata вполне могут быть проблемы с  OLTP нагрузкой потому что redo logs...лежат вместе с данными и  512Mb кэша обычного диска не хватает. Сразу несколько сотрудников Oracle написали, что проблемы не существует. Но Oracle Dev думал по-другому - и буквально на днях анонсировали Smart Flash Log - теперь redo запись идет параллельно на диск и flash и ответ приложению дается  когда одна из записей прошла. Если бы проблемы не было, то и не было бы нужды делать это изменение. Это значительное улучшение для OLTP.

Я хочу выразить искреннее признательность:

- Oracle Corp за возможность посетить OpenWorld
- IBM - за всестороннюю поддержку и финансовую помощь в этой поездке
- Oracle Dev Team за незабываемый ужин -)
- IBM Dev Team за глубокое погружение в технологии компании

PS На картинке вы видите автограф Rick Greenwald, одного из авторов книги по Exadata.

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

  1. Дмитрий, цифры в посте про золушку неверные. Нет там никаких 41%. При самом неблагоприятном исходе: заводской брак, не более 2%.
    Один Alex ошибся в рассчетах, не стоит на этом фундаменте строить целую теорию. Как правильно считать, объяснил второй Alex на семинаре ruoug http://www.ruoug.org/events/20110420/RuOUG-Apr2011-Oracle-ASM-by-Alex-Gorbachev-no-builds.pdf

    Но с замечанием про тыкву согласен - даже имея ASM нужно делать бекап. Вероятность выхода массива из строя есть всегда.

    ОтветитьУдалить
  2. Анонимный10/10/11 12:39 PM

    Верните Волкову Oracle! Верните Oracle Волкова!

    ОтветитьУдалить
  3. Анонимный10/10/11 2:28 PM

    По сжатию - тесты на реальной базе заказчика показали результаты сжатия от 7 до 15 раз в зависимости от типа данных. Средняя температура по больнице составила 11 градусов. Это факт.

    ОтветитьУдалить
  4. >Один Alex ошибся в рассчетах, Как правильно считать, объяснил второй Alex
    Оба Alex считают правильно. 41% процент вероятности потери данных при выходе из строя второго диска. Alex второй делает вывод по Google какая вероятности выхода из строя дисков одной партии, но не учитывает что диски стоят в одной коробке при одной температуре. Это разные цифры. Я мог бы долго про это писать - но проще всего поверить Oracle Dev который рекомендует делать тройное зеркалирование.
    >Верните Волкову Oracle
    все 15% моих акций пожалуйста

    >Средняя температура по больнице составила 11 градусов. Это факт
    Грамотно. Технически аргументировано. Совершенно анонимно. Я верю вам.

    ОтветитьУдалить
  5. Exadata User10/10/11 6:16 PM

    > у Exadata вполне могут быть проблемы с OLTP нагрузкой потому что redo logs...лежат вместе с данными и 512Mb кэша обычного диска не хватает

    Во-первых, у Exadata - 512MByte кэш на каждые 12 дисков (7 гигабайт на 168 дискова в конфигурации Full Rack).

    Во-вторых, Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.

    В-третьих, проблемы не сущестует. Тот факт, что Oracle Dev добавил функционал Smart Flash Log - не есть признание какой-либо проблемы. Это естественный шаг по использованию дополнительного уровня СХД - в аварийной ситуации, при недоступности кэша, это может спасти производительность Экзадаты.

    ОтветитьУдалить
  6. >проблемы не сущестует. Тот факт, что Oracle Dev добавил функционал
    Вы по ссылке ходили ? График видели ? Страус тоже закапывается в песок и проблемы не существует.

    >Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.
    Аллилуйя ! IBM вообще рядом не стояла. До сих пор делают дисковые массивы размером со шкаф. Другое дело - JBOD из обычных дисков -))))

    ОтветитьУдалить
  7. Exadata User10/10/11 6:50 PM

    2 Dmitry Volkov

    > Вы по ссылке ходили ? График видели ? Страус тоже закапывается в песок и проблемы не существует.

    График совершенно справедливо показывает, что флэш быстрее дисков - в той самой аварийной ситуации, когда кэш недосупен.

    Разработчики Оракла просто добавили более оптимальную обработку аварийной ситуации: если кэша нет, пусть уж лучше лог идет на флэш, а не диски.

    >>Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.
    > Аллилуйя ! IBM вообще рядом не стояла. До сих пор делают дисковые массивы размером со шкаф. Другое дело - JBOD из обычных дисков -))))

    У всех производителей используются одни и те же диски. Но используются по-разному. В Экзадате диски используются оптимальным для СУБД Оракл способом. И там, конечно же, не JBOD-ы, а контоллерные полки, если полки, если проводить аналогии с традиционными СХД.

    А уж IBM в смысле СХД и впрямь рядом не стояла.

    ОтветитьУдалить
  8. >В-третьих, проблемы не сущестует
    >просто добавили более оптимальную обработку аварийной ситуации

    Вы сами-то помните что сказали 5 минут назад ?

    ОтветитьУдалить
  9. Анонимный10/10/11 10:38 PM

    Волкова назад в Oracle!
    Что он вообще в IBM делает?

    ОтветитьУдалить
  10. > Что он вообще в IBM делает?
    Я занимаюсь Oracle Database, в частности вопросами perfomance, tuning, best practices for AIX.

    ОтветитьУдалить
  11. Анонимный11/10/11 10:17 AM

    Дим, пока ты освещал OOW, ты был объективен, а сейчас IBM' ские уши полезли. Не айс. :-)

    ОтветитьУдалить
  12. > сейчас IBM' ские уши полезли
    Знаю что ходить по ссылкам не барское дело, но откройте для себя Alex Fatkulin, Jonathan Lewis и Mark Fielding. Это супер объективные парни.

    ОтветитьУдалить
  13. Exadata User12/10/11 5:52 PM

    2 Dmitry Volkov

    >>В-третьих, проблемы не сущестует
    >>просто добавили более оптимальную обработку аварийной ситуации

    > Вы сами-то помните что сказали 5 минут назад ?

    Да, Дмитрий, я помню, что я говорю.

    А вот вы пытаетесь выдать желаемое за действительно - что оптимизация обработки аварийной ситуации, есть призанание наличие проблемы.

    А проблемы нет. Кэш Экзадаты не переполняется, как бы вам в IBM этого бы не хотелось.

    ОтветитьУдалить
  14. >Кэш Экзадаты не переполняется


    Вот только Oracle Dev думает по другому. См слайд 30

    http://crmondemand.oracle.com/technetwork/database/exadata/exadata-storage-technical-overview-128045.pdf?page=30

    "
    These peaks would correspond to the times when the controller RAM cache is full" by Mark Fielding

    ОтветитьУдалить
  15. Exadata User13/10/11 12:21 AM

    > Вот только Oracle Dev думает по другому. См слайд 30

    > http://crmondemand.oracle.com/technetwork/database/exadata/exadata-storage-technical-overview-128045.pdf?page=30

    > " These peaks would correspond to the times when the controller RAM cache is full" by Mark Fielding

    Oracle Dev так не думает, не дезинформируйте.

    На слайде #30 приведен график, где сравнивается скорость дисков без кэша и флэша. И все.

    А дальше вы нашли совсем на другом, не оракловском сайте, цитату принадлежащую Mark Fielding, где он комментируя этот слайд, предполагает, что видимо, это отражение ситуации, когда "cache is full". В Оракле Марк не работает, так что пусть предполагает, что хочет. Кэш Экзадаты от его, и тем более, от ваших, предположений не переполнится.

    Вы же вообще о существовании кэша в Экзадате от меня узнали совсем недавно. Но сразу же развели теоретизирование. Однако, у вас лишь предположения, а у нас знания, подкрепленные практикой.

    ОтветитьУдалить
  16. >На слайде #30 приведен график, где сравнивается скорость дисков без кэша и флэша. И все.


    Правда ? Вы были на презентации ? А Marc Fielding был - я с ним разговаривал и мы обсуждали этот момент.


    >Вы же вообще о существовании кэша в Экзадате от меня узнали совсем недавно

    Папа ? Мама ? сколько раз я просил вас не комментировать ничего в моем блоге ..-))

    Спасибо что вспомнили этот случай. Вот пост про который идет речь
    http://dsvolk.blogspot.com/2011/07/exadata-better-than-emc.html

    Ваша цитата:
    "
    Exadata User комментирует...

    Также, Вы не знаете, что кэш в контроллере, который на самом диске, на запись отключен - так делается в любом нормальном дисковом массиве, или сервере
    "

    Вы написали что кэш отключен. После чего пишите мне что я от вас узнал про существование кэша. Это достойно.


    >В Оракле Марк не работает, так что пусть предполагает, что хочет

    Теперь понятно. Вы делите людей на тех кто работает в Oracle и всех прочих ламеров. Это ваше право. Надеюсь заказчики оценят ваше высказывание.

    >у нас знания, подкрепленные практикой.
    У вас, это у кого ? у серых ников ? Вы даже подписаться боитесь.


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

    ОтветитьУдалить
  17. Exadata User13/10/11 12:04 PM

    >> Также, Вы не знаете, что кэш в контроллере, который на самом диске, на запись отключен - так делается в любом нормальном дисковом массиве, или сервере
    "

    > Вы написали что кэш отключен. После чего пишите мне что я от вас узнал про существование кэша.

    Дмитрий - на самом диске, есть свой собвственный контролле, со своим собственным кэшем, мегов этак до 64. И вот он отключен.


    >>В Оракле Марк не работает, так что пусть предполагает, что хочет

    > Теперь понятно. Вы делите людей на тех кто работает в Oracle и всех прочих ламеров.

    Нет. Вы приписали предположения Марка - разработчикам Оракла. Будто бы они сообщили о переполняющемся кэше. Ничего подобного не было.

    ОтветитьУдалить
  18. Анонимный13/10/11 8:40 PM

    очевидно, что не работающий в оракле дима действительно отождествляет две принципиально разные сущности - какого-то чувака и Oracle development. очевидно, что чувак не при делах (как и дима), рядом с мопедом даже близко не стоял, и попытка выдать его слова за мнение Oracle development есть ни что иное как вопиющее пренебрежение известным принципом "после этого не значит вследствие этого" и классическое размещение об'явы.

    ranger.

    ps. ненавижу айфон за отсутствие твердого знака, а русский язык - за его наличие.
    pps. ods - one developer said. вот вероятный источник информации :-) чтож, тебя можно понять :-)


    впрочем, так как дима суть есть типичный мимо проходил-кун - то и
    поведение оное следует признать более яем нормальным.

    ОтветитьУдалить
  19. >что не работающий в оракле ..две принципиально разные сущности - какого-то чувака

    Этот 'какой-то чувак' ведущий технический эксперт в компании партнере Oracle, которая на OpenWorld получила Titan Award (в том числе) за поддержку клиента на Exadata. Все было бы ничего, но ты высказываешь явное пренебрежение только на основании факта что он не работает в Oracle. Со стороны сотрудника support организации такое отношение к клиентам и партнерам доставляет

    Теперь о главном. Ты не отрицаешь факта что 'какой-то чувак' прав. Нет. Ты не даешь другого объяснения происходящему на графике. Тоже нет. Ты пытаешь скомпрометировать человека высказывая сомнения что не может знать про это.

    ОтветитьУдалить
  20. Анонимный14/10/11 1:17 AM

    я его не знаю. ни лично, ни еще как. поэтому "какой-то чувак" меня вполне устраивает. some dude. that's it.

    далее, по поводу явного пренебрежения: именно его я и высказываю, правда, я уже усомнился - в адрес того ли чувака я его высказываю, ибо я задумался о том, что вроде бы фразу этого чувака с графиком не его авторства из презентации не его, опять же, авторства, связал (выдав это за мнение "oracle dev") какой-то другой чувак :)

    в любом случае - я волен высказывать оное пренебрежение, хочешь ты того или нет :)

    > Теперь о главном. Ты не отрицаешь факта что 'какой-то чувак' прав. Нет.
    > Ты не даешь другого объяснения происходящему на графике. Тоже нет.
    > Ты пытаешь скомпрометировать человека высказывая сомнения что не
    > может знать про это.

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

    я утверждаю лишь, что не работая в oracle development утверждать что-либо от ее имени и даже просто со ссылкой на нее - это, по меньшей мере, самонадеянно (надеюсь, я достаточно мягко выразился). другой вопрос - если ты мог бы дать ссылку на какой-нибудь ресурс авторства "oracle dev" (а уж я подлинность я проверю, не сомневайся :)) в котором заявляется возможность переполнения кэша и соответствие этих моментов каким-то пикам на каких-то графиках...

    компрометировать я никого не собираюсь, и ни в коем разе не высказываю сомнений в том, что человек "может не знать про это" (кстати - про это - это про то, что oracle dev не заявлял что кэш экзадаты не может переполняться? :)

    что до твоих методов ведения дискуссии - они типично женские: это называется "подмена тезиса". вроде бы все хорошо, и вдруг раз - мы разговариваем на другую тему :) и, оказывается, я кого-то пытаюсь скомпрометировать, да еще мне какое-то отношение предъявляют. trololo.

    ranger.

    ОтветитьУдалить
  21. Exadata User14/10/11 1:45 AM

    > объяснения происходящему на графике

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

    ОтветитьУдалить
  22. >Ranger said:
    >да я вообще про экзадату не говорю, и про графики тоже :D я знать не знаю, в чем там дело, ибо экзадатой не занимаюсь

    Спасибо

    >другой вопрос - если ты мог бы дать ссылку на какой-нибудь ресурс авторства "oracle dev"в котором заявляется возможность переполнения кэша

    Exadata Smart Flash Cache Features and the
    Oracle Exadata Database Machine

    http://www.oracle.com/technetwork/database/exadata/exadata-smart-flash-cache-366203.pdf

    стр 8

    In an OLTP workload, fast response time for database log writes is crucial. The Database
    Administrator (DBA) configures redo log groups and mirrored log files for availability but slow
    disk performance can have a negative impact on redo log write wait time and system
    performance – log writes wait for the write to the slowest disk to complete. Additionally, disk
    drives themselves can experience occasional “hiccups” in performance. These spikes can have a
    huge impact on database performance

    >а уж я подлинность я проверю, не сомневайся

    Начинай проверять

    ОтветитьУдалить
  23. Анонимный14/10/11 9:45 AM

    скучно. опять подмена тезиса.

    соскок с темы засчитан.

    ranger.

    ps. а "спасибо" - это за то, что экзадатой не занимаюсь? :) право, не стоит - это осознанный выбор, хотя в экзадата-тиме вакансии есть, не проблема.

    ОтветитьУдалить
  24. >На графике происходит то, что бывает при отключении кэша на запись в аварийной ситуации:

    Конечно нет. Читать здесь http://www.oracle.com/technetwork/database/exadata/exadata-smart-flash-cache-366203.pdf

    стр 8

    Цитата оттуда есть выше.

    ОтветитьУдалить
  25. >соскок с темы засчитан.
    ranger,
    В чем для тебя была тема ?
    Ты сам написал
    "я знать не знаю, в чем там дело, ибо экзадатой не занимаюсь"

    не дал никаких комментариев по графику, не дал ни одного своего объяснения.

    Ты написал что "что не работая в oracle development утверждать что-либо от ее имени и даже просто со ссылкой на нее"

    Святая Инквизиция ! Те уже нельзя ссылать на публичную презентацию и комментировать ее ?

    Это доставляет. Тебе бы в PR пойти работать. Тогда ты бы ты всех построил как надо.

    Будь конкретней. Есть что скать по теме поста - welcome. А нет - ...ну ты понял -)

    ОтветитьУдалить