Как подключиться к pdb oracle

Обновлено: 06.07.2024

Ниже приводится содержимое моего файла tnsnames.ora:

Вот содержимое моего файла listener.ora:

Кстати это контейнеры:

Тем не менее, когда я пытаюсь подключиться к PDB с помощью любой комбинации команд, это то, что я получаю:

О, я должен ясно дать понять, что использую порт 1523, потому что в системе уже работает другой экземпляр более старого Oracle 10g, который использует этот порт, поэтому я хотел избежать любого конфликта с ним.

2 ответа

Ниже мой конфиг который работает:

listener.ora:

LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = имя хоста)(PORT = 1525)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1525)) ) )

tnsnames.ora:

LISTENER_CATCDB = (ADDRESS = (PROTOCOL = TCP)(HOST = имя хоста)(PORT = 1526))

CATCDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = имя хоста)(PORT = 1526)) (CONNECT_DATA = (SERVER = DEDICATED) (ИМЯ_СЛУЖБЫ = catcdb) ) )

CATDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = имя хоста)(PORT = 1526)) (CONNECT_DATA = (SERVER = DEDICATED) (ИМЯ_СЛУЖБЫ = catdb) ) )

Вы не должны объявлять службы в SID_LIST_LISTENER. Особенно pdborcl, который является не экземпляром, а службой внутри экземпляра. Так что уберите эту часть:

Экземпляр должен зарегистрироваться для прослушивателя. Если вы этого не сделали, то должны сделать это при подключении к CDB:

Похожие вопросы:

Что такое команда SQL для возврата списка PDB и CDB в Oracle?

У меня есть файл .dmp, созданный с Oracle 10g, содержащий базу данных одного из моих клиентов. Я ни за что на свете не смогу настроить его с помощью моей установки 12С. Я могу подключиться к своей.

В чем разница между системными таблицами ALL_TAB_COLUMNS и ALL_TAB_COLS в Oracle 12С? В моем DB ALL_TAB_COLUMNS имеет немного меньше строк, чем ALL_TAB_COLS.

Как пройти процедуру BOOLEAN - Oracle в 12С? Я слышал, что это было невозможно до 12С, но я все еще не могу сделать это в 12С. //.

У меня есть установка Oracle 12c на машине Windows Server 2012. он имеет один PDB (PDBORCL). Я создал пользователя в этом PDB и могу подключиться к нему с клиентской машины через SQL Developer.

Я только что установил свой Oracle 12c, успешно подключил его к базе данных. Я не смог создать пользователя (в CDB). Итак, я попытался создать имя пользователя через PDB. Но даже PDB не работает. Я.

Я использую XAMPP v3.2.2 и пытаюсь подключиться от PHP к Oracle базе данных 12c. Я уже прокомментировал расширение php_oci8_12c.dll в php.ini, перезапустил Apache и установил Oracle.

Я создал образец Oracle 12c PDB (подключаемая база данных), используя инструкции отсюда . Как мне подключиться к этой подключаемой базе данных с помощью приложения Hibernate? Я использую образец.

В посте рассматривается способ разблокировки и доступа к учебному и тестовому пользователю (схемы) HR в базе данных Oracle Database 18c Express Edition. Рассмотрены следующие вопросы:

  • Краткий обзор Multitenant архитектуры
  • Разблокировка пользователя HR
  • Multitenant
  • Flashback Table
  • Flashback Database
  • Oracle Partitioning
  • In-Memory Column Store и Aggregation
  • Advanced Analytics и Security
  • Online Index Rebuild
  • Online Table Redefinition
  • Query Results Cache и PL/SQL Function Result Cache
  • Oracle Advanced Compression
  • Materialized View Query Rewrite
  • Oracle Spatial and Graph
  • Bitmap Indexes

Разблокировка пользователя (схемы) HR

Предполагается, что есть успешно установленная Oracle Database 18c Express Edition. При необходимости, можно установить Oracle Database 18c Express Edition используя следующие материалы: установка Oracle Database 18c Express Edition на Linux и установка Oracle Database 18c Express Edition на Windows. Нижеописанные шаги будут работать с Oracle Database 18c Express Edition, установленной, как на операционную систему Linux, так и на Windows.

Вариант разблокировки с помощью SQL*Plus.

Шаг 1. Подключение к CDB

