OOW 2014. Day 3.

Если вы архитектор, или руководитель IT любого уровня, обязательно посмотрите видео John Fowler 'Real-Time Enterprise'. John говорит медленно и очень понятно, раскладывает по полочкам,  что сделал Oracle и почему это круто, достаточно техническим языком, который в тоже время  легко адаптировать для бизнеса.

Однако, самое интересное начинается с 39:30. Если до этого  John говорил о multitenant, и бизнес преимуществах этой опции,  то тут он внезапно обнаружил, что после того как вы сложили 200 баз данных на один хост,  определить кто оказывает какую нагрузку на I/O,  не представляется возможным. Для массива EMC это нагрузка с хоста, и все. С одного хоста.  Шах и мат, администраторы массива!

Но вам беспокоится не нужно, Oracle уже работает над этим, и новый ZFS Appliance будет позволять вам видеть прямо привязку I/O к имени БД. А массив EMC давно нужно было сдать у утиль истории.

Немного подумав, John также обнаружил, что раз теперь у вас 200 баз данных, кто какими там права обладает неясно, и, при не очень больших ухищрениях, везении, и сопутствующих багах,   можно будет получить доступ к общей памяти..в которой совершенно чужие вам данные. Особенно если это In-Memory pool….Не волнуйтесь, новый SPARC M7  процессор будет понимать, к какой памяти давать доступ какому SQL, а к какой не давать.

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

На фотографии, лишь некоторые из эмоций которые вы испытаете начиная с 39:30…-)


Читать дальше...

OOW 2014. Day 2. General Session Database.

General Session - Database, Andy Mendelsohn, EVP of Database Server Technologies . Запись можно смотреть тут.

Конечно же очень интересно, что будет происходить в сфере Database и Engineering Systems. В прошлые годы можно было услышать над чем идет работа, чего стоит ожидать. В этом году ограничились повторением уже сделанного. Так что если вы менеджер и не имели возможности следить за всеми новинками - смело смотрите, вам будет интересно. Прочим могу рекомендовать только как курс английского языка. Ну или посмотреть демонстрацию, начинающаяся с примерно в 50:30 как объединить данные в СУБД и Hadoop - ее можно посмотреть, и наглядно, и много времени не займет.

PS Где то в середине сесси, есть интервью с аналитиком Gartner, который говорит, что In-Memory это экономия денег, так как удастся загрузить сервер больше. Я конечно же, не хотел бы с ним спорить, но он не прав. Не научились люди еще загружать сервера загрузкой равномерно все 24 часа. На практике будут пики, из-за которых придется купить еще больше лицензий.  Хотя я и  понимаю, что с такой позицией слона не продашь, и он поэтому аналитик в Gartner, а я пишу в бложик -))


Читать дальше...

OOW 2014. Day 2.

В этот день выступал Ларри, уже в роли CTO. Сам (!) показал демонстрацию, даже несколько. Все это не может не вызывать восхищения. Не знаю, насколько его хватит, чтобы играться с кнопочками, но он все равно молодец.

Сама выступление вот тут.

Ларри показывал как легко и просто переместить БД в cloud. Совершенно внезапно оказалось, что есть такая возможность как transportable database, которая превращает БД в набор файлов, которые затем присоединяют к уже существующей CDB в клауде. Все заняло меньше 10 минут.
Оченвидно у заказчика уже должна бы 12c, крайне желательно на Linux, и желательно небольшая чтобы ее можно было залить по http. Amazon честно понимает, что некоторые объемы нельзя залить по http и пишет что вы можете привезти к нам диски. Я пока такой опции у Oracle не видел. Еще бы конечно хотелось бы создать там не новую базу, а standby чтобы догнать потихонечку с production  - наверное все предусмотрено, я просто не разглядел.

Какое время было посвещено дискуссии чем Oracle лучше остальных cloud провайдеров. Почему то основное время сравнивали с SalesForce. Это негодяи взяли базу данных Oracle в качестве основы, но потом сами написали вокруг тучу приложений и API чтобы заказчикам было удобно. Oracle развивает в cloud только свои приложения, кошерные.  Я бы и дальше ерничал по этому поводу, но поскольку все это к России в связи с необходимостью хранить персональные данные (а согласно букве закона это вообще все данные) нужно только в России, смысла это не имеет.  Соглашусь однако, что архитектурно, у Oracle все очень красиво, молодцы!


В завершении всем показали Big Data SQL, объявленный ранее. Я про него уже писал.  Оказалось, что если взять open source код, то в руках Oracle он будет работать сильно быстрее. Планы, конечно громадные, обучить big data делать smart scan, но пока это планы. Вещь и без сомнения, переспективная технология.


Стоил ли смотреть Ларри? Ларри всегда стоит смотреть - просто от этой презентации не стоит ждать открытий.


Читать дальше...

OOW 2014. Day 1.

Прямо перед OOW было объявлено что Ларри уходит. Однако многие не дочитали, что он решил заняться наконец тем, что любит - сосредоточится на технической части и стал Chief Technology Officer (CTO). Что же может себе позволить заняться любимым делом -)

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

Что же было объявлено:

 Теперь Можно будет получить виртуальную машину Oracle VM и ssh доступ к ней как root. Что такое Database Service я не понял, но согласно этой ссылке, это набор опций Enterprise Edition который вам насыпят. Цена? Не знаю, если кто напишет, я обновлю  пост.


Zero Data Loss Recovery Appliance.  Этот продукт уже объявляли в прошлом году, Ларри просто забыл (шутка). Хитрый standby который работает сразу со обоими типами bit endianness и куда необходимо направить ваши логи в real time режиме. И дальше, о чудо, можно даже делать инкрементальные backup. Насколько я понял, уникальная там только технология Delta push, которая позволяет вам сделать full backup только один раз в жизни, а затем постоянно делать incremental. Мое мнение - я все могу сделать тоже самое, просто геморроя будет много. Найдутся большие конторы которые просто купят эту коробочку, чтобы забыть про проблему.


Самые громкое объявление - Flash Storage от Oracle.

Мне очень понравилось что он поддерживает Hybrid Columnar compression и там очень много места, и автоматический tiering.
Надо брать. Правда, в спецификации, самого Flash я не нашел - есть SSD и обычные диски. Но это я придираюсь, конечно же. Привычка.


Exalytics - почти два года разрабатывали свой софт для In-Memory, теперь решили что это не нужно и заменили его на обычную 12c в которой уже есть In-Memory.
Разумное решение, хотя и команда разработчиков наверно осталось не очень довольна. Бизнес, ничего личного.





