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 - крайне рекомендую. 


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