Выполняется подключение к CDB с помощью пользователя sys с ролью as sysdba:

Подключение успешно прошло к CDB. Далее проверяется имя и идентификатор CDB.

Результат запроса показывает, что CDB имеет имя XE и ее уникальный идентификатор = 0. По умолчанию, после установки Oracle Database 18c Express Edition есть одна PDB с именем XEPDB1. Следующий запрос покажет существующие PDB.

Проверяется наличие пользователя HR в CDB.

Запрос не вернул данные. Это означает, что пользователя HR нет в CDB. Далее необходимо подключиться к PDB и найти там HR.

Шаг 2. Подключение к PDB

Есть два способа подключиться к PDB с использованием SQL*Plus.

Способ 1. Находясь в CDB, подключиться к PDB используя команду alter session. В примере ниже происходит переключение из сеанса CDB к PDB с именем XEPDB1:

Переключение прошло успешно. Для того, чтобы удостовериться в корректности подключения, проверяется имя и идентификатор PDB базы:

Запросы показывают характеристики существующей PDB (Шаг 1.).

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

Ниже выполняется подключение к PDB под пользователем sys с указанием IP адреса сервера БД, порта и имени PDB (по умолчанию для созданной PDB (XEPDB1) используется порт 1539):

Подключение прошло успешно.

Для информации: Администраторы баз данных временами выполняют подключение к БД используя аутентификацию на уровне операционной системы с помощью команды sqlplus / as sysdba и без указания пароля. При запуске этой команды в среде с Multitenant архитектурой будет осуществлено подключение к CDB. Для того, чтобы напрямую подключиться к PDB минуя CDB, используется sqlplus / as sysdba и без указания пароля, также необходимо в переменную среду операционной системы добавить новый системный параметр ORACLE_PDB_SID и в его значении указать название PDB. Этот параметр для подключения к PDB без указания пароля могут осуществлять только пользователи sys и system. Остальные пользователи будут автоматически подключены к CDB, если не укажут параметры подключения к PDB. Ниже описываются шаги подключения к PDB для пользователя sys с применением параметра ORACLE_PDB_SID в переменной среде операционной системы. Это очень удобный способ для администраторов баз данных:

Подключение к PDB прошло успешно напрямую из операционной системы без указания пароля и параметров подключения PDB. Далее проверяется имя и идентификатор PDB.

После успешного подключения к PDB c использованием одного из двух способов определяется наличие пользователя HR, а также его статус.

Запускается запрос поиска пользователя HR среди всех существующих пользователей в XEPDB1:

Получен результат, подтверждающий наличие пользователя HR в PDB.

При помощи запроса определяется имя, статус и дата блокировки пользователя HR:

Шаг 3. Разблокировка пользователя HR

После установки Oracle Database 18c Express Edition учетная запись HR заблокирована и пароль у нее просрочен (необходимо задать новый пароль) (см. предыдущий шаг – Шаг 2.). В этом случае, система позволяет сделать запросы к объектам HR (таблицам, представлениям, функциям и т.п.) от имени других пользователей при наличии соответствующих привилегий. Например, при выполнении запроса на определение количества строк в таблице EMPLOYEES пользователя HR под пользователем SYS система успешно выдаст следующий результат:

Для пользователя HR назначается новый пароль:

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

Необходимо заново подключиться к PDB под пользователем sys:

и разблокировать пользователя HR следующей командой:

Операции назначения пароля и разблокировки пользователя HR прошли успешно. Проверяется статус пользователя:

Пользователь HR разблокирован и новый пароль активен. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Используя данные для подключения к PDB, выполняется вход систему под учетной записью HR и запускается запрос для определения количества строк в его таблице EMPLOYEES.

На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL*Plus.

Вариант разблокировки с помощью SQL Developer.

Шаг 1. Подключение к CDB

Для этого создается новое подключение в SQL Developer и указываются необходимые параметры подключения к CDB, такие как:

Name: XE_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать CDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XE
SID или имя CDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных.


После нажатия Connect произойдет успешное подключение к CDB с именем XE. Далее проверяется имя, идентификатор и версия CDB, а также выводятся существующие PDB.


Как и ожидалось, выведенные выше данные идентичны полученным с помощью SQL*Plus.

Далее проверяется наличие пользователя HR в CDB.


