Oracle multitenant что это

Обновлено: 04.07.2024

Терминология

В примерах, иллюстрирующих процесс клонирования, используются следующие БД:

Требования

Процесс клонирования удаленной БД, как PDB, так и non-CDB во многом идентичен. Поэтому требования в обоих вариантах одинаковые.

Пользователь локальной БД должен иметь привилегии CREATE PLUGGABLE DATABASE.
Удаленная БД (PDB и non-CDB) должна быть запущена в режиме только для чтения (read-only mode).
В локальной БД должна быть создана ссылка (database link) на удаленную БД. Если клонируется PDB, то ссылка может быть связана с контейнерной удаленной БД (CDB) через глобального пользователя или с подключаемой БД (PDB) через локального или глобального пользователя.
Пользователь удаленной БД, через которого настроена связь (database link) должен иметь привилегии CREATE PLUGGABLE DATABASE.
Локальная и удаленная БД должны иметь одинаковые разрядности, установленные опции и кодировки.
В случае клонирования non-CDB, обе БД должны иметь версию не ниже 12.1.0.2.

Подготовка локальной БД (CDB)

Устанавливаем переменные окружения в ОС с локальной БД.

Создаем локальную контейнерную БД (CDB).

Клонирование удаленной подключаемой БД (PDB)

Через удаленный терминал (ssh) заходим на сервер с удаленной БД (CDB) и настраиваем переменные окружения.

Соединяемся с БД.

Создаем пользователя для удаленного соединения с разрешением клонирования (в данном примере будет использоваться локальный пользователь).

Переводим подключаемую БД (PDB) в режим read-only.

Через удаленный терминал (ssh) заходим на сервер с локальной БД (CDB) и настраиваем переменные окружения.

Определяем строку соединения (tnsname) с удаленной подключаемой БД (PDB)

Соединяемся с локальной БД (CDB).

Создаем ссылку для соединения с удаленной БД (remote database link с PDB) и проверяем ее.

Если использование автоматического управления файлами невозможно, то при запуске данной команды мы получим ошибку:

Если на удаленной БД не используется автоматическое управление файлами (OMF) можно определить общее правило, определяющее расположение директорий с файлами данных на удаленной и локальной БД:

Если же OMF используется, то может возникнуть ошибка:

В таком случае необходимо определить правило конвертации для каждого файла данных:

Запускаем созданную БД (PDB). После клонирования новая локальная подключаемая БД (PDB) находится в состоянии MOUNTED.

Для завершения процесса необходимо открыть смонтированную БД в режиме чтение-запись.

Клонирование удаленной неконтейнерной БД (Non-CDB)

Через удаленный терминал (ssh) заходим на сервер с удаленной БД (Non-CDB), настраиваем переменные окружения и устанавливаем соединение с Non-CDB.

Создаем пользователя для удаленного соединения с разрешением клонирования.

Переводим удаленную БД (Non-CDB) в режим read-only.

Через удаленный терминал (ssh) заходим на сервер с локальной БД (CDB), настраиваем переменные окружения и устанавливаем соединение с CDB.

Определяем строку соединения (tnsname) с удаленной БД (Non-CDB).

Создаем ссылку для соединения с удаленной БД (remote database link с Non-CDB) и проверяем ее.

Самым крупным нововведением недавно вышедшего Oracle 12c безусловно является Multitenant Architecture. Сам Oracle преподносит эту возможность в основном как средство консолидации и снижения расходов.

Суть технологии состоит в возможности запустить несколько независимых баз (pluggable database, PDB) в рамках одного инстанса (container database, CDB). Каждая база имеет свой набор схем и табличных пространств, но при этом у них общая SGA и один набор серверных процессов. Есть возможность клонировать pluggable database, как в рамках одного контейнера, так и между контейнерами. Вот эту возможность и будем использовать для создания копий тестовых баз и экономии ресурсов.

Задача — имеем большую систему, с большой базой. Нужно проводить тестирование изменений, причем изменений разрушительных — удаление/модификация таблиц. Как это делается сейчас — создаем новую базу, заливаем в нее минимально возможный набор схем и данных и проводим тестирование. Процесс сам по себе не быстрый, трудоемкий и всегда есть возможность ошибиться. Да и «минимальный набор данных» может быть не таким уж и маленьким.