Последнее в списке объявление - SPARC M7. Достойно отдельной темы, слишком уж там много слоев маркетинга. Отмечу, что Ларри сказал что команда SPARC очень плотно работает с Intel чтобы … рассказать им что они делают в SPARC.  В общем, если конкуренции с IBM больше нет, то и смысла упираться в SPARC тоже нет.


Читать дальше...

12 Looks at Oracle Database 12c - my own about In-Memory

I did not manage to visit Oracle Open World this year, but I've took part in very exciting program, which called 12 looks at Oracle Database 12c.

Please find my presentation regarding In-Memory option, or, more specifically, architecture approach you should follow to successfully implement Oracle In-Memory.

I found, that for real world implementation Oracle Engineering system would be required. Even though price could be a issue for a such implementation,  I believe i could be managed during initial sales conversation with Oracle representative, having in my total cost of solution (Enterprise Edition, RAC, Partitioning, In-Memory).

Have a look!

PS Hmm..I have a vide too…but its too funny to share it with you…-)

Update 1.

In my presentation above I made a suggestion that Exadata should have the same format as In-Memore. Below is a slide, that in Flash data will be in two formats. It will possible soon to have true memory hierarchy between DRAM, Flash and spindle drives (soon, I hope) - data will be compressed everywhere in the same manner.




Читать дальше...

How to find a good job. Part 2.

Первая часть.  Я решил оставить на сладкое еще один мега-вопрос: 'кем вы видите себя через 5 лет?'. Если это вопрос задается вам на собеседовании большим начальником, гуру SQL.ru рекомендуют отвечать - 'я вижу себя на вашем месте'.  Прекрасный ответ, если вам не очень нравится эта компания -)

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


Читать дальше...

Oracle Database In-Memory. Part 4.

Решил написать о некоторых занятных  публикациях, которые появились в последнее время в области In-Memory. По большей части они касаются лицензирования.

Kevin Closson нашел занятный баг, при котором, если вы обновили свою СУБД до версии 12.1.0.2 и просто выдали команду на создание таблицы

create table <>  inmemory

вместо ошибки, таблица создается, но вот что действительно плохо, Oracle начинает считать, что вы использовали In-Memory опцию, а поэтому пора бы и заплатить.

Почему я ожидал бы ошибку? По умолчанию, параметр INMEMORY_SIZE равен 0 - поэтому, разумно было бы ожидать ошибку, ведь мы не выделили место (память)  под таблицу. Но вот, что путает, так то  что существует отдельный параметр INMEMORY_QUERY, по умолчанию TRUE. Так вот похоже, что если INMEMORY_QUERY=TRUE Oracle начинает считать, что опция использовалась несмотря на значение параметра  INMEMORY_SIZE. Кстати, если, вы запустите (просто запустите!)  СУБД c  INMEMORY_SIZE >0 - вы также начали использовать опцию In-Memory. Итого, совет, если вы не готовы закупаться лицензиями - установите параметр INMEMORY_QUERY = FALSE.

Oracle даже написал разгромную статью, что Kevin не прав -), что не помешало завести bug  -)

James Morle написал архитектурного рода пост, где в том числе, делается вывод, что помимо платы собственно за In-Memory, все ошибки проектирования вашего приложения, вместо того, чтобы оставаться в области ввода-вывода, перейдут на память, а следовательно, вам придется закупить больше CPU. Сами процессоры (x86) относительно дешевы, но вот процессорные лицензии Oracle на них - не очень. Покупая новые процессоры, вы не только заплатите за новые лицензии но и скорее, всего уйдете за возможности 2 сокетного бокса, а с ростом числа сокетов, вы попадете в ловушку с  NUMA архитектурой - доступ к памяти, расположенной на других сокетах дороже доступа к памяти локального сокета.

Интересно, что похожа идея 2-х  сокетных боксов соединенных между собой Infiniband, начинает  побеждать - IBM, который не особенно поддерживал (ok, своеобразно поддерживал)  Infiniband на Power и AIX, решил добавить поддержку Infiniband в свое cloud решение SoftLayer.  Идея небольших коробочек, из 2 или 4-х сокетов соединенных Infiniband начинает завоевывать умы людей. Что интересно, это в точности модель hi-end серверов Power 770/7780/795 -))  с тем отличием, что у hi-enf  общая память организуется на аппаратном уровне, в то время как  у отдельных коробочек на уровне программного обеспечения (Oracle RAC).  Ужасная latency (по сравнению с аппаратным решением), необходимость адаптировать приложение - ничего не останавливает людей - все хотят россыпь маленьких серверов. Это прекрасно - учите RAC и всегда будете получать хорошую зарплату -)


Читать дальше...

Intel Designs Custom Chip for Oracle Exadata

На днях наткнулся на фантастическое сообщение от Intel: "This customized version of the Intel Xeon processor E7 v2, developed in collaboration with Oracle, helps maximize the power of the Exadata Database Machine X4-8 .." 

Как не сложно заметить тут две новости: вышла Exadata X4-8 и, как может показаться на первый взгляд, какой то специально модернизированный chip Intel для нее! Фантастика, надо разобраться! 


Нет лучше источника информации,  чем официальный пресс релиз Oracle откуда мы узнаем:


'

For the database compute nodes, Exadata Database Machine X4-8 uses the Intel® Xeon® E7-8895 v2, an optimized 15-core microprocessor that elastically scales frequency and number of active cores to help deliver peak workload performance.
'


Динамически меняет число активных ядер! Может можно теперь платить меньше, если используешь меньше ядер?  Одно просмотр спецификации процессора E7-8895 на сайте Intel показывает только так называемые C-State - когда ядру нечего делать, процессор может его потихоньку переводить в спящее состояние, чтобы экономить электроэнергию. Таким образом, число ядер остается постоянным в системе. К сожалению, никак сэкономить эта технология не поможет. 






Вторая часть, связанная с динамическим увеличением частоты более интересная: Как видно, если на целое ядро у нас нашлась только одна задачка, то выполняться она будет на частоте 3.6HGz. Как только задачек станет больше, частота будет понижаться,  дополнительные ядра будут переводиться в активное состояние.



Прекрасные технологии Intel, полезные и приятные на ощупь. Intel сокращает отставание от IBM Power, значительно обгоняя в маркетинге. Как вы видите, ничего специального для Exadata в этом чипе нет, но для обеих компаний это прекрасный информационный повод еще раз напомнить о стратегическом сотрудничестве.   


Intel также анонсировал что '  Intel has cooked up a hybrid chip that bolts a Field-Programmable Gate Array onto its high-end Xeon E5 server chip'. Технология FPGA уже есть в Power 8, и ее теоретически можно было бы использовать для обработки данных на низком уровне, как это делает Netezza. Но IBM, по крайней мере пока, этого не сделал. Вот если Oracle применит эту технологию в Exadata cells это будет бомба. Но мое предсказание - это не случиться еще по крайне мере несколько лет. 