Запрос не вернул данные, это означает, что пользователя HR нет в CDB. Теперь необходимо подключиться к PDB и проверить наличие HR в PDB.

Шаг 2. Подключение к PDB

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1, такие как:

Name: XEPDB1_18c
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: sys
Указывается имя пользователя для подключения к БД.

Role: SYSDBA
Подключение к БД осуществляется пользователем sys. Данный пользователь может подключиться только с ролью SYSDBA.

Password:
Пароль пользователя sys, который был назначен во время установки базы данных. Пользователи sys и system могут подключиться с одним и тем же паролем и к CDB и к PDB.


После нажатия Connect произойдет успешное подключение к подключаемой БД XEPDB1. Далее проверяется имя и идентификатор.


Результаты показывают, что было подключение к PDB с именем XEPDB1 и идентификатором 3. Определяется наличие пользователя HR в этой PDB. В иерархии дерева надо выбрать «Other Users» в соединении с именем XEPDB1_18c как показано на скриншоте:


В списке пользователей необходимо найти пользователя HR и нажать на правую кнопку. Из контекстного меню выбрать «Edit User». Откроется новое модальное окно «Edit User» как показано на скриншоте. Как видно на скриншоте учетная запись HR заблокирована (Account is Locked) и пароль у нее просрочен (Password Expired):


Шаг 3. Разблокировка пользователя HR:

В продолжение предыдущего шага необходимо:

  1. Задать идентичный пароль в полях New Password (новый пароль) и Confirm Password (подтвердить пароль).
  2. Снять галочку из пункта Password Expired (user must change next login).
  3. Снять галочку из пункта Account is Locked для разблокировки пользователя.
  4. Нажать Apply.

Пользователь HR разблокирован и ему назначен пароль. Это означает, что теперь можно подключиться к PDB с именем XEPDB1 под учебным тестовым пользователем HR и начать работу.

Шаг 4. Подключение к PDB с учетной записью HR.

Создается новое подключение в SQL Developer и указываются необходимые параметры подключения к подключаемой базе данных XEPDB1 с пользователем HR, такие как:

Name: XEPDB1_18c_hr
Указывается имя соединения, которое позволяет однозначно идентифицировать PDB при подключении с пользователем HR.

IP: 192.168.0.1
IP адрес сервера БД.

Port: 1539
Порт подключения к БД.

SID: XEPDB1
SID или имя PDB.

Username: HR
Указывается имя пользователя для подключения к БД.

Role: default
Подключение к БД осуществляется пользователем HR. Данный пользователь не может использовать роль SYSDBA.

Password:
Пароль, который был назначен пользователю HR на третьем шаге, то есть hr.


После нажатия Connect произойдет успешное подключение к PDB с именем XEPDB1 под пользователем HR. Выполняется запрос для определения количества строк в таблице EMPLOYEES:


На этом завершается определение наличия пользователя, назначение ему пароля и разблокировка HR в PDB Oracle Database 18c Express Edition, а также выполнение запроса к его объекту с помощью SQL Developer.

Сводка: Наша задача — предоставлять решения для упрощения ИТ-инфраструктуры, предлагая решения для баз данных, специализированную разработку, динамические ЦОД и гибкие вычислительные системы. Свернуть Наша задача — предоставлять решения для упрощения ИТ-инфраструктуры, предлагая решения для баз данных, специализированную разработку, динамические ЦОД и гибкие Развернуть

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

Симптомы

Затронутые решения:

Oracle Database — Oracle 12cR1 12.1.0.1.0 Enterprise Edition

Операционные системы — Oracle Linux 6.4 с ядром 2.6.39-400.109.17.1.el6uek.x86-64 и

Платформы хранения данных — Dell EqualLogic PS 5000 и Dell EqualLogic PS 6110

Проблема:

Как подключиться к подключаемым базам данных в Oracle RAC 12cR1?

Решение:

  1. Использование службы по умолчанию с тем же именем, что и имя базы данных, которая создается автоматически программным обеспечением базы данных.
  2. Использование определенных пользователем служб, созданных со свойством PDB с помощью утилиты SRVCTL, которая связывает службу с подключаемыми базами данных
  3. Использование команды «alter session» и установка необходимого контейнера
  4. Использование Enterprise Manager Express
  • В файле tnsnames.ora необходимо создать запись, которая определяет адреса баз данных, позволяющие установить соединение с базой данных.
  • Необходимо изменить состояние PDB с установленного на режим чтения и записи.