В документации на команду CREATE PLUGGABLE DATABASE, в разделе клонирования есть упоминание об опции SNAPSHOT COPY. Судя по описанию, при создании клона с опцией SNAPSHOT COPY, файлы данных клонируемой базы копироваться не будут. Для них будут
созданы copy on write снапшоты и место на диске будут занимать только измененные блоки клонированной базы. Создание клонов со снапшотами возможно либо на ACFS, либо на специализированных NAS .

Эксперимент проводился в среде Oracle Virtualbox 4.2.14. Я не буду подробно описывать инсталляцию, она хорошо освещена в документации, буду останавливаться только на важных моментах.

Инсталляция

Ставим Oracle linux 6.4 c апдейтами, зависимости для oracle и поддержку ASM:

конфигурируем ASM и создаем ASM disk:

Инсталлируем Oracle Database 12c Release 1 Grid Infrastructure (12.1.0.1.0) for Linux x86-64 в режиме singl node. В discovery path -> /dev/oracleasm/disks.
Командами asmcmd или с помощью asmca создаем disk group (DATA) volume (DATAVOL) и ASM cluster filesystem c точкой монтирования (/data). Из под root монтируем ACFS и убеждаемся что все хорошо:

Подключаемся к инстансу ASM и меняем режим совместимости:

В результате получаем базу-контейнер и с seed database (модельная база для создания pluggable database).
Проверяем что все получилось:

Работа с клонами

Создаем каталог на ACFS /data/oradata, и меняем владельца на oracle. Меняем параметр db_create_file_dest на /data/oradata. Cоздаем клон который будет изображать тестовую базу:

На ACFS должен появиться каталог с буквенно-цифровым именем (случайным), содержащий наш PDB:

PDB после создания или рестарта контейнера нужно открывать:

Имитируем создание тестовой базы — создадим tablespace test размером 2G:

Убеждаемся что файл данных есть и размер его 2 гигабайта:

Ради чего все это затевалось

Мы имеем тестовую базу большого объема и хотим протестировать особо крупное изменение, затрагивающее структуру таблиц и требующее для проверки всех данных.
Клонируем тестовую базу в режиме snapshot:

И смотрим что произошло на файловой системе:

Файлы данных всех табличных пространств кроме TEMP это ссылки на ACFS снапшот, и место на диске они не занимают. Узнать сколько реально занял снапшот можно так:

Чего и добивались — 286МB против более 3GB

Естественно, если активно начать изменять блоки клона со снапшотами, занимаемое им место вырастет.

После того как провели тестирование, удаляем ненужный клон:

Убеждаемся что место освободилось:

Результат

В результате нам удалось сэкономить время и ресурсы. И не только дисковые, напомню, что все базы PDB используют один комплект процессов и одну SGA.

PS. Статья не претендует на полное описание Oracle Multitenant Architecture, рассмотрен лишь частный случай применительно к конкретной задаче.

Зачастую в организациях используется большое количество баз данных разных размеров, типов нагрузки, объёмов и критичности. При большом количестве баз данных мало внимания уделяется именно небольшим по объёмам, тестовым, а также предназначенным для разработчиков

Перед администраторами баз данных возникает ряд проблем, которые необходимо решать:

Улучшение утилизации ресурсов;
Упрощение управления (управление большим количеством как единым целым);
Стандартизация процедур и уровней обслуживания;
Быстрое развертывание новых баз данных;
Простота создания development / testing окружений;
Мобильность баз данных;
Масштабируемость баз данных;
Возможность консолидации баз данных без внесения изменений в приложения.

Эффективность консолидации

Традиционно для консолидации баз данных используются три разновидности подходов:

Виртуализация;
Instance Caging – несколько разных экземпляров баз данных на сервере;
Консолидация с помощью схем.

Но все эти подходы ведут к накладным расходам по вычислительным ресурсам, а зачастую (при консолидации с помощью схем) вынуждают к внесению изменений в приложения. Из-за накладных расходов и усложнения решения мы имеем плохую плотность консолидации, увеличенные затраты на обслуживание, вследствие чего увеличивается стоимость разработки. Oracle Multitenant упрощает процесс консолидации, поскольку мы можем подключать базы данных в контейнерную БД, при этом не требуется никаких изменений в приложении. В новой Oracle Multitenant архитектуре (рис. 1) память и фоновые процессы нужны только для контейнерной базы данных, что позволяет добиться более высокого уровня масштабируемости и большей плотности консолидации.