Читать дальше...

Oracle In-Memory is here!

С сегодняшнего дня Oracle 12.1.0.2 доступен для скачивания, а значит мы все имеем возможность прикоснуться к официальной документации и посмотреть, что из

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

Если вам интересна именно In-Memory еще раз рекоменду вам blog Maria Colgan.

Поскольку 12.1.0.2 это полноценный pathset, кроме ожидаемой In-Memory он содержит  несколько интересных вещей, таких как Automatic Big Table Caching, Full Database Caching, Zone Maps. Прочитать о них можно в  New Features.

Update 1.

Одно можно сказать точно на данный момент: стоимость In-Memory равна $23K USD на Процессор, или, вместе с опцией RAC это дает удвоение стоимости лицензии Enterprise Edition.





Читать дальше...

How to find a good job. Part 1.

Я решил начать серию постов о поиске работы. Материалов об этом вагон, но не все советы применимы именно к IT. Я постараюсь писать о специфике, связанной именно с Oracle.

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

Итак, у вас есть резюме, вы даже его где то разместили, и вам позвонили и пригласили на встречу. Вы по новому для вас адресу, нервничаете, что можете опоздать, и пытаетесь судорожно вспомнить команды rman. Наконец, с 10 минутным опоздаем вы прорываетесь через охрану, вас сажают в кабинет, вы видите свою резюме с обаятельной дамы, сидящей напротив вас, думаете "ну она то уж точно меня не завалит вопросами про rman" как неожиданно она вас спрашивает - "расскажите о себе".


Читать дальше...

IBM + Apple

Ну что за месяц, что ни день, то потрясающие новости: 




Официальный press release: "..IBM will also sell iPhones and iPads..". Представляете себе запрос заказчика: "2 Power 795 и 4 IPad пожалуйста".  И комментарии  бухгалтерии 'в этом заказе вычеркнем 1 IPad для уменьшения цены'. 


Тут парень прочитал и прокомментировал press release. Смешно получилось. 


Читать дальше...

Oracle Big Data SQL

Наконец-то все поняли, что нет никакого смысла в 10 десятке разных языков, один другого смешнее, pig, fig, hruk, impala-la-la, и что можно обойтись просто SQL.

Сегодня большой день - Oracle объявил о Big Data SQL. Вы сможете увидеть свои Big Data данные как (внешние) таблицы в Oracle. Просто напишите select - и загрузите данные из Twitter. Кто-то должен был сказать Twitter, чтобы они это сделали, но сделал это Oracle. Спасибо. Уф. Теперь на вопрос - знаю ли я что такое Big Data я буду с чистой совестью отвечать что уже 20 лет как -)



Судя по Data Sheet, можно предположить, что Oracle доработал обертку над Hive.  Сделал так, чтобы Hive металанные доехали до СУБД и там выглядели как таблицы. Красиво. Картинка справа нарисована Product Manager и похоже ему есть куда развивать свое умение рисовать -)



По дороге, опять таки, прикрутили Storage Indexes, как пишут,  прямо на стороне Hadoop.

Открытый вопрос - нужна ли Exadata на стороне СУБД - похоже,  что технически нет,
не нужна, но возможно внесут какие то ограничения, чтобы она была необходима. Пока надо подождать.

Посмотреть анонс. (не технический, как что работает из анонса непонятно)

Цитата: "Oracle Big Data SQL will be generally available in 3Q 2014"

Update 1. Хорошая картинка, из нее чуть больше понятно, что будет происходить. И этот блог пост также хорош.




Читать дальше...

ASH - it is a time to rethink what is inside

Пост обновлен  18.07.2014

После публикации первого поста о возможности анализа данных ASH с помощью Tableao, я получил весьма смешной комментарий, что я открыл для себя ASH. Помимо того, что это правда, такое же открытие в этом году сделали и некоторые весьма уважаемые сотрудники Oracle.

Убедительно прошу вас просмотреть одну из лучших презентаций на тему ASH, сделанную в этом году на RMOUG. (на секундочку, это rocky montains oracle users group, и вообще то материалы доступны только участникам. Но поскольку именно эта презентация сделана сотрудниками Oracle, ее выложили. Кстати, если посмотреть на сайт rmoug сразу понятно как должна выглядеть Users Group).

В презентации много интересного, но самое вкусное начинается после слайда "The ASH Fix-up Mechanism". Там рассказывается, как посчитать правильно latency. Большинство людей предполагало, что это avg (time_waited) where time_waited > 0 и можно найти даже книги по Oracle performance с такой формулой.


Все очень просто - запускаем SwingBench, где soe tablespace находится на отдельном устройстве и попробуем определить latency для db file sequential read.

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

>iostat -xkd 1 | awk '{ if ($1 != "" &&  $1!="Device:" && $1!="Linux") print strftime("%d/%m/%y %H:%M:%S",systime()),$1,$11 | "tee  iostat.dat" ;}'
и после окончания нагрузки 
>grep sde iostat.dat  | awk '{sum+=$4} END { print "Average = ",sum/NR}'


Результат - 2.6 ms

Теперь AWR - 2 ms. хо-хо - база данных считает, что она читала быстрее чем отдавал диск. Есть несколько объяснений, почему может быть такое, но в целом данные сходятся.






 Тестируем магическую формулу из презентации


Точнее, чем AWR - что не удивительно, поскольку в ASH просто больше данных.

Ну и наконец, посмотрим что нам дает нерекомендованный способ:

Update 1. Это конечно же 5.4 ms. - у меня плохо с операциями деления.


Фантастические данные, но к сожалению не имеющие отношения к реальности.

Мне сложно прямо сходу назвать причину, но если рассмотреть сырые данные, то можно увидеть, что только 1 из многих записей имеет реальное значение порядка 1.6 ms.






В комментариях Игорь обратил внимание что максимум -  1.6 sec, минимум 4.6 ms. Понятно, что одна операция ввода-вывода не может длиться 1 sec - у меня локальные ssd диски. С другой стороны, если это было чтение индекса, операций было много, время которое было затрачено, проставлено только в последней - тогда вроде бы все встает на свои места. Число операций, которые в сумме дали нам 1.6 остается нам неизвестным, посколько были очень короткие, и sample на них просто не попали.



Согласно описанию, по крайне мере как я его понимаю, поскольку все чтения диска длятся очевидно меньше 1 s, time_waited отражает просто момент времени на который пришелся sample. Фактически, мы получим все возможные распределения от 0 до 2.6 ms (которое,  по видимому, отражает реальность).