При использовании Oracle RAC 12c, хотя служба по умолчанию с тем же именем, что и подключаемая база данных, автоматически создается программным обеспечением базы данных, но файл tnsnames.ora создается только с одной записью, имеющей отношение к глобальной базе данных. Например, при использовании двухузлового Oracle RAC 12c, где «cpdb» — глобальная база данных, «pdb1» и «pdb2» — две созданные подключаемые базы данных, а «cpdb1» и «cpdb2» — два экземпляра, запись по умолчанию в файле tnsnames.ora приведена ниже:

(ADDRESS = (PROTOCOL = TCP)(HOST = OracleRACscan.dbase.lab)(PORT = 1521))

Поэтому необходимо создать соответствующие записи для имени службы по умолчанию подключаемых баз данных в файле tnsnames.ora, как показано ниже:

(ADDRESS = (PROTOCOL = TCP) (HOST = OracleRACscan.dbase.lab)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP) (HOST = OracleRACscan.dbase.lab)(PORT = 1521))

Изменение статуса подключаемой базы данных:

При создании блоков PDB по умолчанию для параметра «open_mode» установлено значение «Mounted». Это можно проверить следующим образом:

SQL> select name, open_mode from v$pdbs;

NAME OPEN_MODE PDB$SEED READ ONLY

Эта команда открывает все подключаемые базы данных в режиме чтения и записи.

SQL> Alter pluggable database all open;

После этогоможно установить подключение к базе данных с помощью sqlplus следующим образом:

[oracle@node1 bin]$ sqlplus sys/oracle@pdb1 as sysdba

SQL*Plus: версия 12.1.0.1.0, дата выпуска: 8 октября 2013 г., вторник, 11:23:32

© Oracle, 1982, 2013. Все права защищены.

Oracle Database 12c Enterprise Edition версия 12.1.0.1.0 — 64-разрядная производственная среда с разбиением на разделы, Real Application Clusters, Automatic Storage Management, OLAP, Advanced Analytics и Real Application Testing

2. Использование определенной пользователем службы для подключения к PDB

  1. создание службы базы данных со свойством PDB с помощью утилиты SRVCTL;
  2. создание записи в файле tnsnames.ora для созданной службы;
  3. запуск службы;
  4. подключение к базе данных с помощью службы со свойством PDB, созданным на шаге a.

Следующие команды, использующие утилиту SRVCTL, создают две службы базы данных «hr1» и «sales1» для связи с подключаемой базой данных «pdb1»:

[[oracle@node1 bin]$ srvctl add service -db cpdb -service hr1 -pdb pdb1 -preferred cpdb1 -available cpdb2

[oracle@node1 bin]$ srvctl add service -db cpdb -service sales1 -pdb pdb1 -preferred cpdb1 -available cpdb2

Свойство PDB можно просмотреть в представлении словаря данных all_services.

SQL> SELECT NAME, PDB FROM all_services;

Команда «$ srvctl config service –db » также содержит список доступных служб.

б) Создание записи в файле tnsnames.ora для созданной службы базы данных

Можно создать имена служб HR_PDB1 и SALES_PDB1, которые могут использоваться приложениями «hr» и «sales» для подключения к подключаемой базе данных «pdb1», следующим образом:

(ADDRESS = (PROTOCOL = TCP)(HOST = OracleRACscan.dbase.lab)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = OracleRACscan.dbase.lab)(PORT = 1521))

в) Запуск службы

[oracle@nsnode1 bin]$ srvctl status service -db cpdb -service hr1

Служба «hr1» не запущена

[oracle@nsnode1 bin]$ srvctl start service -db cpdb -service hr1

При запуске службы, связанной с PDB, автоматически открывается PDB в режиме чтения и записи.

г) Подключение к службе базы данных

Пользователь подключается к PDB с помощью службы базы данных со свойством «pdb».

Например, пользователь SYS может подключиться к «pdb1» с помощью службы базы данных HR_PDB1, связанной с «pdb1», следующим образом:

SQL> connect sys/oracle@HR_PDB1 AS SYSDBA

SQL> SHOW CON_ID;

SQL> SHOW CON_NAME;