Быстрое развертывание баз данных

Для многих компаний довольно проблематичным и трудоёмким является создание и клонирование баз данных для тестирования, разработки и диагностики. Администратор БД может потратить довольно большое количество времени на клонирование или миграцию баз данных между разными операционными системами, например, Windows и Solaris. Oracle Multitenant позволяет быстро создавать, клонировать, а также выполнять кросс-платформенные миграции. Кроме того некоторые файловые системы такие, как ZFS, ASM Cluster Filesystem поддерживают «copy on write» механизм, то есть тестовые базы данных будут создаваться практически мгновенно.

Упрощенное обновление

Каждый администратор должен поддерживать рекомендуемый уровень обновлений для всех баз данных в организации. В настоящее время обновления применяются для каждой базы данных отдельно, включая тестовые и базы данных для разработчиков. С помощью Oracle Multitenant обновления и исправления применяются на уровне контейнерной базы данных, то есть один раз. Такой подход упрощает обновление баз данных и уменьшает время их простоя, поскольку не нужно обновлять каждую встроенную БД отдельно. Если администратор хочет выборочно обновить подключаемые базы данных, ему достаточно создать контейнерную базу данных новой версии и переподключить к ней необходимые подключаемые БД.

Упрощенное управление (большим количеством как единым целым)

Помимо очевидного преимущества в обновлении консолидированных баз данных – меньшего их количества – есть и ряд других преимуществ. Например, вместо того, чтобы резервировать каждую базу данных отдельно, резервируется весь контейнер вместе с подключаемыми базами данных в нём, то есть проверять успешность резервирования необходимо один раз, а не для каждой по отдельности, а восстанавливать их можно на уровне подключаемых баз данных или на уровне всего контейнера. Создание резервной базы данных тоже выполняется на уровне контейнера, например, если вам необходимо, чтобы все подключаемые БД имели горячую физическую резервную копию (standby), он настраивается для уровня контейнера, при создании в нём новой подключаемой базы данных, в которой автоматически будет создана резервная копия. Ко всему прочему, очень сильно переработан Resource Manager, который отныне может на уровне контейнера управлять распределением ресурсов между подключаемыми базами данных:

количеством одновременных сессий;
потребляемыми ресурсами процессора;
возможностью использования параллельных процессов Oracle Server;
файловым вводом / выводом, но только на Exadata!

Resource Manager не контролирует использование SGA и выделение PGA, поскольку память у всех подключаемых баз данных общая.

Путь в Oracle Multitenat

Консолидировать базы данных в Oracle Multitenant очень просто. Администраторы могут обновить базу данных до версии 12, а затем подключить её в контейнерную базу данных, также можно использовать Oracle Data Pump или GoldenGate для миграции базы данных в подключаемую. Администраторы могут использовать Oracle Enterprise Manager Cloud Control как единое средство управления всеми базами данных, начиная от создания до распределения ресурсов между БД и диагностики проблем. Возможности Oracle Multitenant архитектуры также расширяются при использовании Oracle Real Application Clusters и Active Data Guard.

Новая опция Oracle Multitenant позволяет пользователям с лёгкостью консолидировать базы данных без внесения изменений в приложения. Эта архитектура предоставляет централизованное управление консолидированными базами данных как единым целым, позволяет управлять распределением ресурсов и расстановкой приоритетов для отдельных баз данных. Oracle Multitenant предоставляет функциональные возможности для быстрого создания баз данных, миграций, обновления и др.

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 12c - это многозадачные базы данных. Они также стали известны как подключаемые базы данных. Если вы не слышали о облаке, вы должны были жить под скалой последние несколько лет. c в 12c означает облако.

В наши дни обслуживание облачных вычислений и приложений в облаке. Это уменьшает капитальные затраты для корпораций и имеет немедленные налоговые льготы. Поэтому у компаний есть много стимулов для использования облачных вычислений.

