home \ Oracle. Database Concepts
Написано: 24.12.2022

3. Контейнеры для приложений

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

О контейнерах приложений

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

В контейнере приложения, приложение – это именованный версионный набор общих данных и метаданных, хранящихся в корневом приложении. В данном контексте контейнера приложения, термин “приложение” означает ”определение master-приложения”. Например, приложение может включать определения таблиц, представлений и пакетов.

Например, можно в одном контейнере приложения создать несколько PDB, связанных с продажами, при этом эти PDB будут совместно использовать приложение, состоящее из набора общих таблиц и определений таблиц. Можно в отдельном контейнере приложения хранить несколько PDB, связанных с персоналом, с их собственными общими таблицами и определениями таблиц.

Инструкция CREATE PLUGGABLE DATABASE с предложением AS APPLICATION CONTAINER создает корневое приложение для контейнера приложения и, таким образом, неявно создает сам контейнер приложения. Когда впервые создаете контейнер приложения, в нем нет PDB. Чтобы создать PDB, нужно подключиться к корневому приложению, а затем выполнить инструкцию CREATE PLUGGABLE DATABASE.

В инструкции CREATE PLUGGABLE DATABASE необходимо указать имя контейнера (которое совпадает с именем корневого приложения), например, saas_sales_ac. Имя контейнера приложения должно быть уникальным в пределах CDB и в пределах области действия всех CDB, экземпляры которых доступны через определенный прослушиватель. Каждый контейнер приложения имеет службу по умолчанию с тем же именем, что и контейнер приложения.

Назначение контейнеров приложений

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

Корневое приложение позволяет приложениям PDB совместно использовать приложение, что в данном контексте означает именованный, версионный набор общих метаданных и данных. Типичное приложение устанавливает общих пользователей приложения, общие объекты, связанные с метаданными, и общие объекты, связанные с данными.

Основные преимущества контейнеров для приложений

Контейнеры приложений предоставляют несколько преимуществ по сравнению с хранением каждого приложения в отдельной PDB.

  • В корневом приложении хранятся метаданные и данные, которыми могут совместно пользоваться все PDB приложения.

    Например, все PDB приложений могут совместно использовать данные в центральной таблице, такой как таблица, в которой перечислены роли приложений по умолчанию. Кроме того, все PDB могут совместно использовать определение таблицы, к которому они добавляют строки, специфичные для PDB.

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

    Если вы обновляете приложение в корневом приложении, то изменения автоматически распространяются на все PDB приложения. Серверная часть приложения может содержать общий объект, связанный с данными, app_roles, который представляет собой таблицу, где перечислены роли по умолчанию: admin, manager, sales_rep и так далее. Пользователь, подключенный к PDB любого приложения, может запросить эту таблицу.

  • Контейнер приложения может включать в себя seed-приложения, PDB приложения и прокси-PDB (которые ссылаются на PDB в других CDB).

  • Можно быстро создавать новые PDB приложения из seed-приложения.

  • Можно запросить представление, оповещающее обо всех PDB в контейнере приложения.

  • При подключении к корневому приложению, можно использовать функцию CONTAINERS для выполнения DML над объектами в нескольких PDB.

    Например, если таблица products существует в каждом PDB приложения, можно подключиться к корневому приложению и запросить продукты во всех PDB приложения, используя одну инструкцию SELECT.

  • Можно отключить PDB от корневого приложения, а затем подключить его к корневому приложению в новой версии БД Oracle. Таким образом, PDB полезны при обновлении БД Oracle.

Пример использования контейнера приложения: SaaS

Развертывание SaaS может использовать несколько PDB приложений, каждый для отдельного клиента, которые совместно используют метаданные и данные.

В чистой среде SaaS определение главного приложения находится в корневом приложении, но данные, относящиеся к конкретному клиенту, находятся в его собственном PDB. Например, sales_app – это модель приложения в корневом каталоге приложения. PDB с именем cust1_pdb содержит данные о продажах только для клиента 1, тогда как PDB с именем cust2_pdb содержит данные о продажах только для клиента 2. Подключение, отсоединение, клонирование и другие операции на уровне PDB доступны для отдельных клиентских PDB.

OraCon_Fig3-1

Чистая конфигурация SaaS обеспечивает следующие преимущества:

  • Эффективность

  • Безопасность

  • Поддержка нескольких клиентов

    Данные для каждого клиента хранятся в отдельном контейнере, но консолидированы, так что можно управлять многими клиентами коллективно. Эта модель расширяет эффект масштаба от управления многими как одним для администратора приложения, а не только для администратора БД.

Пример использования контейнеров приложений: Логическое хранилище данных

Клиент может использовать несколько PDB для решения проблем с независимостью данных.

В этом примере, компания помещает данные, относящиеся к каждому финансовому кварталу, в отдельный PDB. Например, контейнер приложения с именем sales_ac включает q1_2016_pdb, q2_2016_pdb, q3_2016_pdb и q4_2016_pdb. Вы определяете каждую транзакцию в PDB, соответствующую отдельному кварталу. Чтобы сгенерировать отчет, который агрегирует производительность за год, вы агрегируете данные по четырем PDB, используя предложение CONTAINERS().

Преимущества такого дизайна для логического хрпнения включают:

  • ETL для данных, специфичных для одной PDB, не влияет на другие PDB.

  • Планы выполнения более эффективны, поскольку они основаны на фактическом распределении данных.

Корневое приложения

Контейнер приложения имеет ровно одно корневое приложение, которое является родительским для PDB в контейнере.