3. Использование команды «alter session» для подключения к PDB

По умолчанию при подключении к экземпляру RAC выполняется подключение к CDB$ROOT. Каждый экземпляр RAC открывает PDB, доступен единый образ системы. Если необходимо изменить сеанс на pdb, измените сеанс и укажите необходимый контейнер. Запрос «show con_name» можно использовать для проверки имени текущего контейнера.

[oracle@node1 bin]$ sqlplus / as sysdba

SQL*Plus: версия 12.1.0.1.0, дата выпуска: 9 октября 2013 г., среда, 13:56:27

© Oracle, 1982, 2013. Все права защищены.

Oracle Database 12c Enterprise Edition, версия 12.1.0.1.0 — 64-разрядная производственная среда

С разбиением на разделы, Real Application Clusters, Automatic Storage Management, OLAP

Advanced Analytics и Real Application Testing

SQL> show con_name;

SQL> ALTER SESSION SET CONTAINER = PDB1;

SQL> SHOW CON_NAME;

SQL> ALTER SESSION SET CONTAINER = PDB2;

SQL> SHOW CON_ID;

SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;

SQL> SHOW CON_NAME;

Ниже приведено описание идентификаторов контейнеров.

ID контейнера Описание
0 Вся CDB
1 CDB$ROOT
2 PDB$SEED
От 3 до 254 PDB

Таблица 1. Описания идентификаторов контейнеров

В данном конкретном примере «con_id 3» представляет «pdb1», а «con_id 4» — «pdb2».

[grid@node1 bin]$ echo $ORACLE_HOME

[grid@node1 bin]$ echo $ORACLE_SID

[grid@node1 bin]$ sqlplus / as sysdba

SQL*Plus: версия 12.1.0.1.0, дата выпуска: 9 октября 2013 г., среда, 13:51:39

© Oracle, 1982, 2013. Все права защищены.

Oracle Database 12c Enterprise Edition, версия 12.1.0.1.0 — 64-разрядная производственная среда

С Real Application Clusters и Automatic Storage Management

SQL> show con_id;

SQL> show con_name;

4. Использование Enterprise Manager (EM) Express для подключения к PDB

Прежде чем перейти по URL-ссылке для доступа к EM Express, необходимо выпустить следующего SQL-оператора, чтобы подтвердить порт для EM Express:

Если отображаются данные, показанные выше, можно подключиться к URL-адресу, отображаемому DBCA.

Однако если отображаются неопределенные данные, например,

Процедура PL/SQL успешно завершена.

После этого попробуйте открыть EM Express с помощью URL-адреса.

Чтобы установить порт EM Express для PDB, необходимо изменить контейнер на соответствующие PDB и выполнить процедуру PL/SQL для настройки порта для этого контейнера.

SQL> alter session set container = pdb1;

SQL> alter session set container = pdb2;

SLN310924_ru__1icon

ПРИМЕЧАНИЕ. Если по-прежнему не удается подключиться к URL-адресу EM Express, перезагрузите элемент управления приемника в качестве пользователя сетки и повторите попытку.


На момент написания статьи официальный выпуск новой версии Oracle Database 12.2.0.1 еще не состоялся, но уже есть документация и возможность опробовать предварительную версию 12.2.0.1 RC4 от 14.09.2016 вживую в рамках курса Oracle University «Oracle Database 12c R2: New Features for 12c R1 Administrators». Здесь я поделюсь впечатлениями о том, что показалось наиболее интересным из тех возможностей, которые удалось опробовать.

Контейнерная архитектура

В 12c R2 контейнерная архитектура базы данных получила довольно существенное развитие. Если в 12c R1 удалось реализовать совместное использование компонент инфраструктуры (процессы, память, метаданные) среди слабо связанных между собой баз данных, то в 12c R2 через контейнеры приложений появилась возможность совместного использования метаданных и общих данных приложений. С другой стороны, появились новые инструменты распределения критичных ресурсов (память, ввод-вывод) между отдельными контейнерами. Архитектура начала приобретать свойство древовидности (с фиксированным количеством уровней).


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

Ключевым понятием данного слоя является понятие — Приложение:

  • приложения первоначально устанавливаются в корневые контейнеры приложений;
  • обязательными атрибутами приложения являются его имя и версия;
  • в рамках инсталляции создаются общие метаданные и данные приложения;
  • приложения в рамках одного корневого контейнера приложений устанавливаются строго последовательно;
  • в один контейнер можно разместить несколько приложений.

