ACE Director
Источник: журнал Oracle Magazine #5 (сентябрь-октябрь) 2013
http://www.oracle.com/technetwork/issue-archive/2013/13-sep/o53cloud-1971984.html
Джон, главный архитектор баз данных в банке ACME, принимает сегодня важных посетителей: директора по информационным технологиям (CIO - chief information officer) и ее старших ИТ-служащих.
ACME имеет несколько отделов, в каждом из которых используется купленное приложение MortEngage, которое управляет процессом ипотечного кредита. За последние годы эти подразделения расширились и стали использовать различные версии этого продукта в своих независимых базах данных. Компания понимает необходимость консолидации многочисленных баз данных и машин, и как часть текущего проекта консолидации ИТ-директор хочет собрать все отдельные установки в единую базу данных, работающих на одной мощной машине. Все различные экземпляры приложения будут представлены в виде схем в единой базе данных, что устранит много накладных расходов. Предполагается, что будет один экземпляр базы данных Oracle, а не сотни, будет только один набор метаданных для всех баз данных Oracle, а также снизится необходимость в администраторах баз данных для управления всего лишь одной базой данных и так далее. Идея отличная, но, к сожалению, ИТ-директору сообщили, что каждому приложению нужно конкретное имя схемы — MORTENGAGE — в базе данных, и это жестко прописано в заявке и не может быть изменено. Очевидно, как DBA правильно информировали CIO, что невозможно создать в базе данных две разные схемы с тем же именем. Таким образом, единственный способ запуска нескольких экземпляров приложения — это создание требуемых схем в нескольких отдельных базах данных.
Консолидация? Невозможно — это общий приговор ABD компании ACME.
Но умная CIO не готова просто так отказаться. Она дает Джону карт-бланш для поиска решения, и она не проигрывает. Действительно, можно консолидировать базы данных в новой мультиарендной (multitenant) архитектуре в Oracle Database 12c, это она узнает от улыбающегося Джона. По ходу этой статьи станет очевидно, как Джон обеспечил требуемое решение.
Проблема имеет отношение, Джон сообщает CIO и старшим ИТ-руководителям, к пространству имен. Каждый пользователь Oracle Database обладает уникальным именем, так что, если программа связана с пользователем базы данных по имени MORTENGAGE, то только один экземпляр приложения может работать в этой базе данных. Для каждого дополнительного развертывания этого приложения необходимо задействовать пользователя MORTENGAGE на другой базе данных.
Но это изменилось в Oracle Database 12c, объясняет Джон. Вместо создания нескольких [обычных] баз данных, можно создать несколько pluggable (подключаемых) баз данных в мультиарендном контейнере базы данных. Экземпляр базы данных – набор областей памяти, таких как кэш-буфер и разделяемый пул, процессы, например, PMON и SMON, – связаны с контейнером мультиарендной базы данных; индивидуальные подключаемые (pluggable) базы данных не имеют своих собственных экземпляров. Процессы экземпляра базы данных Oracle существуют только для контейнерной мультиарендной базы данных, но не для подключаемых баз данных, что экономит много ресурсов на хост-сервере.
Для иллюстрации этой концепции Джон обратил внимание CIO и ИТ-руководителей на Рисунок 1 и показал различные базы данных; они используют память, процессор и устройство хранения, и какова экономия после того, как базы данных были закреплены в качестве подключаемых на одном мультиарендном контейнере базы данных. На рис.1 показаны три красных экземпляра баз данных до начала консолидации и один мультиарендный контейнер базы данных после консолидации. Зеленые - это подключаемые базы данных после консолидации, они являются сменяемыми базами.
Рисунок 1: Несколько экземпляров базы данных преобразуются в подключаемые базы в мультиарендном контейнере базы данных
Немного погодя, CIO спрашивает: "Так вы, Джон, говорите, что фактически есть только одна база данных, и, следовательно, есть только один набор всех областей памяти, таких как SGA, и один набор фоновых процессов: SMON и т.д., независимо от Количества подключаемых баз данных. А если есть только одна подлинная база данных, как может быть в ней несколько пользователей с одним и тем же именем - MORTENGAGE - ?"
"В этом и заключается красота мультиарендной архитектуры Oracle Database 12c" — объясняет Джон. Для пользователей подключаемых баз данные ведут себя как данные обычных баз. На самом деле обычный пользователь может даже не знать разницу [в статусе базы]. "Если нужно запустить 50 экземпляров приложения", - продолжает Джон, - "ABD ACME создадут 50 подключаемых баз в одном мультиарендном контейнере. Каждая подключаемая база данных имеет только одного пользователя MORTENGAGE и поддерживает одну инсталляцию приложения." В этот момент слушатели с заметным энтузиазмом призывает Джона показать, как это работает.
Для создания баз данных Джон запускает утилиту конфигурации Database Configuration Assistant, которая имеется в составе Oracle Database 12c. После нескольких кликов он получает экран Database Identification (Идентификатор базы данных), как показано на рисунке 2. Джон выбирает кнопку Create a Container Database with one or more PDBs (Создание контейнера базы данных с одним или несколькими подключаемыми базами) и выбирает 2 – число подключаемых баз. Он входит CONT – имя мультиарендного контейнера базы данных в поле Global Database Name (Глобальное Имя базы данных), и PLUG (штекер) – префикс имени подключаемой базы данных (в поле PDB Name Prefix). Это создаст мультиарендный контейнер базы данных с именем CONT и два подключаемые базы данных с именами PLUG1 Plug2.
Рисунок 2: экран утилиты Oracle Database Configuration Assistant для создания подключаемых баз данных.
После создания мультиарендного контейнера базы данных (CDB – container database) Джон хочет, удостовериться, что были созданы и две подключаемых базы данных. Oracle Database 12c включает новое представление V$PDBS, которое показывает подключаемые базы данных. Джон логинится к SQL*Plus как пользователь SYSDBA и выбирает два столбца в этом й представлении:
SQL> select con_id, name
2 from v$pdbs;
CON_ID NAME
—————————— ——————————
2 PDB$SEED
3 PLUG1
4 PLUG2
Подключаемые базы данных также называются контейнерами (containers) и каждый контейнер имеет уникальный идентификатор, показанный в столбце CON_ID листинга. Джон проверяет вывод запроса и подтверждает, что действительно были созданы два контейнера с CON_IDs 3 и 4, как и ожидалось. По умолчанию Oracle Database 12c создает контейнер с именем PDB$SEED, который также появляется в листинге. Джон уточняет, что этот контейнер не может использоваться приложениями, но может быть использован для создания других контейнеров путем клонирования.
Подключаемые базы данных не имеют своих собственных фоновых процессов и разделяемых областей памяти. Однако они занимают какое-то место в метаданных мультиарендного контейнера, в redo_log файлах, в управляющем (controlfile) файле, а также в некоторых табличных пространствах, например, undo. Каждая из подключаемых баз данных имеет свои собственные табличные пространства SYSTEM, SYSAUX, TEMP и USERS. Для всего мультиарендного контейнера Oracle Database имеет место общее положение опции Automatic Diagnostic Repository; подключаемые базы данных не имеют независимого Automatic Diagnostic Repository. Таким образом, после консолидации 50 упоминавшихся ранее независимых баз данных в 1 мультиарендном контейнере DBA должны управлять только одним мультиарендным контейнером базы данных. Существует всего один экземпляр и один процесс PMON вместо 50, уменьшаются требования к количеству процессоров и памяти. Все это доказывает значительное снижение стоимости, как инфраструктуры, так и эксплуатации.
Затем Джон переходит к созданию пользователей, необходимых для приложения. Приложение нуждается в пользователе с именем MORTENGAGE. Джон создает такого пользователя в каждой из подключаемых баз данных. Для создания пользователя в подключаемой базе данных PLUG1, он впервые устанавливает параметр сессии CONTAINER (КОНТЕЙНЕР) с именем подключаемой базы данных, а затем создает пользователя.
SQL> alter session set container = plug1; Session altered. SQL> create user mortengage identified by plug1pass; User created.
Чтобы создать такое же имя пользователя в другой подключаемой базе данных, он выполняет следующие команды:
SQL> alter session set container = plug2; Session altered. SQL> create user mortengage identified by plug2pass; User created.
После выполнения этих запросов Джон проверяет их наличие, используя новое представление Oracle Database 12c, называемое CDB_USERS:
SQL> select con_id, username, common
2 from cdb_users;
CON_ID USERNAME COMMON
————————— ————————————— ————————
3 MORTENGAGE NO
4 MORTENGAGE NO
1 SYSTEM YES
2 SYSTEM YES
3 SYSTEM YES
4 SYSTEM YES
На этот результат стоит обратить особое внимание. Есть два пользователя с именем MORTENGAGE, но они находятся в двух разных подключаемых базах данных – их контейнеры отличаются по столбцу CON_ID – 3 и 4. Поскольку эти пользователи относятся к различным подключаемым базам данных, они не видны во всех подключаемых базах. Они называются local (локальными) или noncommon пользователями, индицируемыми как NO в столбце COMMON в листинге. Напротив, пользователь SYSTEM видим во всех контейнерах. Более того, в отличие от пользователя MORTENGAGE пользователь SYSTEM это тот же пользователь во всех подключаемых баз данных в мультиарендном контейнере. SYSTEM известен как common (обычный) пользователь, а его значение в столбце COMMON — YES.
"Я вижу, что в каждой из подключаемых баз данных есть пользователь MORTENGAGE", - отмечает один DBA, - "но как приложение соединяется с определенной подключаемой базой данных?"
"Точно так же, как это было в прошлом с использованием соответствующей TNS-строки соединения", - отвечает Джон. В файле TNSNAMES.ORA, расположенном в директории network\admin в Oracle Home на клиентских машинах, где функционируют приложения. Листинг 1 показывает элементы файла TNSNAMES.ORA.
PLUG1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prohost1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PLUG1)
)
)
PLUG2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prohost1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PLUG2)
)
)
Имена служб (service names ) в каждой строке соединения определяют подключаемые базы данных для соединения. Каждая подключаемая база данных имеет уникальное имя службы, которое совпадает с именем подключаемой базы данных. Так подключаемая база данных PLUG1 имеет по умолчанию имя службы PLUG1, которое не может быть определено для любой другой подключаемой базы данных в мультиарендном контейнере. Приложения соединяются с базой данных так же, как они всегда это делали. Простой пример демонстрирует SQL*Plus-соединение с подключаемой базой данных PLUG1:
sqlplus mortenagage/plug1pass@plug1
Приложение, работающее с подключаемой базой данных Plug2, использует в строке Connect имя Plug2, так что с точки зрения приложений и обычных пользователей ничего не меняется. Вместо соединения с отдельными независимыми базами данных, приложения и пользователи в настоящее время коннектятся к нескольким подключаемым базам-контейнерам в одном мультиарендном контейнере базы данных. Для приложений контейнеры являются независимыми базами данных. Это музыка для ушей CIO.
Чтобы определить, с какими подключаемыми базами данных соединен пользователь, в функции SYS_CONTEXT применяется новая переменная пользовательской среды CON_NAME:
SQL> select sys_context('userenv','con_name')
2 from dual;
SYS_CONTEXT('USERENV','CON_NAME')
———————————————————————————————————
PLUG1
В этот момент, Майя, ведущий разработчик, отвечающая за развертывание приложений и их обслуживание, выражает беспокойство. Различные установки приложения MortEngage требуют различных настроек базы данных для повышения производительности. Например, в одной базе данных параметр optimizer_use_sql_plan_baselines установлен в TRUE, чтобы воспользоваться исходным планом выполнения, тогда как в других базах этот параметр равен FALSE. Теперь, когда мультиарендный контейнер базы данных является одинаковым для всех этих подключаемых баз, ее беспокоит, что все подключаемые базы получат одинаковое значение параметра, что может привести к серьезным проблемам некоторые инсталляции приложения.
Это действительно важно, но Джон говорит, что, к счастью, можно задавать различные значения параметров для разных подключаемых баз данных. Он демонстрирует это, установив значение параметра в FALSE в подключаемой базе данных Plug2.
$ sqlplus sys/oracle@plug2 as sysdba SQL> alter system set optimizer_use_sql_plan_baselines = false scope=memory;
Затем он устанавливает значение TRUE того же параметра в подключаемой базе данных PLUG1 .
$ sqlplus sys/oracle@plug1 as sysdba SQL> alter system set optimizer_use_sql_plan_baselines = true scope=memory;
Джон затем регистрируется в различных подключаемых баз данных как пользователь MORTENGAGE и проверяет значение параметра.
Первое подключение к Plug2:
SQL> connect mortengage/plug2@plug2 SQL> show parameter optimizer_use_sql_plan_baselines NAME TYPE VALUE —————————————————————— ——————— ——————— optimizer_use_sql... boolean FALSE
Значение параметра, как и ожидалось, FALSE.
При подключении к PLUG1 проверка показывает, что значение TRUE.
SQL> conn sys/oracle@plug1 as sysdba Connected. SQL> shutdown immediate Pluggable database closed.
У CIO растет уверенность в приемлемости мультиарендной архитектуры. Но Джилл, менеджер DBA, все еще проявляет скептицизм. "Хорошо, если это на самом деле единая база данных. Но как администраторы баз данных смогут независимо управлять подключаемыми базами данных? Например, почему именно этот DBA, а не другой, остановит какую-либо конкретную подключаемую базу данных?"
Джон соглашается, что это важный вопрос, но он утверждает, что подключаемыми базами данных можно управлять раздельно. Чтобы продемонстрировать это, Джон сначала логинится как SYSDBA к подключаемой базе PLUG1 и останавливает ее:
SQL> conn sys/oracle@plug1 as sysdba Connected. SQL> shutdown immediate Pluggable database closed.
После ее остановки проверяет статус всех подключаемых баз:
SQL> conn / as sysdba
Connected.
SQL> select con_id, name, open_mode
2 from v$pdbs;
CON_ID NAME OPEN_MODE
————— ———————— ———————————
2 PDB$SEED READ ONLY
3 PLUG1 MOUNTED
4 PLUG2 READ WRITE
Подключаемая база PLUG1 находится в состоянии MOUNTED, Джон прав. На другие подключаемые базы это не оказало воздействия.
Аналогичным образом Джон стартует подключаемую базу следующей командой:
SQL> conn sys/oracle@plug1 as sysdba Connected. SQL> startup Pluggable Database opened.
Поскольку экземпляр базы данных принадлежит контейнерной мультиарендной базе данных и разделяется подключаемыми базами, собственно экземпляр сам по себе не закрываются, когда Джон закрывает подключаемую базу данных. А учитывая, что Alert log — журнал регистрации событий обслуживает экземпляр базы данных, он принадлежит мультиарендной контейнерной базе данных, и в Листинге 2 Джон показывает нам его хвостовую часть. В этих строках Джон видит, что подключаемая база данных PLUG1 была закрыта, а спустя некоторое время открыта в режиме чтения/записи.
2012-12-21 16:24:31.874000 -05:00 ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE ALTER SYSTEM: Flushing buffer cache inst=0 container=3 local 2012-12-21 16:24:32.923000 -05:00 Pluggable Database PLUG1 closed Completed: ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE 2012-12-21 16:24:38.095000 -05:00 ALTER PLUGGABLE DATABASE OPEN READ WRITE 2012-12-21 16:24:45.659000 -05:00 Opening PDB 3 with no Resource Manager plan active Pluggable Database PLUG1 opened read write Completed: ALTER PLUGGABLE DATABASE OPEN READ WRITE … output truncated …
Джилл все еще не убеждена, что такая консолидация будет легкой прогулкой для ее команды. "У нас есть тонны скриптов, использующих DBA_представления, например, DBA_USERS, чтобы получить список всех пользователей. Должны ли мы теперь изменить все эти скрипты для использования CDB_представлений? Это очень много изменений."
"Вовсе нет", - уверяет Джон. - "CDB_префиксируемые представления, вновь вводимые в Oracle Database 12c, показывают данные по всем подключаемым базам данных внутри контейнера. Однако, когда DBA соединен с одной из подключаемых баз данных, DBA_префиксированные представления показывают метаданные, которые специфичны для конкретных подключаемых баз данных. Ни один из скриптов, использующих DBA_префиксированные представления, не должен быть изменен.
Кроме того, Oracle Enterprise Manager 12c владеет данными о мультиарендной архитектуре и DBA компании ACME могут использовать этот инструмент для управления мультиарендном контейнером базы данных и подключаемыми базами. Джилл была просто счастлива.
Могущество мультиарендной архитектуры Oracle Database 12c не ограничивается просто возможностью работать с несколькими подключаемыми базами данных к мультиарендному контейнеру. Можно также создать другую подключаемую базу в качестве копи и существующей или быстро клонировать подключаемую базу. Джон демонстрирует процедуру клонирования подключаемой базы Plug2 в виде новой подключаемой базы с именем PLUG3:
SQL> conn / as sysdba
SQL> alter pluggable database plug2 close;
SQL> alter pluggable database plug2 open read only;
SQL> create pluggable database plug3
from plug2 file_name_convert = ('PLUG2','PLUG3');
Команда выполнилась успешно с сообщением “Pluggable database created.” ("подключаемая база создана").
Теперь подключаемая база готова к функционированию.
SQL> alter pluggable database plug3 open;
Теперь подключаемая база данных PLUG3 готова к функционированию.
Джилл, менеджер DBA, чувствует значительный потенциал этой функции. Команды разработчиков приложений часто просят DBA клонировать базы данных для отработки QA (гарантия качества) и их тестирования, а завершения тестирования отказаться от них. Эта деятельность требует не только значительных усилий со стороны администраторов баз данных, но требует также значительных ресурсов CPU и памяти на сервере для запуска новых экземпляров баз данных. В мультиарендной архитектуре, применяя клонирование можно сразу раскручивать другие базы данных для тестирования без потребления дополнительных CPU и памяти. Когда тестирование завершено, можно удалить вновь созданную подключаемую базу, выполнив следующую SQL-команду:
SQL>drop pluggable database plug3 including datafiles;
Джилл иногда получает для клонирования базы данных с других серверов. Она спрашивает, сможет ли мультиарендная архитектура базы данных Oracle 12c выполнить это. Джон отвечает, что клонирование не есть преимущество только одной базы данных. Можно клонировать другие подключаемые базы данных через другой мультиарендный контейнер, или "вставить" подключаемую базу из удаленного мультиарендного контейнера в данный мультиарендный контейнер базы данных. Эту Джон технику продемонстрировал с помощью следующих шагов:
SQL> alter pluggable database plug4 close;
Pluggable database altered. [подключаемая база данных изменена]
"Отключите" (“Unplug”) подключаемую базу: Создайте новый файл метаданных с информацией о подключаемой базе. Эта информация хранится в XML-формате (а Джон назовет этот файл pluginfo_plug4.xml). Этот файл метаинформации создается в директории Oracle Home, как поддиректория базы данных (в Windows) или в поддиректории DBS (в UNIX).
SQL> alter pluggable database plug4 2 unplug into 'pluginfo_plug4.xml'; Pluggable database altered. [подключаемая база данных изменена]
SQL> connect sys/oracle@plug4 as sysdba SQL> select name from v$datafile;
SQL> drop pluggable database plug4;
SQL> connect / as sysdba
SQL> create pluggable database plug4 2 using ‘pluginfo_plug4.xml’;
На выходе Джон получает “Pluggable database created”, что подтверждает создание клонированной базы данных. Джилл вне себя от радости!
"А как насчет резервных копий?" — спрашивает Джилл. В частности, она обеспокоена тем, что возможно придется существенно изменить многие хорошо написанные и проверенные скрипты резервного копирования Oracle Recovery Manager (Oracle RMAN), которые использует ACME. Джон уверен, что они не изменятся. Резервное копирование Oracle RMAN работает на отдельных подключаемых базах данных или на всем мультиарендном контейнере, при этом создаются резервные копии всех подключаемых баз данных внутри него. Джон приводит пример команды Oracle RMAN для резервного копирования подключаемой базы PLUG1.
$ rman target=sys/oracle@pdb1 RMAN> backup database;
Джон показал, что команды резервного копирования точно такие же, как в релизах Oracle Database до 12c. Поэтому нет никакой необходимости изменять скрипты резервного копирования. Более того, при восстановлении используются такие же команды, как и в предыдущих версиях Oracle Database.
RMAN> restore database; RMAN> recover database;
Резервное копирование всех подключенных к мультиарендному контейнеру баз данных может быть сделано во время этого подключения. Джон демонстрирует:
$ rman target=/ RMAN> backup database;
Кроме того, в это время может быть сделано [выборочное] резервное копирование конкретных подключаемых баз данных, подключенных к мультиарендному контейнеру. Ниже показана эта команда для совместного резервного копирования подключаемых баз данных PLUG1 и PLUG3.
RMAN> backup pluggable database plug1,plug3;
Читайте руководство по настройке Oracle ADF Mobile, чтобы узнать о настройке среды разработки для развертывания мобильных приложений для Android и родных IOS-устройствах или их эмуляторов. После завершения настройки, просто разверните пример приложения родного устройство или эмулятора устройства.
Время развертывания колеблется для мобильных операционных систем и устройств, но всего требуется до двух минут. Во время развертывания типовое приложение пакетируется, а затем сворачивается в родной контейнер устройства для целевой операционной системы. После развертывания вы увидите на мобильном устройстве иконку приложения, помеченную OraMagSepOct13 (этикетка может быть обрезана, если вы развернули приложение для мобильного телефона).
Обратите внимание, что в верхней части мобильного экрана значок красного треугольника (см. Рисунок 2) во время выполнения показывает, что развернутое приложение находится в режиме отладки. Это может быть изменено с помощью параметра конфигурации в проекте ViewController, и это изменение также сокращает время развертывания.
Подключаемые базы данных, работающие в мультиарендной архитектуре Oracle Database 12c, обеспечивают простоту и знакомство с традиционными базами данных, обеспечивая при этом гибкость для запуска нескольких подключаемых баз данных в пределах одного мультиарендном контейнера базы данных.
Мультиарендная архитектура позволяет совместно функционировать многим схемам с одинаковыми именами без необходимости порождения множества различных баз данных. Имеется только один мультиарендный контейнер и только один экземпляр базы данных, устранены фоновые процессы Oracle Database и такие, как SGA, области памяти для отдельных баз данных. Применение подключаемых баз данных в мультиарендной архитектуре Oracle Database 12c не требует внесения изменений в приложения.
Все ИТ-руководители ACME убеждены, улыбаются, ни у кого не возникает больше вопросов о целесообразности применения Oracle Database 12c, ее мультиарендной контейнерной архитектуры, подключаемых баз данных, нет вопросов о подготовке, клонировании и резервных копиях. Заседание закрывается.
Аруп Нанда (arup@proligence.com ) администратор баз данных Oracle с 1993 года, занимается всеми аспектами администрирования баз данных, от оптимизации производительности до безопасности и аварийного восстановления. Он был DBA 2003года по версии журнала Oracle Magazine, он получил премию Oracle Excellence Award for Technologist в 2012 году.