|
|
|||||||||||||||||||||||||||||
|
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. В этой новой архитектуре память и фоновые процессы необходимы только в многопользовательском уровне контейнера базы данных , что позволяет ИТ-организации достигнуть более высокого уровня масштабируемости и плотности без консолидации без нарушения безопасности старых баз данных. Управление многими базами данных As One ( "как одной" ). Использование в облаке Oracle Multitenant очень просто. Администраторы могут использовать знакомые обновления на месте способа обновления существующих баз данных и подключать их к многопользовательским контейнерам баз данных или использовать интеграции данных инструментов, такие как Data Pump и GoldenGate для переноса данных с подключаемых баз данных. Администраторы могут использовать Oracle Enterprise для упрощения управления Oracle Multitenant из базы данных. Oracle Multitenant option предназначена для консолидации, но уже не для улучшения работы обслуживающего персонала, а для хранения и обработки самих данных. Наглядно выглядит это так. Правительство (или корпорация Oracle) начинает новую жилищную программу, когда несколько семей переселяются в коммунальные квартиры. Таким образом:
Но что будет, если отключат воду? Ведь теперь от такого 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 позволяет увеличить коэффициент использования серверов. Ссылки по теме
|
|