При первом открытии корневого контейнера создается встроенное приложение с именем APP$GUID, где GUID — это глобальный идентификатор корневого контейнера приложений, и для него создается дополнительное логическое имя (или алиас) APP$CON.

Инсталляция приложения начинается с команды ALTER PLUGGABLE DATABASE APPLICATION name BEGIN INSTALL 'version'.

После начала инсталляции приложения начинается захват SQL кода, который выполняется в корневом контейнере приложений в рамках одной или нескольких сессий (так по документации, а пробной версии 12.2.0.1 такой захват в рамках нескольких сессий производился некорректно). Кроме обычного SQL осуществляется захват сессий SQL*Loader. В дальнейшем этот код будет использован при синхронизации PDB приложений с корневым контейнером приложений. Поэтому необходимо, например, избегать указания полного имени файла при создании табличных пространств. При синхронизации будет попытка создания такого же табличного пространства с тем же самым именем файла и синхронизация окончится ошибкой. Посмотреть захваченный SQL код можно в представлении DBA_APP_STATEMENTS:

Если на момент инсталляции приложения уже существовали другие (не корневые) PDB приложений в этом контейнере, то для того чтобы общие метаданные и данные приложения стали видны в таких PDB, их нужно синхронизировать командой ALTER PLUGGABLE DATABASE APPLICATION . SYNC, подключившись к такой PDB. То же самое относится и к вновь создаваемым PDB при отсутствии в этом корневом контейнере специальной предзаполненной PDB, создаваемой с опцией AS SEED, либо если такая SEED PDB не была предварительно синхронизирована с корневым контейнером. При наличии SEED PDB, другие PDB в этом контейнере приложений создаются как ее клоны. Встроенное приложение APP$CON можно синхронизировать, как и любое другое.

Изменить приложение можно операцией Upgrade либо Patch. Разница между операциями состоит в наборе допустимых SQL команд в корневом контейнере после выполнения команды ALTER PLUGGABLE DATABASE APPLICATION . BEGIN [UPGRADE | PATCH]. Крупные изменения обычно оформляются как операция Upgrade, а более мелкие как Patch. При этом в рамках операции Patch недопустимы, например, разрушающие команды (DROP . ). Обе операции меняют версию приложения в корневом контейнере приложений.

После начала изменения приложения и до команды ALTER PLUGGABLE DATABASE APPLICATION . END [UPGRADE | PATCH] производится такой же захват SQL кода, как и при инсталляции приложения.

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

Если при выполнении SQL кода явно не была начата ни одна из операций Upgrade либо Patch, то считается, что изменение относится к встроенному приложению APP$CON и оформляется как операция Patch для него. Может появиться искушение не создавать свои приложения, а воспользоваться тем, что есть по умолчанию. Но не всегда это может быть возможным — в APP$CON может быть захвачен код, который имеет смысл только для корневого контейнера приложений и оканчивающийся ошибкой в обычной PDB приложений. В примере ниже в APP$CON захвачена операция, которая может быть успешно выполнена (если только в этой PDB уже не был создан локальный пользователь с таким же именем) при синхронизации в любой PDB. Результатом синхронизации будет создание пользователя toys_test в синхронизируемой PDB.

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

Кроме пользователей, ролей, профилей и многие другие объекты базы данных, в том числе таблицы и PL/SQL код, могут рассматриваться как общие для данного контейнера приложений и создаваться в рамках операций Install, Upgrade и Patch с разными значениями атрибута SHARING:

  • METADATA — метаданные такого объекта рассматриваются как общие (принадлежат корневому контейнеру приложений), но данные будут уникальны для каждой PDB (размещаются в них). Это является поведением по умолчанию.
  • DATA — метаданные и данные такого объекта рассматриваются как общие и размещаются в корневом контейнере приложений, а остальные PDB видят эти метаданные и данные по ссылке.
  • EXTENDED DATA — метаданные и часть данных принадлежат корневому контейнеру приложений, но каждая из PDB может иметь и собственную порцию данных.
  • NONE — объект не используется совместно.

