12-я версия СУБД Oracle радует новыми возможностями: архитектура Multitenant

Облачная 12-я версия СУБД Oracle радует новыми возможностями в области консолидации. Каждое обновление (feature) направлено исключительно на сокращение обслуживания БД, на упрощение работы и увеличение утилизации ресурсов. Так, например, раньше, чтобы восстановить удаленную таблицу, нужно было сделать следующее:

Зато теперь в утилите RMAN (Recovery Manager) есть команда RECOVER TABLE, которая делает ровно тоже самое, но только одной командой. Ну чем не консолидация? :-)

Рассмотрим подробно очень полезную новую опцию Oracle Multitenant - архитектура, которая позволяет пользователям легко консолидировать несколько баз данных , без изменения их приложений, использовать все преимущества управления многими базами данных , как одной, но все же сохраняет изоляцию и приоритетность ресурсов отдельных баз данных. Теперь несколько баз обитают в одной среде, как соседи в коммунальной квартире, прекрасно уживаясь и ладя между собой :-). С помощью Oracle Multitenant , обновления и патчи применяются к многопользовательскому контейнеру баз данных, упрощая и ускоряя весь процесс. Кстати, перевод слова  TENANT  - арендатор, жилец, наниматель, квартиросъемщик, обитатель, квартирант.

Кроме того, Oracle Multitenant  позволяет быстрое развертывание и обновление , и  в полной мере дополняет другие варианты, включая Oracle Real Application Clusters, и Active Data Guard.
В этой новой облачной архитектуре многопользовательской базы данных, контейнер может содержать
много подключаемых баз данных. Теперь клиенты могут легко объединить несколько баз данных. 

Oracle Multitenant. В этой новой архитектуре память и фоновые процессы необходимы только в многопользовательском уровне контейнера базы данных , что позволяет ИТ-организации  достигнуть более высокого уровня масштабируемости и плотности без консолидации без нарушения безопасности старых баз данных.
В дополнение к упрощению консолидации баз данных , Oracle Multitenant  также позволяет администраторам баз данных легко скопировать базы данных и подключить их к разработке и тестированию контейнеров. Кроме того, если основная
файловая система поддерживает копирование при записи (например, файловая система ZFS , ASM кластера файловой системы ), клонирование
подключаемых баз данных может произойти почти мгновенно .
ОСНОВНЫЕ ПРЕИМУЩЕСТВА
• Упрощение консолидации баз данных
• Надежное изолирование данных
• Быстрота и клонирование
• Более быстрое обновление и исправление
• Управление множеством подключений одним ORACLE DATA SHEET

Управление многими базами данных As One ( "как одной" ).
Очевидное преимущество консолидации баз данных является то, что администраторы имеют меньшее количество баз данных. Другими словами, все подключаемые базы данных объединены в контейнер и соединены в одну, и администраторам проще  выполнять операции восстановления в отдельных подключаемых уровнях базы данных, если требуется.

 Использование в  облаке Oracle Multitenant очень просто. Администраторы могут использовать знакомые обновления на месте способа обновления существующих баз данных и подключать их к многопользовательским контейнерам баз данных или использовать интеграции данных инструментов, такие как Data Pump и GoldenGate для переноса данных с подключаемых баз данных. Администраторы могут использовать Oracle Enterprise для упрощения управления Oracle Multitenant из базы данных. 

 Oracle Multitenant option  предназначена для консолидации, но уже не для улучшения работы обслуживающего персонала, а для хранения и обработки самих данных. Наглядно выглядит это так. Правительство (или корпорация Oracle) начинает новую жилищную программу, когда несколько семей переселяются в коммунальные квартиры. Таким образом:

1. Повышается утилизация ресурсов: туалетов (дисков), канализации(Network), водопровода (CPU), отопления (Memory)
2. Несмотря на то, что тарифы (Лицензии) на коммунальные услуги в таком помещении значительно выше по сравнению с обычной Stand Alone квартирой, в итоге жильцам приходится платить меньше. На лицо - двойной плюс. И правительству - выгодно, и жильцам - экономия :-) . Хотя прежняя денежная политика, в принципе, сохраняется. Типа  денежки заносите нам, а с проблемами пожалуйте в управляющую организацию  (то бишь к Партнеру). Да и помощи от них особо не дождешься: на заборе написано Support (ТехПоддержка), а на самом деле еще не понятно, что там тебе поддержат.
3. Различные рутинные операции вроде визита участкового, проверок ГорГаза или снятия показаний счетчиков теперь проводятся для всех семей сразу, и для этого не обязательно присутствие каждого из соседей, вполне можно выделить одного представителя (Container Database), который и займется всеми переговорами с представителями властей.

Но что будет, если отключат воду? Ведь теперь от такого downtime пострадают сразу несколько семей, а не отдельная квартира. Пустяки! Ведь, согласно заверениям правительства, новая архитектура позволяет выдернуть особо критичную семью (Unplug Database) из одной коммуналки и подключить (Plug into) в другую, т.е туда, где ремонтные работы уже проведены.