Свойство быть корневым приложением устанавливается во время создания и не может быть изменено. Единственным контейнером, к которому принадлежит корневое приложение, является корневой CDB. Корневое приложение в некоторых отношениях похож на корневой CDB, а в других – на PDB:

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

  • Как и для PDB, корневое приложение создаётся инструкцией CREATE PLUGGABLE DATABASE, изменяется с помощью ALTER PLUGGABLE DATABASE, доступность меняется через STARTUP и SHUTDOWN. Можно использовать DDL для подключения, отсоединения и удаления корневого приложения. Кореневое приложение имеет свое собственное служебное имя, и пользователи могут подключаться к корневому приложения таким же образом, как подключаются к PDB.

Корневое приложение отличается как от корневого CDB, так и от стандартного PDB, поскольку в нем могут храниться общие объекты, созданные пользователем, которые называются общими объектами приложения. Общие объекты приложения доступны для PDB, подключенных к корневому приложению. Общие объекты приложения не видны корневому CDB, другим корневым приложениям или PDB, которые не принадлежат корневому приложению.

Пример 3-1 Создание корневого приложения

В этом примере, вы входите в корневой CDB общим пользователем-администратором c##system. Вы создаете контейнер приложения с именем saas_sales_ac, а затем открываете корневое приложение, которое имеет то же имя, что и контейнер.

-- Create the application container called saas_sales_ac
CREATE PLUGGABLE DATABASE saas_sales_ac AS APPLICATION CONTAINER
  ADMIN USER saas_sales_ac_adm IDENTIFIED BY manager; 

-- Open the application root
ALTER PLUGGABLE DATABASE saas_sales_ac OPEN;

Вы устанавливаете для текущего контейнера значение saas_sales_ac, а затем проверяете, что этот контейнер является корневым приложением:

-- Set the current container to saas_sales_ac
ALTER SESSION SET CONTAINER = saas_sales_ac;

COL NAME FORMAT a15
COL ROOT FORMAT a4
SELECT CON_ID, NAME, APPLICATION_ROOT AS ROOT, 
       APPLICATION_PDB AS PDB,
FROM   V$CONTAINERS;

    CON_ID NAME            ROOT PDB
---------- --------------- ---- ---
         3 SAAS_SALES_AC   YES	NO

PDB приложения

PDB приложения – это PDB, который находится в контейнере приложения. Каждая PDB в CDB находится либо в нулевом, либо в одном контейнере приложений.

Например, контейнер приложений saas_sales_ac может поддерживать несколько клиентов, при этом каждое клиентское приложение хранит свои данные в отдельном PDB. PDB cust1_sales_pdb и cust2_sales_pdb могут находиться в saas_sales_ac, и в этом случае они не принадлежат никакому другому контейнеру приложений (хотя как PDB они обязательно принадлежат также корневому CDB).

Создаётся PDB приложения командой CREATE PLUGGABLE DATABASE при подключении к корневому приложению. Можно либо создать PDB приложения из seed-а, либо клонировать PDB или подключить отключенный PDB. Подобно PDB, подключенному к корневому CDB, можно клонировать, отключать или удалять PDB приложения. Однако PDB приложения всегда должна принадлежать корневому приложению.

Seed-приложения

Seed-приложения – это необязательный, пользовательский PDB в контейнере приложения. В контейнере приложения либо нет, либо один Seed-приложения.

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

Имя seed-приложения всегда называется так: application_container_name$SEED, где application_container_name – это имя контейнера приложения. Например, для создания saas_sales_ac$SEED в контейнере приложения saas_sales_ac используйтся инструкция CREATE PDB ... AS SEED.

Общие объекты приложения

Общий объект приложения – это общий объект, созданный внутри приложения в корневом приложении. Общие объекты связаны либо с данными, либо с метаданными.

Для общего объекта, связанного с данными, PDB приложений совместно используют один набор данных. Например, для контейнера приложений saas_sales_ac приложение называется saas_sales_app, имеет версию 1.0 и включает таблицу usa_zipcodes, связанную с данными. В этом случае, строки сохраняются единожды в таблице корневого приложения, но видны всем PDB приложения.

Для **общего объекта, связанного с метаданными, PDB приложений совместно используют только метаданные, но содержат разные наборы данных. Например, таблица продуктов, связанная с метаданными, имеет одно и то же определение в каждой PDB приложения, но сами строки специфичны для PDB. База данных приложения с именем cust1pdb может иметь таблицу продуктов, содержащую книги, в то время как база данных приложения с именем cust2pdb может иметь таблицу продуктов, содержащую автозапчасти.

Об общности в CDB

Феномен общности, определённый в CDB или в корневом приложении, является одиноковым для всех контейнеров, к нему подключённых.

Принципы общности

В CDB феномен может быть общим либо внутри системного контейнера (самого CDB), либо внутри определенного контейнера приложения.

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

В контексте CDB$ROOT или корневого приложения принципы общности заключаются в следующем:

  • Общий феномен является одним и тем же в каждом существующем и будущем контейнере.

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

  • Только общий пользователь может изменить существование общего феномена.

    Точнее, только общий пользователь, вошедший в корневой CDB или корневое приложение, может создавать, уничтожать или изменять атрибуты пользователя, роли или объекта, которые являются общими для текущего контейнера.

Именованные пространства в CDB

В CDB пространство имен для каждого объекта ограничено его контейнером.

Создание общих объектов приложения

Общие объекты приложений, связанные с метаданными

Общие объекты приложений, связанные с расширенными данными

Карты контейнера

Между-контейнерные операции