Мне такая архитектурная конструкция стала напоминать объектную модель таких языков программирования, как Java. Осталось только допустить (сейчас запрещено) вложенность корневых контейнеров приложений друг в друга с возможностью наследования и переопределения метаданных, то мы фактически получили бы иерархию классов не ограниченную как сейчас тремя уровнями. Объекты, разделяемые в режиме DATA, могли бы выступать в качестве в качестве статических элементов класса, METADATA как объектные элементы и т.д.

Еще одним вариантом использования контейнерных баз данных, является возможность расщепить большую таблицу на фрагменты и каждый фрагмент обрабатывать независимо от других в своей PDB. А с появлением возможности, которую предоставляют proxy PDB, то и разнести нагрузку по обработке данных на разные контейнерные СУБД, находящихся на разных хостах. Перемещение же PDB с одной контейнерной базы данных в другую контейнерную базу данных тоже, в свою очередь, значительно упростилось и теперь может быть осуществлено практически без остановки обслуживания пользователей в этой PDB. И, если раньше для создания запроса по набору PDB требовалось использование специального синтаксиса с конструкцией CONTAINERS(), то теперь с помощью контейнерных карт можно это сделать, не меняя исходный код приложения.

Практические примеры

Теперь обо всем по порядку.

Имеем 2 контейнерные базы данных: CDB1 и CDB2. Подключаемся к ним в разных сессиях и настраиваем SQLPROMPT для удобства:

В CDB1 создаем корневой контейнер приложений app_root:

Инсталлируем приложение app1:

При создании табличного пространства используем OMF, иначе мы не сможем выполнить захваченный код в PDB приложений при синхронизации.

У таблиц будут общими только метаданные, а данные в каждой PDB будут свои.

Настраиваем возможность создания запросов к таблицам через контейнерную карту. Свойство таблицы containers_default позволяет её использовать во фразе CONTAINERS(table_name) запроса. А свойство container_map позволяет делать отсечку секций (фактически целиком PDB) при выполнении запроса основываясь на ключе секционирования использованном во фразе WHERE. Например WHERE region_id = 2.

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

Заканчиваем инсталляцию приложения:

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

Создадим шаблонную PDB (SEED), на основе которой будут создаваться другие PDB и синхронизируем ее с корневым контейнером приложений:

Теперь можно создать PDB содержащие данные. Они будут создаваться как клон app_root$seed и поэтому их синхронизация с корневым контейнером не понадобится:

Заполним данными наши таблицы и соберем статику по ним. Статистика по общим объектам собирается по месту нахождения данных.

Устанавливаем таблицу maptable в качестве контейнерной карты:

Теперь запрос, сделанный из корневого контейнера приложений, должен вернуть данные из обеих PDB без использования фразы CONTAINERS, а таблицы содержать псевдостолбец CON_ID. Проверяем:

Создадим консолидированный отчет и посмотрим план выполнения такого запроса:


Теперь посмотрим, как можно перемещать наши PDB в другие контейнерные базы данных, не изменяя код приложения, создающий консолидированную отчетность. Это может понадобиться, например, при исчерпании ресурсов на данном сервере или для того, чтобы сбалансировать нагрузку по серверам. Переносить будем PDB asia в CDB2. Для этого нам понадобиться сделать клон корневого контейнера app_root на CDB2, а на CDB1 создать proxy PDB, которая будет прозрачно для приложения перенаправлять запросы на другую базу данных через Database Link. Обе базы данных должны работать в режиме локального UNDO и архивирования журнальных файлов.

Склонируем корневой контейнер приложений app_root с CDB1 на CDB2 под именем app_rr:

На CDB1 создадим proxy PDB для перенаправления запросов на CDB2:

Для перемещения PDB мы должны дать на базе источнике привилегию SYSOPER пользователю, через которого работает Database Link на приемнике:

Готовим базу данных приемник:

Перемещаем PDB asia на CDB2:

В данный момент PDB asia у нас присутствует на обеих CDB. На CDB1 она открыта на чтение/запись, а на CDB2 она закрыта:

Но при первом открытии на чтение/запись PDB asia в CDB2, на старом месте в CDB1 её автоматически закроют и удалят. При необходимости, можно было бы воспользоваться режимом AVAILABILITY MAX, чтобы не обрывать существующие сессии пользователей к перемещаемой PDB.

Осталось проверить что наш запрос создания консолидированной отчетности по-прежнему работает:

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