Налицо существенное уменьшение неудобств, но почему все забывают собственно про сам переезд, когда надо упаковывать вещи, грузить коробки в грузовики и выполнять прочий Transfer Data? По-моему, неудобств остается ровно столько же, а еще появляются и дополнительные хлопоты вроде того, что надо заново обживаться на новом месте (или исправлять ошибки переезда из представления PDB_PLUG_IN_VIOLATIONS). Ведь пока современные методы телепортации стоят безумных денег и являются весьма непривлекательными (Streams, GoldenGate). Несмотря на то, что подобные методы всячески популяризуются различными высосанными из пальца Success Stories и бесплатными trial-периодами, обыватель мудро полагает, что за несколько недель можно только избавиться от запора, да и то если есть хорошее слабительное.

А что если в одной из комнат коммуналки обитают буйные соседи, которые дебоширят по ночам и мешают спать остальным? Ведь слышимость здесь далеко не такая, как в изолированной отдельной квартире! В итоге просыпается сначала один сосед, потом другой и в конце концов заваривается такой бардак, который заканчивается только вызовом участкового (или DBA). Дядя в фуражке пригрозит шумным соседям  или посадит особо буйного товарища в обезьянник (kill session) для дальнейшего выяснения.

Но заботливое правительство позаботилось о том, чтобы подобные вещи тревожили обывателей как можно меньше. Заботливый участковый под страхом лишения свободы определяет простые правила, вроде "больше трех не собираться" (PDBs Resource Plans). Несмотря на то, что дебоширам приходится формально следовать правилам, они просто научились их обходить. Теперь они собираются несколькими кучками по три человека и продолжают точно также дебоширить.

Безусловно, в пребывании большого количества народа под одной крышей определенно должны быть плюсы. Например, удобство коммуникации. Но нет. Чтобы пообщаться с друганом из соседней комнаты, нужно выходить из квартиры и снова звонить в главный звонок (создавать DB_LINK) и ждать, когда тот, другой сосед тебе откроет.

Про передачу сообщений вообще говорить не стоит. Казалось бы, коротенькую весточку можно просто написать на бумажке и подсунуть под дверь (grant insert), но приходится как и раньше идти на почту, отправлять заказное письмо и ждать уведомление о получении.

А если мы, к примеру, хотим вскрыть стены и проложить проводку или снять обои, чтобы перечитать старые газеты, наклееные на стенку, (т.е сделать FlashBack), то теперь такая операция повлияет на всех остальных соседей, а если кто-то из соседей, не дай бог, уже поменял коммуникации, то его квартиру надо заколачивать намертво, иначе возникнет конфликт оборудования от разных производителей (ORA-39866)

Планируется, что в ближайшем будущем все квартиры станут коммунальными, а обычные отдельные квартиры отойдут в небытие. Причем новая правительственная программа предусматривают дополнительные бонусы. К примеру, в отдельных квартирах нового типа появятся чуланы для хранения ненужных вещей (In-Database Archiving), но в коммуналках такие новые возможности пока не поддерживаются.

Или другая интересная возможность. Ты убираешь на антресоль вещь, которая может скоро понадобиться, и в нужный момент она вдруг сваливается на тебя, как снег на голову (Temporal Validity). Но поскольку антресоли в коммуналках появятся только во второй редакции, то тоже - извините.

У нас появится реестр всех вещей, находящихся в квартире (Heat Map), который автоматически отследит, как часто ты используешь тот или иной предмет. Причем при помощи простых правил ты можешь определить, что, скажем, вещь, которую купили и ни разу не использовали в течение года, отправлялась бы на вечное хранение в чулан... сама! (Automatic Data Optimization). Но, поскольку реестр в коммуналке повесить негде, то и правила определять нельзя. Хотя, конечно, можно, но работать они все равно не будут.

Я уверен, что ни одна уважающая семья (или база данных) не согласится жить в подобных нечеловеческих условиях. Хотя, если рассматривать такие коммуналки в качестве концентрационных лагерей для незаконных мигрантов, на чью судьбу всем наплевать, то, безусловно, в мультиарендной среде от Оракл (Oracle Multitenant option) и есть какой-то толк. Ведь теперь стало понятно как именно корпорация Oracle собирается относиться к нашим базам данных.

Oracle Multitenant  также подходит для поставщиков SaaS.  

Инфографика Oracle Multitenant :

Резервное копирование нескольких баз данных как одну с Oracle Multitenan.

Управление несколькими базами данных как одиной с Oracle Multitenan.

Многопользовательская архитектура позволяет предоставлять базу данных очень быстро.

Перемещение базы данных с Oracle Multitenant происходит очень быстро.

Архитектура multitenant позволяет увеличить коэффициент использования серверов.

Ссылки по теме

• Каталог программ Oracle
• Задать вопрос ONLine по покупке программ Oracle
• Купить программу Oracle Database Enterprise Edition
• Купить Oracle Database Standard Edition One