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.