oracle pluggable database что это
Oracle 12c Multitenant Architecture. Новые возможности для разработки и тестирования
Самым крупным нововведением недавно вышедшего Oracle 12c безусловно является Multitenant Architecture. Сам Oracle преподносит эту возможность в основном как средство консолидации и снижения расходов.
Суть технологии состоит в возможности запустить несколько независимых баз (pluggable database, PDB) в рамках одного инстанса (container database, CDB). Каждая база имеет свой набор схем и табличных пространств, но при этом у них общая SGA и один набор серверных процессов. Есть возможность клонировать pluggable database, как в рамках одного контейнера, так и между контейнерами. Вот эту возможность и будем использовать для создания копий тестовых баз и экономии ресурсов.
Задача — имеем большую систему, с большой базой. Нужно проводить тестирование изменений, причем изменений разрушительных — удаление/модификация таблиц. Как это делается сейчас — создаем новую базу, заливаем в нее минимально возможный набор схем и данных и проводим тестирование. Процесс сам по себе не быстрый, трудоемкий и всегда есть возможность ошибиться. Да и «минимальный набор данных» может быть не таким уж и маленьким.
Эксперимент проводился в среде Oracle Virtualbox 4.2.14. Я не буду подробно описывать инсталляцию, она хорошо освещена в документации, буду останавливаться только на важных моментах.
Инсталляция
Ставим Oracle linux 6.4 c апдейтами, зависимости для oracle и поддержку ASM:
конфигурируем ASM и создаем ASM disk:
Подключаемся к инстансу 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, рассмотрен лишь частный случай применительно к конкретной задаче.
Todo list online
Внешние устройства компьютера
В наши дни обслуживание облачных вычислений и приложений в облаке. Это уменьшает капитальные затраты для корпораций и имеет немедленные налоговые льготы. Поэтому у компаний есть много стимулов для использования облачных вычислений.
Опция Multitenant для Oracle 12c лицензируется. Как обычно, обратитесь к представителю отдела продаж Oracle за расходами. Опять же, убедитесь, что вы знаете о возврате инвестиций, которые эта функция может принести вам.
Вам нужно знать о новых типах баз данных, которые теперь являются частью многоуровневой архитектуры:
База данных контейнеров (CDB): Основная база данных, содержащая несколько подключаемых модулей базы данных. Многие операции могут выполняться на уровне контейнера для снижения затрат на управление. База данных создается либо как CDB, либо CDB.
Pluggable Database (PDB): Набор объектов схемы, объектов и объектов, которые могут быть подключены и отсоединены от базы данных контейнера. PDB представляется OracleNet и конечным пользователям как сама база данных, но фактически управляется внутри контейнера, который может иметь много PDB.
Параметр Multitenant позволяет выполнить следующее:
Высокая плотность консолидации: Многие базы данных могут совместно использовать память и фоновые процессы.
Предоставление: База данных может быть отключена от одной среды и подключена к другой или клонирована командами SQL всего за несколько секунд. Их можно даже подключить к операционным системам и наборам микросхем.
Патч и обновления: Вы можете исправить базу данных, просто отключив ее от одного нераспределенного контейнера и подключив его к другому исправленному контейнеру.
Управление несколькими базами данных как один: Вы можете выполнять такие задачи, как резервное копирование и исправление в основной базе данных контейнера вместо отдельных подключаемых баз данных.
Управление ресурсами: Функция Oracle Resource Manager может работать на уровне подключаемых баз данных для управления конкуренцией ресурсов между базами данных в вашей среде.
Как создать среду многопользовательской базы данных в 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, вы можете по существу сделать противоположное предыдущим командам:
Oracle pluggable database что это
С выходом новой версии Oracle 12c пользователи этой БД приобрели принципиально новую возможность – облачные экземпляры базы данных. С ними можно выполнять массу различных действий – клонирование, перенос, извлечение и пр. Но для начала необходимо научиться самомму простому дейсвию – запуск и остановка БД.
В данном случае мы имеем дело с двумя принципиально разными видами БД: контейнерная (CDB) – она является основной “платформой”, на которой размещаются БД второго вида – подключаемые (PDB). Каждый экземпляр обоих видов БД необходимо запускать отдельно. В последующих обновлениях была добавлена возможность автоматического старта всех PDB во время запуска CDB. В первой же версии такая возможность отсутствует, поэтому придется запускать все вручную или добавить специальный триггер ON STARTUP, где во время запуска CDB будут запущены и необходимые PDB.
Запуск CDB ничем не отличается от БД предыдущих версий:
После этой операции все подключаемые базы данных (PDB) оказываются смонтированными, но неоткрытыми. Проверить состояние всех БД можно простым запросом.
Из БД, являющейся контейнером, можно открыть любую подключаемую БД или все сразу:
Все операции с выбранной PDB можно делать находясь непосредственно в контексте подключаемой БД. Сначала проверим где мы находимся сейчас, затем перейдем в MYPDB, остановим ее и запустим заново:
Вышеописанные команды запуска подключаемых БД можно добавить в триггер. Тогда желаемые PDB будут открываться автоматически.
Oracle pluggable database что это
Use the CREATE PLUGGABLE DATABASE statement to create a pluggable database (PDB).
This statement enables you to perform the following tasks:
Create a PDB by using the seed as a template
Use the create_pdb_from_seed clause to create a PDB by using the seed in the multitenant container database (CDB) as a template. The files associated with the seed are copied to a new location and the copied files are then associated with the new PDB.
Create a PDB by cloning an existing PDB or non-CDB
Use the create_pdb_clone clause to create a PDB by copying an existing PDB or non-CDB and then plugging the copy into the CDB. The files associated with the existing PDB or non-CDB are copied to a new location and the copied files are associated with the new PDB.
Create a PDB by plugging an unplugged PDB or a non-CDB into a CDB
Use the create_pdb_from_xml clause to plug an unplugged PDB or a non-CDB into a CDB, using an XML metadata file.
Create a proxy PDB by referencing another PDB. A proxy PDB provides fully functional access to the referenced PDB.
Use the create_pdb_clone clause and specify AS PROXY FROM to create a proxy PDB.
Create an application container, application seed, or application PDB
When a new PDB is established in a CDB, it is possible that the name of a service offered by the new PDB will collide with an existing service name. The namespace in which a collision can occur is that of the listener that gives access to the CDB. Within that namespace, collisions are possible among the names of non-CDB’s default services, CDB’s default services, PDB’s default services, and user-defined services. For example, if two or more CDBs on the same computer system use the same listener, and the newly established PDB has the same service name as another PDB in these CDBs, then a collision occurs.
Oracle Database Concepts for general information on PDBs
ALTER PLUGGABLE DATABASE and DROP PLUGGABLE DATABASE for information on modifying and dropping PDBs
You must be connected to a CDB. The CDB must be open and in READ WRITE mode.
To create a PDB or an application container, the current container must be the root and you must have the CREATE PLUGGABLE DATABASE system privilege, granted commonly.
To create an application seed or an application PDB, the current container must be an application root, the application container must be open and in READ WRITE mode, and you must have the CREATE PLUGGABLE DATABASE system privilege, either granted commonly or granted locally in that application container.
To specify the create_pdb_clone clause:
If src_pdb_name refers to a PDB in the same CDB, then you must have the CREATE PLUGGABLE DATABASE system privilege in the root of the CDB in which the new PDB will be created and in the PDB being cloned.
If src_pdb_name refers to a PDB in a remote database or a non-CDB, then you must have the CREATE PLUGGABLE DATABASE system privilege in the root of the CDB in which the new PDB will be created and the remote user must have the CREATE PLUGGABLE DATABASE system privilege in the PDB or non-CDB to which src_pdb_name refers.
See Oracle Multitenant Administrator’s Guide for more information on the prerequisites to PDB creation.
The PDB name must be unique in the CDB, and it must be unique within the scope of all the CDBs whose instances are reached through a specific listener.
AS APPLICATION CONTAINER
Specify this clause to create an application container.
Oracle Database Administrator’s Guide for the complete steps for creating an application container
An application container can have at most one application seed. The application seed is optional, but, if it exists, you can use it to create application PDBs quickly that match the requirements of the application container. An application seed enables instant provisioning of application PDBs that are created from it.
Oracle Database Administrator’s Guide for the complete steps for creating an application seed
This clause enables you to create a PDB by using the seed in the CDB as a template.
Oracle Database Administrator’s Guide for the complete steps for creating a PDB using the seed
You can also use the GRANT statement to grant roles to the PDB_DBA role after the PDB has been created. Until you have granted the appropriate privileges to the PDB_DBA role, the SYS and SYSTEM users can perform administrative tasks on a PDB.
This clause instructs the CDB to use parallel execution servers to copy the new PDB’s data files to a new location. This may result in faster creation of the PDB.
Use integer to specify the number of parallel execution servers to use. The CDB can ignore this setting, depending on the current database load and the number of available parallel execution servers. If you specify a value of 0 or 1, then the CDB does not parallelize the creation of the PDB. This can result in a longer PDB creation time.
Use this clause to specify storage limits for the PDB.
Use this clause to determine how the database generates the names of files (such as data files and wallet files) for the PDB.
Oracle Database will replace filename_pattern with replacement_filename_pattern when generating the names of files associated with the new PDB.
File name patterns cannot match files or directories managed by Oracle Managed Files.
Use this clause to rename the user-defined services of the new PDB based on the service names of the source PDB. When the service name of a new PDB conflicts with an existing service name in the CDB, plug-in violations can result. This clause enables you to avoid these violations.
Oracle Database will use the replacement service name for the service in the PDB being created.
Restrictions on service_name_convert
The service_name_convert clause is subject to the following restrictions:
You cannot change the name of the default service for a PDB. The default service has the same name as the PDB.
You cannot specify this clause when you use the create_pdb_from_seed clause to create a PDB from the CDB seed, because the CDB seed does not have user-defined services. You can, however, specify this clause when you use the create_pdb_from_seed clause to create an application PDB from the application seed.
Use this clause to ensure that file paths for directory objects associated with the PDB are restricted to the specified directory or its subdirectories. This clause also ensures that the following files associated with the PDB are restricted to the specified directory: the Oracle XML repository for the PDB, files created with a CREATE PFILE statement, and the export directory for Oracle wallets. You cannot modify the setting of this clause after you create the PDB. This clause does not affect files created by Oracle Managed Files.
Be sure to specify path_name so that the resulting path name will be properly formed when relative paths are appended to it. For example, on UNIX systems, be sure to end path_name with a forward slash ( / ), such as:
After the path_prefix_clause is specified for a PDB, existing directory objects might not work as expected, since the PATH_PREFIX string is always added as a prefix to all local directory objects in the PDB. The path_prefix_clause only applies to user-created directory objects. It does not apply to Oracle-supplied directory objects.
When you create a PDB, Oracle Database associates temp files with the new PDB. Depending on how you create the PDB, the temp files may already exist and may have been previously used.
Specify TEMPFILE REUSE to instruct the database to format and reuse a temp file associated with the new PDB if it already exists. If you specify this clause and a temp file does not exist, then the database creates the temp file.
If you do not specify TEMPFILE REUSE and a temp file to be associated with the new PDB already exists, then the database returns an error and does not create the PDB.
You can use this clause to separate the data for multiple schemas into different PDBs. For example, when you move a non-CDB to a PDB, and the non-CDB had a number of schemas that each supported a different application, you can use this clause to separate the data belonging to each schema into a separate PDB, assuming that each schema used a separate tablespace in the non-CDB.
Specify tablespace to make the tablespace available in the new PDB. You can specify more than one tablespace in a comma-separated list.
Specify ALL to make all tablespaces available in the new PDB. This is the default.
Specify ALL EXCEPT to make all tablespaces available in the new PDB, except the specified tablespaces.
These clauses apply only when cloning a PDB with the create_pdb_clone clause. They do not apply when cloning a non-CDB. By default, the database creates each tablespace to be made available in the new PDB according to the settings specified for cloning the PDB. These clauses allow you to override those settings as follows:
These clauses apply when you plug in a PDB with the create_pdb_from_xml clause. By default, the database creates each tablespace to be made available in the new PDB according to the settings specified for plugging in the PDB. These clauses allow you to override those settings as follows:
Use this clause to specify whether the new PDB is included in one or more standby CDBs. If you include a PDB in a standby CDB, then during standby recovery the standby CDB will search for the data files for the PDB. If the data files are not found, then standby recovery will stop and you must copy the data files to the correct location before you can restart recovery.
Specify cdb_name to include the new PDB in the specified standby CDB. You can specify more than one standby CDB name in a comma-separated list.
Specify ALL to include the new PDB in all standby CDBs. This is the default.
Specify ALL EXCEPT to include the new PDB in all standby CDBs, except the specified standby CDBs.
Specify NONE to exclude the new PDB from all standby CDBs. When a PDB is excluded from all standby CDBs, the PDB’s data files are unnamed and marked offline on all of the standby CDBs. Standby recovery will not stop if the data files for the PDB are not found on the standby. If you instantiate a new standby CDB after the PDB is created, then you must explicitly disable the PDB for recovery on the new standby CDB.
You can enable a PDB on a standby CDB after it was excluded on that standby CDB by copying the data files to the correct location, bringing the PDB online, and marking it as enabled for recovery.
When creating a tablespace, you can override the default logging attribute by specifying the logging_clause of the CREATE TABLESPACE statement.
Refer to logging_clause for a full description of this clause.
By default, a newly created PDB inherits its Oracle Managed Files settings from the root. If the root uses Oracle Managed Files, then the PDB also uses Oracle Managed Files. The PDB shares the same base file system directory for Oracle Managed Files with the root and has its own subdirectory named with the GUID of the PDB. If the root does not use Oracle Managed Files, then the PDB also does not use Oracle Managed Files.
This clause lets you override the default behavior. You can enable or disable Oracle Managed Files for the PDB and you specify a different base file system directory or Oracle ASM disk group for the PDB’s files.
Specify NONE to disable Oracle Managed Files for the PDB.
Specify either directory_path_name or diskgroup_name to enable Oracle Managed Files for the PDB.
Specify directory_path_name to designate the base file system directory for the PDB’s files. Specify the full path name of the operating system directory. The directory must exist and Oracle processes must have appropriate permissions on the directory. The single quotation marks are required, with the result that the path name is case sensitive.
Specify diskgroup_name to designate the default Oracle ASM disk group for the PDB’s files.
These clauses are useful only if you are creating a PDB that you plan to reference from a proxy PDB. This type of PDB is called a referenced PDB.
When creating a referenced PDB:
In an Oracle Real Application Clusters (Oracle RAC) environment, you can specify for hostname any of the hosts for the PDB.
A proxy PDB uses a database link to establish communication with its referenced PDB. After communication is established, the proxy PDB communicates directly with the referenced PDB without using a database link. The host name and port number of the listener for the referenced PDB must be correct for the proxy PDB to function properly.
The clause AS PROXY FROM of create_pdb_clone for information on creating a proxy PDB
This clause enables you to create a new PDB by cloning a source to a target PDB. The source can be a PDB in the local CDB, a PDB in a remote CDB, or a non-CDB. The target PDB is the clone of the source.
If the source is a PDB in the local CDB, then the source PDB can be plugged in or unplugged. If the source is a PDB in a remote CDB, then the source PDB must be plugged in.
If the source is a non-CDB or a PDB in a remote CDB, then the source and the CDB that contains the target PDB must meet the following requirements:
They must have the same endian format.
They must have compatible character sets and national character sets, which means:
Every character in the source character set is available in the local CDB character set.
Every character in the source character set has the same code point value in the local CDB character set.
They must have the same set of database options installed.
Users in the PDB who used the default temporary tablespace of the source non-CDB or PDB use the default temporary tablespace of the new PDB. Users who used non-default temporary tablespaces in the non-CDB or PDB continue to use the same local temporary tablespaces in the new PDB.
Oracle Database Administrator’s Guide for the complete steps for creating a PDB by cloning an existing PDB
Use this clause to specify the source PDB or non-CDB. The files associated with the source are copied to a new location and these copied files are then associated with the new PDB.
The source PDB or non-CDB cannot be closed. It can be open as follows:
If the CDB that contains the source PDB (the source CDB) or the source non-CDB is in ARCHIVELOG mode and local undo mode, then the source PDB or the source non-CDB can be open in READ WRITE mode and fully functional during the cloning operation. This is called hot PDB cloning.
Specify the source PDB or non-CDB as follows:
If the source is a PDB in a remote CDB, then use src_pdb_name to specify the name of the source PDB and dblink to specify the name of the database link to use to connect to the remote CDB.
Use this clause to create a proxy PDB by referencing a different PDB, which is referred to as the referenced PDB. The referenced PDB can be in the same CDB as the proxy PDB or in a different CDB. A local proxy PDB is in the same CDB as its referenced PDB, and a remote proxy PDB is in a different CDB than its referenced PDB.
Oracle Database Administrator’s Guide for the complete steps for creating a proxy PDB
Use this clause to specify a permanent default tablespace for the PDB. Oracle Database will assign the default tablespace to any non- SYSTEM user for whom a different permanent tablespace is not specified. The tablespace must already exist in the source PDB or non-CDB. Because the tablespace already exists, you cannot specify the DATAFILE clause or the extent_management_clause when creating a PDB with the create_pdb_clone clause.
Use this clause to specify storage limits for the new PDB. Refer to pdb_storage_clause for the full semantics of this clause.
Use this clause to determine how the database generates the names of files for the new PDB. Refer to file_name_convert for the full semantics of this clause.
Use this clause to determine how the database renames services for the new PDB. Refer to service_name_convert::= for the full semantics of this clause.
Use this clause to ensure that all directory object paths associated with the PDB are restricted to the specified directory or its subdirectories. Refer to path_prefix_clause for the full semantics of this clause.
Specify TEMPFILE REUSE to instruct the database to format and reuse a temp file associated with the new PDB if it already exists. Refer to tempfile_reuse_clause for the full semantics of this clause.
You can specify SNAPSHOT COPY only when cloning a PDB. This clause is not supported when cloning a non-CDB. The source PDB can be in the local CDB or a remote CDB. The SNAPSHOT COPY clause instructs the database to clone the source PDB using storage snapshots. This reduces the time required to create the clone because the database does not need to make a complete copy of the source data files.
Direct NFS Client enables an Oracle database to access network attached storage (NAS) devices directly, rather than using the operating system kernel NFS client. If the PDB files are stored on Direct NFS Client storage, then the following additional requirements must be met:
The source PDB files must be located on an NFS volume.
Storage credentials must be stored in a Transparent Data Encryption keystore.
The storage user must have the privileges required to create and destroy snapshots on the volume that hosts the source PDB files.
Credentials must be stored in the keystore using an ADMINISTER KEY MANAGEMENT ADD SECRET SQL statement.
When you use the SNAPSHOT COPY clause to create a clone of a source PDB, the following restrictions apply to the source PDB as long as any clones exist:
It cannot be unplugged.
It cannot be dropped.
PDB clones created using the SNAPSHOT COPY clause cannot be unplugged. They can only be dropped. Attempting to unplug a clone created using the SNAPSHOT COPY clause results in an error.
For a PDB created using the SNAPSHOT COPY clause in an Oracle Real Application Clusters (Oracle RAC) environment, each node that must access the PDB’s files must be mounted. For Oracle RAC databases running on Linux or UNIX platforms, the underlying NFS volumes must be mounted. If the Oracle RAC database is running on a Windows platform and using Direct NFS for shared storage, then you must update the oranfstab file on all nodes with the created volume export and mount entries.
Storage clones are named and tagged using the new PDB GUID. You can query the CLONETAG column of DBA_PDB_HISTORY view to view clone tags for storage clones.
The REFRESH MODE clause applies only when cloning a PDB. The source PDB must be in a remote CDB, that is, you must specify the source PDB using the FROM src_pdb_name @ dblink clause.
A refreshable PDB can be opened only in READ ONLY mode. A refreshable PDB must be closed in order for a refresh to occur. If it is not closed when you attempt to perform a manual refresh, then an error will occur. If it is not closed when the database attempts an automatic refresh, then the refresh will be deferred until the next scheduled refresh.
ALTER PLUGGABLE DATABASE REFRESH for information on refreshing a PDB manually
ALTER PLUGGABLE DATABASE pdb_refresh_mode_clause for information on changing the refresh mode of a PDB
Oracle Database Administrator’s Guide for more information on refreshable PDBs
The RELOCATE clause allows you to relocate a PDB from one CDB to another. The database first clones the source PDB to the target PDB, and then removes the source PDB. The database also moves the files associated with the PDB to a new location. This operation is the fastest way to relocate a PDB with minimal down time. The down time for the PDB is approximately the time required to copy the PDB’s files from their old location to their new location. The source PDB can be open in READ WRITE mode and fully functional during the relocation operation.
Oracle Database Administrator’s Guide for the complete steps for relocating a PDB
The NO DATA clause applies only when cloning a PDB. This clause specifies that the source PDB’s data model definition is cloned, but not the PDB’s data. The dictionary data in the source PDB is cloned, but all user-created table and index data from the source PDB is discarded.
Restrictions on the NO DATA Clause
The following restrictions apply to the NO DATA clause:
You cannot specify NO DATA when cloning a non-CDB.
You cannot specify NO DATA if the source PDB contains clustered tables, Advanced Queuing (AQ) tables, index-organized tables, or tables that contain abstract data type columns.
These clauses are useful only if you are creating a PDB that you plan to reference from a proxy PDB. This type of PDB is called a referenced PDB. Refer to HOST and PORT for the full semantics of these clauses.
This clause enables you to create a PDB by plugging an unplugged PDB or a non-CDB (the source database) into a CDB (the target CDB). If the source database is an unplugged PDB, then it may have been unplugged from the target CDB or a different CDB.
The source database and the target CDB must meet the following requirements:
They must have the same endian format.
They must have compatible character sets and national character sets, which means:
Every character in the source database character set is available in the target CDB character set.
Every character in the source database character set has the same code point value in the target CDB character set.
They must have the same set of database options installed.
Oracle Database Administrator’s Guide for the complete steps for creating a PDB by plugging an unplugged PDB into a CDB and creating a PDB using a non-CDB
Specify this clause only if the target CDB already contains a PDB that was created using the same set of data files. The source files remain as an unplugged PDB and can be used again. Specifying AS CLONE also ensures that Oracle Database generates new identifiers, such as DBID and GUID, for the new PDB.
If the source database is an unplugged PDB, then the file was created by the pdb_unplug_clause of ALTER PLUGGABLE DATABASE as follows:
If the source database is a non-CDB, then you must create the XML metadata file using the DBMS_PDB package, and ensure that the XML metadata file, as well as the source non-CDB’s data files, are in a location that is accessible to the CDB.
pdb_unplug_clause of ALTER PLUGGABLE DATABASE
Specify this clause only if the contents of the XML file do not accurately describe the locations of the source files. If the files that must be used to plug in the source database are no longer in the location specified in the XML file, then use this clause to map the specified file names to the actual file names.
Oracle Database will replace filename_pattern with replacement_filename_pattern when searching for the source database files.
File name patterns cannot match files or directories managed by Oracle Managed Files.
Specify this clause only if the contents of the XML file do not accurately describe the locations of the source files and the source files are all present in a single directory. This clause is convenient when you have a large number of data files and specifying a replacement file name pattern for each file using the source_file_name_convert clause is not feasible.
You can specify this clause for configurations that use Oracle Managed Files and for configurations that do not use Oracle Managed Files.
Specify COPY if you want the files listed in the XML file to be copied to the new location and used for the new PDB. This is the default. You can use the optional file_name_convert clause to use pattern replacement in the new file names. Refer to file_name_convert for the full semantics of this clause.
Specify MOVE if you want the files listed in the XML file to be moved, rather than copied, to the new location and used for the new PDB. You can use the optional file_name_convert clause to use pattern replacement in the new file names. Refer to file_name_convert for the full semantics of this clause.
Specify NOCOPY if you want the files for the PDB to remain in their current locations. Use this clause if there is no need to copy or move the files required to plug in the PDB.
Use this clause to determine how the database renames services for the new PDB. Refer to service_name_convert::= for the full semantics of this clause.
Use this clause to specify a permanent default tablespace for the PDB. Oracle Database will assign the default tablespace to any non- SYSTEM user for whom a different permanent tablespace is not specified. The tablespace must already exist in the source database. Because the tablespace already exists, you cannot specify the DATAFILE clause or the extent_management_clause when creating a PDB with the create_pdb_from_xml clause.
Use this clause to specify storage limits for the new PDB. Refer to pdb_storage_clause for the full semantics of this clause.
Use this clause to ensure that all directory object paths associated with the PDB are restricted to the specified directory or its subdirectories. Refer to path_prefix_clause for the full semantics of this clause.
Specify TEMPFILE REUSE to instruct the database to format and reuse a temp file associated with the new PDB if it already exists. Refer to tempfile_reuse_clause for the full semantics of this clause.
These clauses are useful only if you are creating a PDB that you plan to reference from a proxy PDB. This type of PDB is called a referenced PDB. Refer to HOST and PORT for the full semantics of these clauses.
Creating a PDB by Using the Seed: Example
Cloning a PDB From an Existing PDB: Example