Вот еще картинка из dba_hist_event_histogram. Oracle считает что да, были события по 2 ms.

Пусть очень мало, но все таки было. Хотя мне кажется, что это что то с аккуратностью сбора  статистики.












PS
Я  разговаривал с одним DBA, который занимается исключительно performance tuning в своей  компании. Так вот, вся команда PT не имеет доступа к production systems. Они могут только запрашивать данные, на основании которых давать свое заключение. Честно говоря, первый раз о таком услышал, что внутри компании такие ограничения. Но вот эта группа не очень чувствует чем им может помочь ASH - они больше ориентируются на AWR, что явно не лучший способ в наше время!


Читать дальше...

Using Tableau for Oracle Performance analysis. Part 1.

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

Популярное сейчас решение - попросить AWR и ставить диагноз по нему. Тут есть несколько проблем.
  1. AWR содержит тексты SQL запросов - был случай,  когда мне сказали что это секретная информация
  2. AWR собирается с какой то частой, по умолчанию 1 раз в час, и чаще всего, вместе с проблемным участком попадает и нормальный. Данные получаются размытыми.
  3. Можно сделать  снимок (snapshot)  до начала проблемы и после, и сделать отчет между двумя этими снимками - но, встречаются случаи, когда это не очевидное действие для администраторов. 
  4. Данные в AWR представлены в виде среднего по больнице. 40% база данных тратила на ввод-вывод, можно по Top SQL догадаться кто виноват (найти sql) но восстановить общую картинку, как чувствует себя тот или иной бизнес модуль, даже если код хорошо инструментирован, весьма сложно. 
  5. Приходится писать много текста, который мало кто любит читать - все любят картинки. 
Не менее популярно (по крайне мере, было) написание своих скриптов для сбора нужной вам информации. Это отдельная песня - элементарно не разрешают, на основании того, что эти ваши скрипты погубят систему. 

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


Читать дальше...

RuOUG


Я, как и все зарегистрированные участки RuOUG, получил письмо от администрации о том, что не все ладно в датском королевстве, и цитата, 'деятельность стала пробуксовывать'

Я хочу напомнить, что RuOUG  был создан Андреем Криушиным и Евгением Горбоконенко в 2009 году ( и я прошу вас перечитать исторический пост Сергея Данилова на эту тему).

Деятельность различных user groups в первую очередь выгодна самой компании Oracle - ведь энтузиасты, собираясь и обсуждая, развивают технологии, причем совершенно бесплатно!

Мне кажется совершенно естественным, что в тяжелое время компания должна помочь и поддержать RuOUG. Возможно что-то делается уже, я не знаю, но пока я вижу, что комания продолжает тратить деньги на мероприятия в стиле <Что-то там>  Пиво" - спору нет, мероприятия наверное интересные. Наверное,  но с последнего даже презентаций нет в открытом доступе.

Update 1. Прислали ссылку на последнее мероприятие Oracle DB Community Day. Предыдущее было ровно год назад. 

Второе, собраться один раз в ресторане компанией людей которые смогли прийти в этот день совсем не то, что поддерживать регулярные события на протяжении года. Если найдутся деньги на оба формата - супер, больше форматов больших и разных.  Нужно помещение. Нужно скромно,  но покормить. Почему бы не заплатить, тем кто выступает? Это для начала, когда паровоз разгонится можно будет брать деньги за билеты -)

В общем я надеюсь, что Oracle поможет. Что скажете? У вас есть еще мысли?

Update 2. Посмотрите видео, 30 сек. Точки зрения бывают разные, чтобы понять картинку нужно суметь выслушать все.  Пока коллеги из Oracle никак не прокомментировали. Это нормально. Попробую задать вопрос по другому: почему бы эти замечательные мероприятия (и Пивы и DB Community Day) не проводить в рамках Users Group? Ведь для этого она и существует  - для объединения людей в community. Это сильно помогло бы, на моей взгляд. Что скажете?




Читать дальше...

Oracle Database In-Memory. Part 3

Потихоньку начинаются публикации людей которые успели попробовать (очевидно в b-версии) In-Memory. Во первых блог Maria Colgan (мне кажется она product manager по этому направлению, но она супер технический product manager).


'If a query is looking up a small number of records (rows), and an index on the WHERE clause column exists, the Optimizer will select an index access path (via the buffer cache), as this execution plan will be both more efficient (lowest cost) and more scalable in a multi-user environment.'

Маленький звоночек, more scalable in multiuser enviroment  - это интересно. Очевидно, если сотни   пользователей OLTP меняют данные, очень тяжело успеть в real time менять их в In-Memory виде.

'..By placing that Materialized View in-memory.. '

Ох, это здорово, те все таки In-Memory будет работать с Mat View как я надеялся здесь.

Другой блог, насколько я понял одного из администраторов Turkcell, который взял Swingbench и посмотрел как будет работать  нагрузка Warehouse. Гениальная идея кстати.

Длинный пост достаточно у него. Попробую повторить его выводы, напутав и переврав.

1. Hash Join + Index Fast Full Scan не удалось победить, время выполнения традиционного запроса и In-Memory одинаково.

2. Как только подключается фильтрование данных, In_Memory выигрывает за счет bloom фильтров, в 5-7 раз легко.

Тестирование проводилось в режиме single user.

Update 1. Прекрасная презентация Игоря Мельникова про In-Memory - там же есть тесты. Вывод, что In_Memory особенно хороша когда есть фильтрация данных подтверждается. 


Читать дальше...

ASH Analitics

В 12с  Enterprise Manager Database Console переименовали  в Enterprise Manager Database Express 12c, но вот что здорово, то что ASH Analitics можно воспользоваться из EM Express и никакого Сloud Сontrol не надо!

ASH Analtics анонсировали еще в 2011 году - вот оригинальная презентация.

Для начала найдем по какому порту слушает EM Express:


[oracle@oradb12c admin]$ lsnrctl status | grep HTTP

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=oradb12c)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/DB12c/xdb_wallet))(Presentation=HTTP)(Session=RAW))

Дальше попадаем в интерфейс (указываем логин пароль пользователя БД,  я указал sys)




Волшебство начинается после выбора Performance-> Performance Hub






Вот как это выглядит:


Классическая картинка - прямо как была на презентации Oracle 2011 года.


Что же со всем этим счастьем можно делать? Предположим, что меня волнует загрузка CPU, для этого я указал фильтр Wait Event: CPU + Wait for CPU и тут же получил набор SQL_ID, да еще и с временами когда они запускались.

