Одна из технологий, которая действительно взлетела с революцией облачных вычислений, - это виртуализация. Использование виртуальных машин, вырезанных из более крупных физических машин и использование дробного лицензирования, еще больше снижает затраты корпораций. Были разработаны базы данных Oracle с множеством тренда, чтобы помочь компаниям воспользоваться всеми этими технологиями и сэкономить средства.

Опция Multitenant для Oracle 12c лицензируется. Как обычно, обратитесь к представителю отдела продаж Oracle за расходами. Опять же, убедитесь, что вы знаете о возврате инвестиций, которые эта функция может принести вам.

Вам нужно знать о новых типах баз данных, которые теперь являются частью многоуровневой архитектуры:

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

Pluggable Database (PDB): Набор объектов схемы, объектов и объектов, которые могут быть подключены и отсоединены от базы данных контейнера. PDB представляется OracleNet и конечным пользователям как сама база данных, но фактически управляется внутри контейнера, который может иметь много PDB.

База данных семян (Seed PDB): PDB по умолчанию, который система использует в качестве шаблона для быстрого предоставления других пользовательских PDB. Внутри это называется PDB $ SEED.

Параметр Multitenant позволяет выполнить следующее:

Высокая плотность консолидации: Многие базы данных могут совместно использовать память и фоновые процессы.

Предоставление: База данных может быть отключена от одной среды и подключена к другой или клонирована командами SQL всего за несколько секунд. Их можно даже подключить к операционным системам и наборам микросхем.

Управление несколькими базами данных как один: Вы можете выполнять такие задачи, как резервное копирование и исправление в основной базе данных контейнера вместо отдельных подключаемых баз данных.

Управление ресурсами: Функция Oracle Resource Manager может работать на уровне подключаемых баз данных для управления конкуренцией ресурсов между базами данных в вашей среде.

Еще одна вещь, о которой стоит упомянуть, заключается в том, что подключаемая база данных полностью совместима с не-CDB. Фактически, у Oracle есть что-то, что он называет гарантией совместимости с PDB / non-CDB, , в котором говорится, что все, что вы делали бы в не-CDB, также будет работать в PDB. Эта гарантия совместимости важна, когда речь заходит о сертификации таких продуктов, как сторонние продукты-производители, для работы в многопользовательской архитектуре.

Как создать среду многопользовательской базы данных в Oracle 12c

При создании базы данных вы должны назначить ее как CDB или не-CDB, чтобы иметь возможность поддерживать многозадачную архитектуру. В следующем наборе примеров описываются этапы создания базы данных контейнеров с DBCA. Существует только один шаг, который отличает CDB от не-CDB при использовании DBCA.

Следуя расширенному пути создания базы данных, первое, что вы можете заметить, это флажок для базы данных Create As Container на шаге 4 из 13.

Вы также можете выбрать количество созданных PDB в это время. Вы также можете создать пустую базу данных контейнера без подключаемых баз данных в начале. Остальные этапы почти такие же, как при создании не-CDB.

Как запускать и останавливать подключаемые базы данных в Oracle 12c

Поскольку архитектура экземпляров подключаемых баз данных полностью отличается от базы данных, не содержащей контейнеров, можно предположить, что управление их состоянием готовности также отличается. Ну, это правда. Давайте начнем с рассмотрения самого CDB.

Первое, что нужно помнить, состоит в том, что, поскольку CDB поддерживает экземпляр, для которого все PDB совместно используют, этот экземпляр должен быть открыт и открыт для людей, чтобы иметь возможность подключаться к PDB. Запуск и остановка CDB не отличается от не-CDB.

Следующее, что нужно помнить, это то, что при запуске CDB все связанные с ним PDB остаются в состоянии MOUNT, а это значит, что по умолчанию они не открываются CDB. К сожалению, 12cR1 не предлагает вариант изменить это поведение.

Однако 12c действительно обеспечивает запуск нового типа триггера, который будет срабатывать, если он обнаружит открытие CDB и затем откроет определенные PDB. Дополнительную информацию по настройке см. В документации Oracle.

После запуска и открытия CDB вы можете открыть любые соответствующие PDB следующим образом:

Чтобы закрыть PDB, вы можете по существу сделать противоположное предыдущим командам:

Вы можете использовать представление словаря данных V $ PDBS для получения информации о готовности PDB.

Читайте также: