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.
Но у этого 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.
Дмитрий, цифры в посте про золушку неверные. Нет там никаких 41%. При самом неблагоприятном исходе: заводской брак, не более 2%.
ОтветитьУдалитьОдин Alex ошибся в рассчетах, не стоит на этом фундаменте строить целую теорию. Как правильно считать, объяснил второй Alex на семинаре ruoug http://www.ruoug.org/events/20110420/RuOUG-Apr2011-Oracle-ASM-by-Alex-Gorbachev-no-builds.pdf
Но с замечанием про тыкву согласен - даже имея ASM нужно делать бекап. Вероятность выхода массива из строя есть всегда.
Верните Волкову Oracle! Верните Oracle Волкова!
ОтветитьУдалитьПо сжатию - тесты на реальной базе заказчика показали результаты сжатия от 7 до 15 раз в зависимости от типа данных. Средняя температура по больнице составила 11 градусов. Это факт.
ОтветитьУдалить>Один Alex ошибся в рассчетах, Как правильно считать, объяснил второй Alex
ОтветитьУдалитьОба Alex считают правильно. 41% процент вероятности потери данных при выходе из строя второго диска. Alex второй делает вывод по Google какая вероятности выхода из строя дисков одной партии, но не учитывает что диски стоят в одной коробке при одной температуре. Это разные цифры. Я мог бы долго про это писать - но проще всего поверить Oracle Dev который рекомендует делать тройное зеркалирование.
>Верните Волкову Oracle
все 15% моих акций пожалуйста
>Средняя температура по больнице составила 11 градусов. Это факт
Грамотно. Технически аргументировано. Совершенно анонимно. Я верю вам.
> у Exadata вполне могут быть проблемы с OLTP нагрузкой потому что redo logs...лежат вместе с данными и 512Mb кэша обычного диска не хватает
ОтветитьУдалитьВо-первых, у Exadata - 512MByte кэш на каждые 12 дисков (7 гигабайт на 168 дискова в конфигурации Full Rack).
Во-вторых, Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.
В-третьих, проблемы не сущестует. Тот факт, что Oracle Dev добавил функционал Smart Flash Log - не есть признание какой-либо проблемы. Это естественный шаг по использованию дополнительного уровня СХД - в аварийной ситуации, при недоступности кэша, это может спасти производительность Экзадаты.
>проблемы не сущестует. Тот факт, что Oracle Dev добавил функционал
ОтветитьУдалитьВы по ссылке ходили ? График видели ? Страус тоже закапывается в песок и проблемы не существует.
>Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.
Аллилуйя ! IBM вообще рядом не стояла. До сих пор делают дисковые массивы размером со шкаф. Другое дело - JBOD из обычных дисков -))))
2 Dmitry Volkov
ОтветитьУдалить> Вы по ссылке ходили ? График видели ? Страус тоже закапывается в песок и проблемы не существует.
График совершенно справедливо показывает, что флэш быстрее дисков - в той самой аварийной ситуации, когда кэш недосупен.
Разработчики Оракла просто добавили более оптимальную обработку аварийной ситуации: если кэша нет, пусть уж лучше лог идет на флэш, а не диски.
>>Exadata Storage Servers - это СХД под СУБД Oracle, с производительностью значительно лучшей, чем все что могут предложить EMC или HDS, не говоря уже об IBM.
> Аллилуйя ! IBM вообще рядом не стояла. До сих пор делают дисковые массивы размером со шкаф. Другое дело - JBOD из обычных дисков -))))
У всех производителей используются одни и те же диски. Но используются по-разному. В Экзадате диски используются оптимальным для СУБД Оракл способом. И там, конечно же, не JBOD-ы, а контоллерные полки, если полки, если проводить аналогии с традиционными СХД.
А уж IBM в смысле СХД и впрямь рядом не стояла.
>В-третьих, проблемы не сущестует
ОтветитьУдалить>просто добавили более оптимальную обработку аварийной ситуации
Вы сами-то помните что сказали 5 минут назад ?
Волкова назад в Oracle!
ОтветитьУдалитьЧто он вообще в IBM делает?
> Что он вообще в IBM делает?
ОтветитьУдалитьЯ занимаюсь Oracle Database, в частности вопросами perfomance, tuning, best practices for AIX.
Дим, пока ты освещал OOW, ты был объективен, а сейчас IBM' ские уши полезли. Не айс. :-)
ОтветитьУдалить> сейчас IBM' ские уши полезли
ОтветитьУдалитьЗнаю что ходить по ссылкам не барское дело, но откройте для себя Alex Fatkulin, Jonathan Lewis и Mark Fielding. Это супер объективные парни.
2 Dmitry Volkov
ОтветитьУдалить>>В-третьих, проблемы не сущестует
>>просто добавили более оптимальную обработку аварийной ситуации
> Вы сами-то помните что сказали 5 минут назад ?
Да, Дмитрий, я помню, что я говорю.
А вот вы пытаетесь выдать желаемое за действительно - что оптимизация обработки аварийной ситуации, есть призанание наличие проблемы.
А проблемы нет. Кэш Экзадаты не переполняется, как бы вам в IBM этого бы не хотелось.
>Кэш Экзадаты не переполняется
ОтветитьУдалитьВот только 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
ОтветитьУдалить> 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". В Оракле Марк не работает, так что пусть предполагает, что хочет. Кэш Экзадаты от его, и тем более, от ваших, предположений не переполнится.
Вы же вообще о существовании кэша в Экзадате от меня узнали совсем недавно. Но сразу же развели теоретизирование. Однако, у вас лишь предположения, а у нас знания, подкрепленные практикой.
>На слайде #30 приведен график, где сравнивается скорость дисков без кэша и флэша. И все.
ОтветитьУдалитьПравда ? Вы были на презентации ? А Marc Fielding был - я с ним разговаривал и мы обсуждали этот момент.
>Вы же вообще о существовании кэша в Экзадате от меня узнали совсем недавно
Папа ? Мама ? сколько раз я просил вас не комментировать ничего в моем блоге ..-))
Спасибо что вспомнили этот случай. Вот пост про который идет речь
http://dsvolk.blogspot.com/2011/07/exadata-better-than-emc.html
Ваша цитата:
"
Exadata User комментирует...
Также, Вы не знаете, что кэш в контроллере, который на самом диске, на запись отключен - так делается в любом нормальном дисковом массиве, или сервере
"
Вы написали что кэш отключен. После чего пишите мне что я от вас узнал про существование кэша. Это достойно.
>В Оракле Марк не работает, так что пусть предполагает, что хочет
Теперь понятно. Вы делите людей на тех кто работает в Oracle и всех прочих ламеров. Это ваше право. Надеюсь заказчики оценят ваше высказывание.
>у нас знания, подкрепленные практикой.
У вас, это у кого ? у серых ников ? Вы даже подписаться боитесь.
Я думаю что можно закончить. Ваша позиция более чем понятна, и мы пошли по кругу. Читатели могут сами рассудить где правда.
>> Также, Вы не знаете, что кэш в контроллере, который на самом диске, на запись отключен - так делается в любом нормальном дисковом массиве, или сервере
ОтветитьУдалить"
> Вы написали что кэш отключен. После чего пишите мне что я от вас узнал про существование кэша.
Дмитрий - на самом диске, есть свой собвственный контролле, со своим собственным кэшем, мегов этак до 64. И вот он отключен.
>>В Оракле Марк не работает, так что пусть предполагает, что хочет
> Теперь понятно. Вы делите людей на тех кто работает в Oracle и всех прочих ламеров.
Нет. Вы приписали предположения Марка - разработчикам Оракла. Будто бы они сообщили о переполняющемся кэше. Ничего подобного не было.
очевидно, что не работающий в оракле дима действительно отождествляет две принципиально разные сущности - какого-то чувака и Oracle development. очевидно, что чувак не при делах (как и дима), рядом с мопедом даже близко не стоял, и попытка выдать его слова за мнение Oracle development есть ни что иное как вопиющее пренебрежение известным принципом "после этого не значит вследствие этого" и классическое размещение об'явы.
ОтветитьУдалитьranger.
ps. ненавижу айфон за отсутствие твердого знака, а русский язык - за его наличие.
pps. ods - one developer said. вот вероятный источник информации :-) чтож, тебя можно понять :-)
впрочем, так как дима суть есть типичный мимо проходил-кун - то и
поведение оное следует признать более яем нормальным.
>что не работающий в оракле ..две принципиально разные сущности - какого-то чувака
ОтветитьУдалитьЭтот 'какой-то чувак' ведущий технический эксперт в компании партнере Oracle, которая на OpenWorld получила Titan Award (в том числе) за поддержку клиента на Exadata. Все было бы ничего, но ты высказываешь явное пренебрежение только на основании факта что он не работает в Oracle. Со стороны сотрудника support организации такое отношение к клиентам и партнерам доставляет
Теперь о главном. Ты не отрицаешь факта что 'какой-то чувак' прав. Нет. Ты не даешь другого объяснения происходящему на графике. Тоже нет. Ты пытаешь скомпрометировать человека высказывая сомнения что не может знать про это.
я его не знаю. ни лично, ни еще как. поэтому "какой-то чувак" меня вполне устраивает. some dude. that's it.
ОтветитьУдалитьдалее, по поводу явного пренебрежения: именно его я и высказываю, правда, я уже усомнился - в адрес того ли чувака я его высказываю, ибо я задумался о том, что вроде бы фразу этого чувака с графиком не его авторства из презентации не его, опять же, авторства, связал (выдав это за мнение "oracle dev") какой-то другой чувак :)
в любом случае - я волен высказывать оное пренебрежение, хочешь ты того или нет :)
> Теперь о главном. Ты не отрицаешь факта что 'какой-то чувак' прав. Нет.
> Ты не даешь другого объяснения происходящему на графике. Тоже нет.
> Ты пытаешь скомпрометировать человека высказывая сомнения что не
> может знать про это.
да я вообще про экзадату не говорю, и про графики тоже :D я знать не знаю, в чем там дело, ибо экзадатой не занимаюсь - мне "традиционных" кластеров хватает :D хотя то, с чем я работаю, далеко не всегда язык повернется назвать "традиционными" :D
я утверждаю лишь, что не работая в oracle development утверждать что-либо от ее имени и даже просто со ссылкой на нее - это, по меньшей мере, самонадеянно (надеюсь, я достаточно мягко выразился). другой вопрос - если ты мог бы дать ссылку на какой-нибудь ресурс авторства "oracle dev" (а уж я подлинность я проверю, не сомневайся :)) в котором заявляется возможность переполнения кэша и соответствие этих моментов каким-то пикам на каких-то графиках...
компрометировать я никого не собираюсь, и ни в коем разе не высказываю сомнений в том, что человек "может не знать про это" (кстати - про это - это про то, что oracle dev не заявлял что кэш экзадаты не может переполняться? :)
что до твоих методов ведения дискуссии - они типично женские: это называется "подмена тезиса". вроде бы все хорошо, и вдруг раз - мы разговариваем на другую тему :) и, оказывается, я кого-то пытаюсь скомпрометировать, да еще мне какое-то отношение предъявляют. trololo.
ranger.
> объяснения происходящему на графике
ОтветитьУдалитьНа графике происходит то, что бывает при отключении кэша на запись в аварийной ситуации: либо батарейка кэш-памяти сдохла, либо пошли ошибки на модулях памяти кэша. В этих ситуациях кэш на запись автоматически отключается.
>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
>а уж я подлинность я проверю, не сомневайся
Начинай проверять
скучно. опять подмена тезиса.
ОтветитьУдалитьсоскок с темы засчитан.
ranger.
ps. а "спасибо" - это за то, что экзадатой не занимаюсь? :) право, не стоит - это осознанный выбор, хотя в экзадата-тиме вакансии есть, не проблема.
>На графике происходит то, что бывает при отключении кэша на запись в аварийной ситуации:
ОтветитьУдалитьКонечно нет. Читать здесь http://www.oracle.com/technetwork/database/exadata/exadata-smart-flash-cache-366203.pdf
стр 8
Цитата оттуда есть выше.
>соскок с темы засчитан.
ОтветитьУдалитьranger,
В чем для тебя была тема ?
Ты сам написал
"я знать не знаю, в чем там дело, ибо экзадатой не занимаюсь"
не дал никаких комментариев по графику, не дал ни одного своего объяснения.
Ты написал что "что не работая в oracle development утверждать что-либо от ее имени и даже просто со ссылкой на нее"
Святая Инквизиция ! Те уже нельзя ссылать на публичную презентацию и комментировать ее ?
Это доставляет. Тебе бы в PR пойти работать. Тогда ты бы ты всех построил как надо.
Будь конкретней. Есть что скать по теме поста - welcome. А нет - ...ну ты понял -)