Дальше я выбрал sql_id (левый нижный угол экрана) и получил его текст, статистику, имя пользователя (SOE) и Plan Hash Value.






Дальше можно получить план выполнения с очень красивой графикой стоимости каждого шага. Также можно построить карту выполнения, если кому-то такое представлением кажется понятнее.

Не отходя от кассы, можно тут же запустить задание на оптимизация SQL.

Мне очень понравилось:  все очень красиво и понятно. Какой sql_id  когда ожидал какого события ожидания, кто и когда запускал этот sql. В реальном режиме времени. Ничего ставить или знать для этого не нужно. Простота и гениальность.

У меня есть подозрение что в Cloud Control интерфейс чуть отличается, но я пока не имел возможности сравнить оба.


Некоторые примеры как использовать ASH Analitics  можно также найти здесь:
http://dbakevlar.com/2014/04/ash-analytics-tracking-down-an-issue-part-i/


Читать дальше...

Goodbye America

В выходные, между просмотром футбольных матчей, можно немного расслабится и прочитать статью Cnews о планах электронного правительства по отказу от проприетарных решений американский компаний: Oracle, IBM, Microsoft. Сама статья  называется 'Прощай Америка' - поэтому я решил также назвать и этот пост.  В статье утверждается, что будут проводить общественные слушания перед окончательным принятием решения, а значит у нас есть право и шанс как то воздействовать на результат.

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

Update 1. Мы делаем процессор Bailkal!  Портируем на него Postgre SQL и национальная инфраструктура готова!


Читать дальше...

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 знать ничего не нужно -)



Читать дальше...

Oracle Multitenant. Part 2

Итак, мы собираемся проводить консолидацию баз данных с помошью Multitenant (CDB).   Для этого нам нужно посчитать сколько нам понадобиться ввода-вывода (I/O), памяти (Memory), и процессорных ресурсов (CPUs), учесть дополнительные расходы и каким то образом просчитать распределение ресурсов между PDB. Простейший способ - сложить все ресурсы математически лишает смысла консолидацию: мы знаем что чем больше сервер, тем он стоит дороже.

 Консолидация I/O

 В общем случае россыпь маленьких серверов могла использовать каждый свою подсистему хранения. Чисто теоретически, ничего не мешает подключить всю эту россыпь к большому серверу - единственная проблема в этом случае, нам нужно чтобы на большом сервере хватило карт ввода-вывода и их пропускной способности (IOPS). Конечно же ничего не мешает позвать специалиста по подсистемам хранения,  чтобы он дополнительно посчитал нам экономику от консолидации Storage. Ну и полная магия наступает в результате использования Exadata - все старые storage просто выбрасываются -) Итого, нам нужно получить картинку кол-ва IOPS вместе с block size от каждого маленького сервера и убедиться что один большой обладает достаточным кол-вом карт ввода-вывода, а подсистема хранения (если она новая) справиться с общим потоком IOPS. Замечание, Oracle считает что после миграции в multitenant кол-во требуемых IOPS снизится (см ссылку, страница 5) - но я не понимаю за счет чего это могло бы произойти.  Следующий момент, не все СУБД которые мы будет подключать к CDB будут требовать пикового IOPS одновременно - вполне возможно что тербования можно было бы снизить, но нужно помнить что 100 IOPS с блоком 8K <>  100 IOPS с блоком 1M. Именно поэтому существуют всякие хитрые storage tools которые умеют проводить консолидацию.
Что можно попробовать, так это собрать на одном графике iostat со всех серверов, но он даст нам среднюю длину записи ввода вывода, из чего сложно сделать вывод сколько каких IOPS реально было.

iostat -xkd  
И далее r/s  w/s дает соответсввенно количество операций чтения/записи а  avgrq-sz * 512 bytes даст средний размер 


Консолидация Памяти

С SGA мы ничего сделать не можем, просто как сложить все исходные SGA вместе. С PGA - поинтереснее, можно надеяться, что разным базам данных понадобиться память в разные моменты времени. Тут есть ограничение, что память не вернется в OS пока сессия не завершится (или не вернет память принудительно с помощью ?) Забегая вперед - правильный расчет памяти оказывается критическим - дело в том, что нет возможности ограничить ее использование с помощью resource manager. Единственное что можно сделать в версии 12c - установить - PGA_AGGREGATE_LIMIT на уровне CDB что поможет избежать paging.
Для мониторинга свободного кол-ва памяти можно использовать vmstat (откуда, зная размер физической памяти и размер SGA можно вычислить размер занимаемые PGA) или напрямую из DBA_HIST_PGASTAT. Мы понимаем, что частота сэмплов тут ограничена скоростью AWR snapshot, но для оценки памяти этого вполне достаточно.


 Консолидация процессорных ресурсов

Мы подошли к самому дорогому для нас вопросу в прямом смысле этого слова - от качества расчета процессорных лицензий будет зависеть цена вопроса. Что нам нужно - построить на одном графике загрузки CPU всех наших БД. Откуда взять загрузку CPU? Я категорически против того, чтобы брать их из AWR - только vmstat с частотой сэмплов 1 сек. Многие вообще не видят как можно сэкономить процессорные ресурсы при консолидации - 'ведь и так понятно, что все системы загружены одинаково:  примерно с 10 утра до 12,  и дальше после обеда с 14 до примерно 16 часов. До 100% доходит, жаловались мне. Надо складывать кол-во процессоров - другого выхода нет'.

На помощь может прийти математика (если вы ее считаете наукой) и практика.
Если у вас есть набор нормальных распределений (а мы считаем нагрузку CPU  подчиняющуюся  законам нормального распределения)  и средняя нагрузка 5%, а пиковая 37%, то для того чтобы 95% времени удовлетворять SLA нам нужен сервер эквивалентный 21% от текущего. Далее, еще одна  магия,  из центральной предельной теоремы следует, что при сложении N нормальных распределений суммарное стандартное отклонение растет как квадратный корень из N.

Простыми словами,  можно сложить до 9 нормальных распределений (как в абзаце выше) пока будет достигнут 93% загрузка сервера.



Это была математика. На практике таких фантастических результатов у меня не получалось, но в два-три раза снизить требования к кол-ву ядер при консолидации 8-12 различных нагрузок вполне реально. Я считаю очень важным посмотреть в реальные цифры загрузки процессора из vmstat. Это очень много меняет в понимании загрузки систем и как они поведут себя, когда будут работать совместно.



 Дополнительные расходы (overhead)

 Красота Multitent в том, что мне не приходят в голову откуда бы им взяться. Это важное преимущество над виртуализацией. Но есть другой момент - если вы складываете нагруженные системы, с большим кол-во блокировок и латчей, не могут ли они помешать друг другу?

Alex Fatkilin показал, что по крайне мере для Result Cache, латчи шарятся между различными PDB.  Я не успел проверить, но я считаю что есть вероятность, при сложении различных БД с высоким уровнем конкуренции усугубить это проблему.

И наконец, распределение ресурсов между PDB - ведь некоторые из БД, которые вы консолидируете могут оказаться важнее других. До 12.1 существовала возможность Instance Caging - вы могли гарантировать  своей БД столько cpu сколько ей одной было нужно.  С приходом Multitenant (CDB)  Instance Caging сохранился, но применяется только если у вас несколько CDB на одном хосте. Для PDB рекомендуют использовать новые интерфейс Resource Manager.

dbms_resource_manager.create_cdb_plan_directive (plan = 'mycdb_plan', pluggable_database = 'mydb', shares = 16, utilization_limit = 66);

Что это значит: вы назначаете каждой PDB ее вес (shares). Сумма весов может быть любой, важно соотношение весов между PDB - у кого больше shares тому больше и дадут процессорного  времени. Чтобы  как то ограничить PDB, используют utilization_limit - это жесткий лимит, ни при каких условиях данная PDB не сможет использовать больше 66% процессорных ресурсов всего сервера.

Схема кажется рабочей, хотя мне было бы приятно сказать - вот этой БД 4 ядра, выделенных, всем остальные пусть как хотят живут в пуле других 8 ядер.

Подробности конфигурации resource manager в MOS 1567141.1. 

Как вы видите, все несложно, посчитать ресурсы, которые вы складываете, все аккуратно сложить вместе и настроить Resource Manager.  Остается сделать небольшое заключение (следующий пост)


Читать дальше...

Oracle Multitenant. Part 1

Опция Multitenant - новая прекрасная опция 12c, которая стала возможна благодаря  существенной переработке архитектуры Oracle. Вкратце (я не претендую тут на полноту описания) теперь вы можете запустить несколько экземпляров баз данных (Pluggable DB) в рамках одной физической базы данных (container или CDB). Экономия  немедленно достигается за счет того,  что:

- ну нужно больше размножать служебные процессы Oracle для каждого экземпляра
- единая SGA

Дополнительные плюсы - теперь вам необходимо выполнять резервное копирование одной СУБД, а не нескольких.

Прекрасная ссылка по теме - Tom Kyte.  Tom часто употребляет термин консолидация, что так  и есть на самом деле: собирая на один большой сервер базы данных с несколько маленьких сервизов, вы на самом деле начинаете больше утилизировать процессоры, а значит на одном большом сервере  их вам понадобиться меньше (вопрос насколько, обсудим чуть дальше). На самом деле, Multitenant, как и любая EE опция -это средство экономии денег заказчика, при правильном применении. В примере выше - если на одном большом сервере нам нужно меньше процессоров - следовательно нам нужно меньше лицензий. Понятно, что в таком ключе (про лицензии) Oracle не очень хотел бы рассказывать, но подразумевается что заказчики это  понимают и поэтому готовы платить на опцию Multitenant. Кстати, стоит она 37% стоимости Enterprise Editions, так что вот и простой вопрос насколько эффективна должна быть ваша консолидация, чтобы быть экономически оправданной.

Теперь рассмотрим несколько вопросов, возникающих в момент миграции обычных баз данных в Multitenant.

Используете ли вы прочие другие опции Enterprise Edition?  Дело в том, что лицезировании Multitenant базы данных единое для всех включенных в нее баз данных. Скажем если, вы объединили две базы, одна из которых использовала partitioning на 4 ядрах, a другая нет (на 8 ядрах), теперь придется лицензировать partitioning на всех процессорах более крупного сервера (10 ядерного 4+8=12 - 2 экономии за счет консилидации). Ссылка по теме.

Character Set. Объединить в одну Multitenant базу данных удастся только БД с одинаковым character set.

Консолидация Баз данных Standard Edition - не поддерживается из-за лицензионных ограничений. Учитывая, насколько стали мощные 4-х сокетные сервера - разумное решение со стороны Oracle.    



Multitenant и RAC

Я с большим интересом прочитал мнение Alex Gorbachev, что сравнивать обе опции это как сравнивать яблоки и апельсины. Ну действительно, RAC позволяет системам расти вширь (scale out), в то время как Multitenant вверх (scale in). Стоит ли их использовать вместе, как на том настаивает Oracle?

Для примера слева (источник) когда у вас есть 5 баз данных и 3 узла можно было вполне обойтись только RAC - никто не мешает вам зарегистрировать несколько баз данных в RAC.  Другое дело, когда у вас есть двух-узловой кластер и вы собираете на нем десятки баз данных - тут Multitenant,  вне всякого сомнения пригодится.



Обратная сторона медали - применение патчей на Multitenant database. Сложили все яйца в одну корзину? Теперь хотите применить патч? Он применится ко всем базам данных и, теоретически, может повлиять на несколько из них. Конечно это не очень продуктивная стратегия, применять патч ко всем БД в один момент времени. Выход есть, вам нужно создать еще одну container (CDB) базу данных, применить патч на ней, и по одной подключать к ней PDB из старой CDB. Вы тоже заметили, что в какой то момент сервера становится 2, что страшно обрадует Oracle?  Я пока не знаю ответа, надеюсь на комментарии. Update 1. конечно можно создать новую CDB  на том же сервере, и играть в домино с ресурсами, такими как память, например. 

В части 2 мы рассмотрим собственно как посчитать выигрыш от консолидации и что ожидать от производительности в CDB.


Читать дальше...

Oracle Database In-Memory. Part 2

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

In-Memory собирается обрабатывать данные в памяти. Ларри несколько раз упоминал M6-32 с 32 TB памяти на борту как машину для таких задача. Однако, я не знаю ни одной инсталляции Oracle, которая использовала бы более 2TB памяти под SGA на одном узле. Пожалуйста напиши, если вам известна такая система, с указанием OS и версии DB. Интересно,  как именно будет организована память под хранение данных в In-Memory, но иного варианта как отдельную структуру памяти в SGA я пока не вижу.


Если вы попытаетесь использовать более 1TB под Oracle, вам скорее всего потребуется использовать huge pages (Linux) или large pages (AIX).  Это связано с тем, что если использовать меньшие размеры страниц памяти, кол-во запросов на преобразование вирутального адреса в реальной сильно возрастает, что приводит к проблема с TLB регистрами процессора - регистр не справляется, время обращения к памяти сильно  увеличивается.

В принципе, проблем, с тем, чтобы правильно сконфигурировать систему нет, но есть например известный факт, что hugepages (large pages) несовместимы с Automaic Memory Management (AMM).

"Each CPU scans local in-memory columns"
Далее,  для больших машинах класса M6-32/Power 795  производительность сильно зависит от того, приходится ли процессорам обращаться к ближней памяти (те памяти на своей процессорной плате)  или дальней (на других процессорных платах). По моим ощущениям, правильное распределение памяти - процессор может давать 20-40% производительности.

Насколько я знаю, обеспечить правильное распределение памяти можно только с помощью поддержки NUMA. NUMA можно сконфигурировать в Oracle, нет проблем, но это должно быть опять такие документировано как требование к In-Memory, для больших машин.

Как мне кажется, наиболее востребованным окажется In-Memory именно в кластерах машин с памятью до 1 Tb, поскольку там нет необходимости ни с чем вышеописанным иметь дело.


"Scans use super fast SIMD vector instructions"

SIMD - Single instruction, multiple data, возможность за один такт выполнить инструкцию над массивом данных. Оказывается существует уже много лет, вот только разработчики баз данных обратили на это внимание в этом году

(источник картинки)

Ларри во время выступления даже сказал, что под SIMD инструкции хорошо бы задействовать GPU..и на сайте Intel я нашел потрясающую штуку - проект Xeon Phi. Это сопроцессор с 61 ядром который как раз поддерживает еще более продвинутый SIMD чем текущие процессоры. Ожидаем Exadata V6 c сопроцессорами для обработки данных в памяти! -) 

Небольшое замечание - я пока не нашел нигде расшировки для каких именно операций (join, group by, aggregations) будет использоваться SIMD. Возможно это вопрос времени, постепенно все допишут. 

Что хотелось бы увидеть:   In-Memory индексы (их обещают, непонятно будут ли у них те же ограничения что у Exadata или нет),  возможность обновления данных в памяти без декомпрессии всего блока хранения (мы еще не знаем,  что собственно будет блоком хранения данных).

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


Читать дальше...

Oracle Database In-Memory. Part 1

10 Июня Ларри презентовал Oracle Database In-Memory.

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

На самом деле Ларри  не сказал ничего нового, по сравнению с тем, что рассказывали на OpenWorld, за исключением того, что эта опция будет доступна в следующем месяце.

Привожу слайд с OOW - где в одном слайде рассказано 90% презентации Ларри.

Итак, появляется возможность указать что таблица, или партиция должна быть постоянно в памяти в columnar формате (со сжатием, алгоритм отличается от того что есть в Exadata).  Для хранения этих  columnar таблиц вы сами определяете размер памяти. Данные хранятся только в памяти и попадают туда на старте БД или при первом обращении. Важно, что с оригинальной таблицей, которая хранится в raw based виде, ничего не происходит - она остается неизменной, а значит ваше приложение продолжает работать неизменно. Напротив, аналитическая часть, вместо чтения диска начинает обращаться к данным в памяти, что драматически ускоряет отчетность.

Ларри упомянул, что OLTP часть также ускоряется при использовании In-Memory - это правда, при условии, что вы удалите индексы, которые были необходимы для поддержки отчетности.

Ничего удивительного, что Oracle сразу же атаковал SAP HANA. Для SAP HANA сегодня это ключевой продукт, от его успеха или не успеха, во многом зависит успех компании. Для того, чтобы вы смогли использовать In-Memory с SAP потребуется сертификация SAP…которую придется подождать. Ту же самую шутку с сертификацией SAP уже проделала с IBM и DB2 BLU технологией - если я не ошибаюсь ждать пришлось год.

Что мне очень понравилось, так это то, что In-Memory полностью совместима с технологией RAC. После выступления Ларри была демонстрация, на которой один и тот же отче гоняли на 8 нодах Exadata и M6-32. M6 конечно работал быстрее (там межпроцессорные связи побыстрее infiniband), но не драматически. При этом, оказалось, что в RAC (или это Exa специальная возможность, не понятно) данные дублируются на двух узлах, и выход одного узла Exadata не привел к отказу системы.

По моему мнению, основное предназназначение In-Memory - это ERP системы, в которых по традиции намешано всего понемного, и OLTP и отчетность. Было бы круто понять, а можно ли использовать эту возможность только на standby. Многие же гоняют отчетность по active data guard, представляете как бы там все ускорилось без влияния на production…Я пока ответа не знаю.

Какие то дальнейшие заключения сложно делать не зная стоимости опции. Да, ускорение отчетов до 100 раз вполне возможно, вопрос сколько за это придется заплатить. 

Ларри также пообещал, что опция будет поддерживаться на всех платформах, на которых поддерживается Oracle и ..даже повторил - и Linux & Solaris -). Если не будет поддержки AIX - это будет очень сильный ход -) 

Список отрытых вопросов: (если кто то знает ответы - напишите пожалуйста в комментарии)

1. Eсли я хочу загрузить и сжать 10Tb on-startup это же сколько времени у меня займет этот самый startup СУБД?

2. Если я по недаразумению запущу update по своей таблице ведь чтобы отразить изменения мне придется заново сжать всю таблицу в памяти? Это должно быть весьма затратно по процессорным ресурсам

Update 1. Совсем забыл написать про TimesTen In-Memory. Изначально, TT предназначен для ускорения именно OLTP части, в отличии от Database In-Memory. Однако, в версии для Exalytics, в TT добавили аналитические функции, и возможность хранить данные в по-колоночном (columnar)  виде и поддерживается компрессия. Возникает интересный вопрос - если у Oracle уже была In-Memory, зачем же еще одна? Будет ли Oracle поддерживать оба продукта или один прекратит?  У меня пока ответов нет.  Из истории Oracle мы знаем, что всегда побеждает продукт, непосредственно внедренный в ядро СУБД, поэтому у меня впечатление, что Exalytics прекратит свое развитие. Ну действительно, если Exadata сможет делать все тоже самое, зачем отдельный продукт?


Читать дальше...

I'm back.

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

Если за последний год Вы обнаружили какой то интересный и постоянно обновляемый блог - пожалуйста в комментарии. Буду их пиарить по мере сил. Безвозмездно -  т.е. за пиво -)

Последнее, что я читал в рунете это Игорь Усольтцев, Oracle Mechanics - крайне рекомендую. 


Читать дальше...

SPEC(ulation)


Читаем блог Oracle про тест  SPEC CPU2006. Цитата:  

'The SPARC T5-8 server beat the 8 processor IBM Power 760 with POWER7+ processors by 1.7'. 

Очень красиво, очень. Хочется купить немедленно.  Правда результата этого на сервере spec.org на момент написания этого текста еще не было, но давайте верить на слово. Скриншот с вышеупомянутого блога:

Несколько комментариев: IBM Power 760 был 4-х сокетный, dual chip module, но Oracle упорно говорит что там было 8 сокетов. Хорошо, считаем per  cores:  T5 3750/128  =  29.2,  Power 760 2170/48 = 45.   И это не самый быстрый Power 7+. Берем результат Power 740 Power 7+, 16 ядер, peak result - 884. 884/16 = 55. Что видим: В 1.9 ( 55/29.2)  раз превосходство Power 7+  per core. Пересчитаны результаты колонки Peak. 

Ну а теперь посмотрим на результаты per core, в графическом виде. T5 не дотягивает ни до одного Power, даже старого, и проигрывает Xeon 2690 с меньшей частотой. 




*** Вечные вопросы и ответы на них ***

Q: Почему per core?   A: Потому что именно так лицензируется Oracle. 
Q: Почему нужно сравнивать T5 с Intel? Потому что сам Oracle делает тоже самое
Q: Все равно у Oracle фактор 0.5 для своих систем. A: если вы не слышали про вирутализацию, то Intel выходит дешевле (см пред пост). А если слышали - IBM выходит дешевле за счет виртуализации (см след. пост) 


PS

Давайте сравним еще  результаты Oracle T5 и  T3 per core (к сожалению результат T4 так и не был опубликован).  Увеличение частоты в 2.1 раза  (3.6 / 1.67)  привело к увеличение per core результата в 2.8 раза (29.2/ 10.4).  Понятно что это не только увеличение частоты, но и  общая оптимизация чипа. Т.е. оптимизация чипа дала ~25% прироста производительности через два поколения процессоров. 

Теперь сравниваем с тем, что делает IBM.  Понижает частоту и ...увеличивает результат. Или увеличивает частоту в 1.16 раз ..а результат увеличивается в 1.5 раз. Какая огромная работа проводится с самим чипом, алгоритмами, из множества возможностей находят наиболее эффективные.  


Теперь вот еще какой момент. Во время презентации Ларри сказал:  'double performance again as it has done with the Sparc T3 to T4 to T5'.  Итого в  4 раза для T5 если сравнивать с T3. Нажмите на картинку чтобы посмотреть поближе самим. 

Cравнение T5 и T3 дает мне ~2.8 что per core, что per system (ну нужно же учитывать что T3 был только 4-х сокетным).  Попросите Oracle пояснить,  как они посчитали удвоение производительности в каждом поколении, если тесты этого не показывают. 


Читать дальше...

Если у вас есть миллион

Я взял два теста, проведенные Oracle, с одной и тоже версией БД (Oracle 11gR2), примерно в одно и тоже время на системах на основе T5 и Intel.  В обоих системах 8 сокетов.   Посчитал tpmC/core. Разница в 5% в пользу T5. Было бы наверное неплохо, но посмотрите стоимость - она различается на 1 миллион долларов (прайс лист). 
Внимательный читатель обратит внимание, что указанная мной стоимость не совпадает с общей стоимостью в  отчетах TPC-C.  Действительно это так,  потому   что я исключил стоимость системы хранения. Я сравниваю  процессоры, а не системы хранения. 




5% это неплохо, если бы не одно 'но'. 10-ти ядерные процессоры Intel обладают частотой 2.4 GHz. Если посмотреть, что может выдать Intel Xeon 2.9 GHz с большим L3 кэшем (тест Cisco, с Oracle 11gR2), то окажется что tpmC/core гораздо выше: 100 против 66 у T5.

Почему это происходит, почему такой ужасный performance per core у T5 ? Если прочитать 'SPARC T5 Server architecture', стр 12, то  окажется что несмотря на наличие 8 потоков в ядре только один может выполняться в один момент времени - сравните с 4-мя в Power 7/Power 7+, двумя у Intel.

Не могу найти ни одной причины, чтобы потратить лишний миллион долларов на T5.  Лучше уж купить еще  один  X2-8 и немного пива. Ну HA кластер то вам понадобиться.   Ну а если вам не нужно 8 сокетов, подойдет и поменьше, то с x86 вы получите несравненно  лучший performance/core. Да и лицензируется Oracle все еще по ядрам, а не по серверам. Да, можно и по пользователям, но не забывайте про минимум 25 пользователей на ядро.

Почему такой шум с T5? Посмотрите на цену выше, при, грубо говоря, схожей цене на железо, за счет большего числа ядер колоссальная разница в цене лицензий. А поддержка лицензий, как мы помним стоит 22% в год. Сравните с поддержкой железа за 12% в год.

PS
Все данные по производительности и стоимости взяты из отчетов tpc.org


Читать дальше...

World’s Fastest Microprocessor


После вчерашнего поста про SAPS были опубликованы результаты T5 & M5 в  SAP Standard Application Benchmark.  Они совершенно неплохие, но в пересчете на ядро не могут догнать процессор Power  3-х летней давности. Не могу дождаться как  будет объявлено,  что мы видим word's fastest microprocessor -)

Update 1. TPC-C результат SPARC T5-8:


Вот так выглядит 5-ка лидеров (нажмите на картинку чтобы увеличить). Впечатляет, 3 из 5 первых мест.

Следующая картинка показывает какая впечатляющая работа была проведена - performance per core по сравнению с T3 и  T2 подскочил в 3 раза, что позволило  обогнать  даже Xeon 2690 (на 5%). Сильно мешают только рядом стоящие графики результатов IBM -)))))




Время доступности системы -  25 сентября 2013 года. Этот квартал продажами закрыть не удастся...Ну и конечно же стоит обратить внимание, что достичь впечатляющих результатов по цене помогло...лицензирование на 3 года, а не пожизненное. Вы ведь так и делаете, не так ли? Каждые три года покупаете Oracle заново?

Update 2. Внимательно послушал Ларри. В каждом, реально в  каждом слайде упоминается IBM. Я не знаю сколько IBM платит за эту рекламную компанию, но идея мне нравится -)))

Вот пример риторики Ларри:

'Наша маленькая машинка побила целый кластер IBM из 3-х high end  машин' -  красиво.












Смотрим с другой стороны (картинка ниже), спустя пять лет удалось достать +25% к результату теста. Ежу понятно, что спустя пять лет одно новое ПО даст гораздо больше чем все эти инженерные достижения...



А вот это интересно:


Если вы не знаете, SUN собирался сделать это в ..2005 году, процессор Rock. Зря его так назвали, сделать его помешал злой рок...


PS Скажите кто нибудь Ларри, что у IBM есть процессор Power 7+, он этого не знает похоже...


Читать дальше...