In an application container, an application is a named, versioned set of application metadata and common data. A typical application installs application common users and application common objects.

Within an application container, an application is the named, versioned set of application common objects stored in the application root. In this context, “application” means “application back-end.” Application common objects include user accounts, tables, packages, and so on. An application can be shared with the application PDBs that belong to the application root.

An application can be installed, upgraded, and patched in an application root. When an application is installed, upgraded, or patched, you must issue an ALTER PLUGGABLE DATABASE ... BEGIN statement to start the operation and an ALTER PLUGGABLE DATABASE ... END statement to end the operation. These statements can be issued in the same user session or in different user sessions.

When application changes are performed in this way, application PDBs can synchronize with the application in the application root to apply the changes. The application container also manages the versions of the application and the patches to the application:

• When you install an application, you must specify the application version number.

• When you upgrade an application, you must specify the old application version number and the new application version number.

• When you patch an application, you must specify the minimum application version number for the patch and the patch number.

As the application evolves, the application container maintains all of the versions and patch changes you apply. You can also configure the application container so that different application PDBs use different versions of the application. For example, if you provide an application to various customers, and each customers has its own application PDB, some customers might wait longer to upgrade the application. In this case, some application PDBs can use the latest version of the application, while other application PDBs can use an older version of the application.

The following is the typical process for creating and maintaining an application in an application container:

1. Create the application container.

2. Install the application in the application root.

   This step includes creating the application data model and configuring the application common users and application common objects.

3. Create the application PDBs in the application root.

4. Synchronize each application PDB that should install the application with the application in the application root.

5. Load the data for each application PDB.

6. Maintain the application by upgrading it and patching it in the application root.

7. Synchronize application PDBs that should apply changes from upgrades and patches.

8. Add new application PDBs whenever necessary.

• About Installing Applications in an Application Container
  You issue ALTER PLUGGABLE DATABASE APPLICATION statements to install an application in the application root.
• Installing an Application in an Application Container with Automated Propagation
  To install an application in an application container, run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL statement to begin the installation and the ALTER PLUGGABLE DATABASE APPLICATION END INSTALL statement to end the installation. The application is installed in the application PDBs that synchronize with the application in the application root.

• About Upgrading Applications in an Application Container
  You issue ALTER PLUGGABLE DATABASE APPLICATION statements to upgrade an application in the application root.
• Upgrading an Application in an Application Container
  To upgrade an application in an application container, run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE statement to begin the upgrade and the ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statement to end the upgrade. Application changes related to the upgrade are propagated to the application PDBs that synchronize with the application in the application root.

• About Patching Applications in an Application Container
  You issue ALTER PLUGGABLE DATABASE APPLICATION statements to patch an application in the application root.
• Patching an Application in an Application Container with Automated Propagation
  To patch an application in an application container, run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN PATCH statement to begin the patch operation and the ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statement to end the patch operation. Application changes for the patch are propagated to the application PDBs that synchronize with the application in the application root.

• About Migrating an Existing Application to an Application Container
  You can migrate an application to an application root by creating an application root using an existing PDB.
• Creating an Application Root Using an Existing PDB
  You can migrate an application that is installed in a PDB by copying the PDB to an application container.
• Creating an Application PDB Using an Existing PDB
  After migrating an existing application to an application root, you can use an existing PDB that uses the application to create an application PDB.

When an application is installed, upgraded, patched, or uninstalled in an application root, an application PDB that belongs to the application root is not changed until it is synchronized. Synchronizing an application updates the application in the application PDB to the latest version and patch in the application root.

1. In SQL*Plus, ensure that the current container is the application PDB.
   The current user must have ALTER PLUGGABLE DATABASE system privilege.
2. Run an ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause.

ALTER PLUGGABLE DATABASE APPLICATION salesapp SYNC;

ALTER PLUGGABLE DATABASE APPLICATION ALL SYNC;

ALTER PLUGGABLE DATABASE APPLICATION APP$CON SYNC;

When application containers in different CDBs have the same application, their application roots can be kept synchronized by creating a master application root, a replica application root, and a proxy PDB.

• About Synchronizing an Application Root Replica with a Proxy PDB
  A proxy PDB can synchronize an application root and a replica based on the application root. When multiple application containers have the same application, you can use this technique to keep the application synchronized in all of the application containers. The application root and the application root replica can be in different CDBs.
• Creating a Proxy PDB That References an Application Root Replica
  When multiple application containers must run the same application, the application in the application containers can be kept in using proxy PDBs.

The compatibility version of an application is the earliest version of the application possible for the application PDBs that belong to the application container.

1. In SQL*Plus, ensure that the current container is the application root.
2. Run an ALTER PLUGGABLE DATABASE APPLICATION SET COMPATIBILITY VERSION statement.

ALTER PLUGGABLE DATABASE APPLICATION salesapp SET COMPATIBILITY VERSION '4.2';

ALTER PLUGGABLE DATABASE APPLICATION salesapp SET COMPATIBILITY VERSION CURRENT;

SQL*Loader is the only supported utility for bulk inserts into tables during application install, upgrade, and patch operations. Only conventional path loads are supported for bulk inserts during application install, upgrade, and patch operations.

1. In SQL*Plus, ensure that the current container is the application root.
2. Set the correct module by running the following procedure:
   exec DBMS_APPLICATION_INFO.SET_MODULE('SQL Loader Conventional Path Load', '');
   This module must remain set for the entire application install, upgrade, or patch operation.
3. Run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN statement for beginning an application installation, upgrade, or patch.
   For example, if you are performing the bulk insert as part of an application installation, then run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name BEGIN INSTALL 'application_version_number';
4. Perform the conventional path load with SQL*Loader.
5. Run the ALTER PLUGGABLE DATABASE APPLICATION END statement for ending an application installation, upgrade, or patch.
   For example, if you are performing the bulk insert as part of an application installation, then run the ALTER PLUGGABLE DATABASE APPLICATION END INSTALL statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name END INSTALL 'application_version_number';

   Note:

   Ensure that the application_name and application_version_number match in the ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL statement and the ALTER PLUGGABLE DATABASE APPLICATION END INSTALL statement.

6. Synchronize all of the application PDBs that must include these application changes by issuing an ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause.

• About Uninstalling Applications from an Application Container
  You issue ALTER PLUGGABLE DATABASE APPLICATION statements to uninstall an application from the application root.
• Uninstalling an Application from an Application Container
  To unistall an application in from application container, run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UNINSTALL statement to begin the uninstallation and the ALTER PLUGGABLE DATABASE APPLICATION END UNINSTALL statement to end the uninstallation. The application uninstalled from the application PDBs that synchronize with the application in the application root.

Application common objects are created in an application root and are shared with the application PDBs that belong to the application root. There are three types of application common object: metadata-linked, data-linked, and extended data-linked.

The following types of database objects can be application common objects:

• Analytic views

• Attribute dimensions

• Directories

• External procedure libraries

• Hierarchies

• Java classes, Java resources, Java sources

• Packages

• Object tables

• Object types

• Object views

• Sequences

• Stored functions

• Stored procedures

• Synonyms

• Tables (including temporary tables)

• Triggers

• Views

You can create these types of database objects as application common objects by issuing the CREATE statement when the current container is the application root and specifying the sharing attribute for it. You can specify the sharing attribute by including the SHARING clause in the CREATE statement or by setting the DEFAULT_SHARING initialization parameter in the application root. When you set the DEFAULT_SHARING initialization parameter, the setting is the default sharing attribute for all database objects of a supported type created in the application root. However, when a SHARING clause is included in a CREATE statement, its setting overrides the setting for the DEFAULT_SHARING initialization parameter.

You can specify one of the following for the sharing attribute:

• METADATA: A metadata link shares the database object’s metadata, but its data is unique to each container. These database objects are referred to as metadata-linked application common objects. This setting is the default.

• DATA: A data link shares the database object, and its data is the same for all containers in the application container. Its data is stored only in the application root. These database objects are referred to as data-linked application common objects.

• EXTENDED DATA: An extended data link shares the database object, and its data in the application root is the same for all containers in the application container. However, each application PDB in the application container can store data that is unique to the application PDB. For this type of database object, data is stored in the application root and, optionally, in each application PDB. These database objects are referred to as extended data-linked application common objects.

• NONE: The database object is not shared.

For most types of application common objects, the only valid settings for the SHARING clause are METADATA and NONE. The following types of application common objects allow additional settings for the SHARING clause:

• For tables (excluding object tables), the SHARING clause can be set to METADATA, DATA, EXTENDED DATA, or NONE. For object tables, only METADATA or NONE is valid.

• For views (excluding object views), the SHARING clause can be set to METADATA, DATA, EXTENDED DATA, or NONE. For object views, only METADATA or NONE is valid.

• For sequences, the SHARING clause can be set to METADATA, DATA, or NONE.

  With a metadata-linked sequence, each application PDB has its own sequence. When the metadata-linked sequence is incremented using the NEXTVAL pseudocolumn in one application PDB, it does not affect the value of the sequence in the other application PDBs in the application container.

  With a data-linked sequence, each application PDB shares the same sequence in the application root. When the metadata-linked sequence is incremented using the NEXTVAL pseudocolumn in one application PDB, all of the other application PDBs in the same application container also see the change.

Application common objects can be created or changed only as part of an application installation, upgrade, or patch. An application PDB applies changes to application common objects when it synchronizes with the application that made the changes. If an application PDB is closed when an application common object is created, dropped, or modified, then the appropriate changes are applied in the application PDB when it is opened and synchronized with the application.

The names of application common objects must not conflict with those of local database objects in any of the application PDBs that belong to the application root or Oracle-supplied common objects in the CDB root. If a newly opened application PDB contains a local database object whose name conflicts with that of an application common object, then the application PDB is opened in RESTRICTED mode. In this case, you must resolve the naming conflict before the application PDB can be opened in normal mode.

Some restrictions apply to application common objects.

Queries on application common objects can return data from a container that is not the current container. For example, when the current container is an application root, queries that include the CONTAINERS clause can return data from application PDBs for metadata-linked application common objects. Also, when the current container is an application PDB, queries on data-linked and extended data-linked application common objects return data that resides in the application root.

Columns of the following types return no data in queries that return data from a container other than the current container:

• The following user-defined types: object types, varrays, REFs, and nested tables

• The following Oracle-supplied types: ANYTYPE, ANYDATASET, URI types, SDO_TOPO_GEOMETRY, SDO_GEORASTER, and Expression

In addition, queries on object tables and object views return no data from containers other than the current container.

You create an application common object in an application root either by ensuring that the DEFAULT_SHARING initialization parameter is set to the correct value or by including the SHARING clause in the CREATE SQL statement.

1. In SQL*Plus, ensure that the current container is the application root.
   The current user must have the privileges required to create the database object.
2. Run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN statement for beginning an application installation, upgrade, or patch.
   For example, if you are creating the application common object as part of an application installation, then run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name BEGIN INSTALL 'application_version_number';
3. Create the application common object and specify its sharing attribute in one of the following ways:
   • Ensure that the DEFAULT_SHARING initialization parameter is set to the desired sharing attribute in the application root, and issue the CREATE SQL statement to create the database object.
   • Issue the CREATE SQL statement, and include the SHARING clause set to METADATA, DATA, or EXTENDED DATA.
   When a SHARING clause is included in a SQL statement, it takes precedence over the value specified in the DEFAULT_SHARING initialization parameter. For example, if the DEFAULT_SHARING initialization parameter is set to METADATA in the application root, and a database object is created with SHARING set to DATA, then the database object is created as a data-linked database object.

   Note:

   Once a database object is created, its sharing attribute cannot be changed.
4. Run the ALTER PLUGGABLE DATABASE APPLICATION END statement for ending an application installation, upgrade, or patch.
   For example, if you are creating the application common object as part of an application installation, then run the ALTER PLUGGABLE DATABASE APPLICATION END INSTALL statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name END INSTALL 'application_version_number';

   Note:

   Ensure that the application_name and application_version_number match in the ALTER PLUGGABLE DATABASE APPLICATION BEGIN INSTALL statement and the ALTER PLUGGABLE DATABASE APPLICATION END INSTALL statement.
5. Synchronize all of the application PDBs that must apply these changes by issuing an ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause with the application PDB as the current container.

ALTER SYSTEM SET DEFAULT_SHARING=DATA SCOPE=BOTH;

ALTER PLUGGABLE DATABASE APPLICATION salesapp BEGIN INSTALL '4.2';
CREATE TABLE employees_md SHARING=METADATA
    (employee_id    NUMBER(6), 
     first_name     VARCHAR2(20),
     last_name      VARCHAR2(25) CONSTRAINT emp_last_name_nn_demo NOT NULL, 
     email          VARCHAR2(25) CONSTRAINT emp_email_nn_demo     NOT NULL, 
     phone_number   VARCHAR2(20), 
     hire_date      DATE  DEFAULT SYSDATE CONSTRAINT emp_hire_date_nn_demo  NOT NULL, 
     job_id         VARCHAR2(10) CONSTRAINT     emp_job_nn_demo  NOT NULL, 
     salary         NUMBER(8,2)  CONSTRAINT     emp_salary_nn_demo  NOT NULL, 
     commission_pct NUMBER(2,2), 
     manager_id     NUMBER(6), 
     department_id  NUMBER(4), 
     dn             VARCHAR2(300), 
          CONSTRAINT emp_salary_min_demo CHECK (salary > 0), 
          CONSTRAINT emp_email_uk_demo UNIQUE (email));
ALTER PLUGGABLE DATABASE APPLICATION salesapp END INSTALL '4.2';

ALTER PLUGGABLE DATABASE APPLICATION salesapp BEGIN INSTALL '4.2';
CREATE TABLE product_descriptions_ob SHARING=DATA     
    (product_id             NUMBER(6), 
     language_id            VARCHAR2(3), 
     translated_name        NVARCHAR2(50)   CONSTRAINT translated_name_nn NOT NULL, 
     translated_description NVARCHAR2(2000) CONSTRAINT translated_desc_nn NOT NULL);
ALTER PLUGGABLE DATABASE APPLICATION salesapp END INSTALL '4.2';

ALTER PLUGGABLE DATABASE APPLICATION salesapp BEGIN INSTALL '4.2';
CREATE TABLE postalcodes SHARING=EXTENDED DATA
    (code        VARCHAR2(7),
     country_id  NUMBER,
     place_name  VARCHAR2(20));
ALTER PLUGGABLE DATABASE APPLICATION salesapp END INSTALL '4.2';

CREATE TABLE departments_ns SHARING=NONE
    (department_id    NUMBER(4), 
     department_name  VARCHAR2(30) CONSTRAINT  dept_name_nn  NOT NULL, 
     manager_id       NUMBER(6), 
     location_id      NUMBER(4), 
     dn               VARCHAR2(300));

The rules are different for issuing DML statements on metadata-linked, data-linked, and extended data-linked application common objects.

1. Complete the appropriate steps:
   For an application common object that is not part of an application root replica configuration:
   1. Connect to the appropriate container in the application container as a user with the privileges required to issue DML statements on the database object.
   2. Issue DML statements normally.
   For a data-linked or extended data-linked object that is part of an application root replica configuration:
   1. In SQL*Plus, ensure that the current container is the master application root in the application root replica in the configuration.
      The current user must have the privileges required to issue the DML statements on the database object.
   2. Run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN statement for beginning an application installation, upgrade, or patch.
      For example, if you are modifying the application common object as part of an application upgrade, then run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE statement in the following form:
      ALTER PLUGGABLE DATABASE APPLICATION application_name BEGIN UPGRADE 'application_start_version_number' TO 'application_end_version_number';
      For example, run the following statement if the application_name is salesapp, the application_start_version_number is 4.2, and the application_end_version_number is 4.3:
      ALTER PLUGGABLE DATABASE APPLICATION salesapp BEGIN UPGRADE '4.2' TO '4.3';
   3. Issue the DML statements on the data-linked application common object.
   4. Run the ALTER PLUGGABLE DATABASE APPLICATION END statement for ending an application installation, upgrade, or patch.
      For example, if you are modifying the application common object as part of an application upgrade, then run the ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statement in the following form:
      ALTER PLUGGABLE DATABASE APPLICATION application_name END UPGRADE TO 'application_end_version_number';
      For example, run the following statement if the application_name is salesapp and the application_end_version_number is 4.3:
      ALTER PLUGGABLE DATABASE APPLICATION salesapp END UPGRADE TO '4.3';

      Note:

      Ensure that the application_name and application_end_version_number match in the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE statement and ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statements.
   5. Synchronize all of the application PDBs that must apply these changes by issuing an ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause when the application PDB is the current container.

When you modify an application common object in an application root with certain DDL statements, you must modify the object between ALTER PLUGGABLE DATABASE APPLICATION BEGIN and ALTER PLUGGABLE DATABASE APPLICATION END statements, and application PDBs must synchronize with the application to apply the changes.

1. In SQL*Plus, ensure that the current container is the application root.
   The current user must have the privileges required to make the planned changes to the database object.
2. Run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN statement for beginning an application installation, upgrade, or patch.
   For example, if you are modifying the application common object as part of an application upgrade, then run the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name BEGIN UPGRADE 'application_start_version_number' TO 'application_end_version_number';
   For example, run the following statement if the application_name is salesapp, the application_start_version_number is 4.2, and the application_end_version_number is 4.3:
   ALTER PLUGGABLE DATABASE APPLICATION salesapp BEGIN UPGRADE '4.2' TO '4.3';
3. Modify the application common object with the DDL statement.
   For example, an ALTER TABLE statement might add a column to a table.
4. Run the ALTER PLUGGABLE DATABASE APPLICATION END statement for ending an application installation, upgrade, or patch.
   For example, if you are modifying the application common object as part of an application upgrade, then run the ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statement in the following form:
   ALTER PLUGGABLE DATABASE APPLICATION application_name END UPGRADE TO 'application_end_version_number';
   For example, run the following statement if the application_name is salesapp and the application_end_version_number is 4.3:
   ALTER PLUGGABLE DATABASE APPLICATION salesapp END UPGRADE TO '4.3';

   Note:

   Ensure that the application_name and application_end_version_number match in the ALTER PLUGGABLE DATABASE APPLICATION BEGIN UPGRADE statement and the ALTER PLUGGABLE DATABASE APPLICATION END UPGRADE statement.
5. Synchronize all of the application PDBs that must apply these changes by issuing an ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause with the application PDB as the current container.

DML statements can affect database objects in more than one container in an application container.

In an application root, a single DML statement that includes the CONTAINERS clause can modify a table or view in one or more containers in the application container. To use the CONTAINERS clause, specify the table or view being modified in the CONTAINERS clause and the containers in the WHERE clause. A target container can be specified in an INSERT VALUES statement by specifying a value for CON_ID in the VALUES clause. Also, a target container can be specified in an UPDATE or DELETE statement by specifying a CON_ID predicate in the WHERE clause.

UPDATE CONTAINERS(sales.customers) ctab 
   SET ctab.city_name='MIAMI' 
   WHERE ctab.CON_ID IN(7,8) AND
   CUSTOMER_ID=3425;

The values specified for the CON_ID in the WHERE clause must be for containers in the current application container.

You can specify default target containers for DML operations. If a DML statement does not specify values for the CON_ID in the WHERE clause, then the target containers of the DML operation are those specified in the database property CONTAINERS_DEFAULT_TARGET in the application root. When issued in an application root, the following DML statement modifies the default target containers for the application container:

UPDATE CONTAINERS(sales.customers) ctab 
   SET ctab.city_name='MIAMI' 
   WHERE CUSTOMER_ID=3425;

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME='CONTAINERS_DEFAULT_TARGET';

In addition, you can enable the CONTAINERS_DEFAULT attribute for a table or view in an application root. When this attribute is enabled, the CONTAINERS clause is used for queries and DML statements on the database object by default, and the CONTAINERS clause does not need to be specified in the SQL statements. To enable the CONTAINERS_DEFAULT attribute for a table or view in an application root, run the an ALTER TABLE or ALTER VIEW statement with the ENABLE CONTAINERS_DEFAULT clause.

The following restrictions apply to the CONTAINERS clause:

• INSERT as SELECT statements where the target of the INSERT is in CONTAINERS() is not supported.

• A multi-table INSERT statement where the target of the INSERT is in CONTAINERS() is not supported.

• DML statements using the CONTAINERS clause require that the database listener is configured using TCP (instead of IPC) and that the PORT and HOST values are specified for each target PDB using the PORT and HOST clauses, respectively.

To specify the default container for DML statements in an application container, issue the ALTER PLUGGABLE DATABASE statement with the CONTAINERS DEFAULT TARGET clause.

1. In SQL*Plus, ensure that the current container is the application root.
   The current user must have the commonly granted ALTER PLUGGABLE DATABASE privilege.
2. Run the ALTER PLUGGABLE DATABASE statement with the CONTAINERS DEFAULT TARGET clause.

ALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET = (APDB1);

ALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET = NONE;

A container map is a database property that specifies a partitioned map table that is defined in an application root. A container map can be used to partition the data in metadata-linked objects in an application container. Container maps partition data in application PDBs based on a commonly-used column.

A container map can define a logical partition key on a column for a common object. This mapping removes the requirements for defining a query with a CON_ID predicate and the need to use the CONTAINERS clause because the container is resolved internally based on the container map. Container maps are often useful when you are migrating from row based consolidation that uses a tenant ID with multiple tenants in a single PDB to a configuration that uses a different PDB for each tenant.

To use a container map in an application container, you use an ALTER DATABASE statement in the application root to specify a partitioned table for the CONTAINER_MAP database property. The partitioned table is called the map object. The map object specifies one of the following partitioning strategies for the data in a metadata-linked table based on a commonly-used column:

• Range partitioning

• List partitioning

• Hash partitioning

The names of the partitions in the map object match the names of the application PDBs in the application container. The column used in partitioning the map object must match a column in the metadata-linked object. The metadata-linked object is not physically partitioned at the table level, but it can be queried using the partitioning strategy that is enabled by the container map.

The following illustration shows, in an application root, a map object, a metadata-linked table, and a query on the metadata-linked table. The query is executed in the appropriate application PDB.

Figure 44-3 Container Map

Description of "Figure 44-3 Container Map"

The illustration shows an application container with three application PDBs named AMER, EURO, and ASIA. The application PDBs store data for the different regions (America, Europe, and Asia, respectively). A metadata-linked table named oe.cmtb stores information for an application, and this table has a COUNTRY column. For this partitioning strategy, partition by list is used to create a map object that creates a partition for each region, and the country value is used to determine the region. This example is described in detail in "Creating a Container Map".

Consider another example that uses a range-partitioned table for the map object. The following SQL statement creates the map object in the application root:

CREATE TABLE app_con_admin.conmap (
   department_id NUMBER NOT NULL)
PARTITION BY RANGE (department_id) (
PARTITION apppdb1 VALUES LESS THAN (100),
PARTITION apppdb2 VALUES LESS THAN (200),
PARTITION apppdb3 VALUES LESS THAN (300));

ALTER PLUGGABLE DATABASE SET CONTAINER_MAP='app_con_admin.conmap';

SELECT employee_id 
   FROM CONTAINERS(hr.employees) 
   WHERE department_id = 10 AND CON_ID IN (44); 

SELECT employee_id 
   FROM hr.employees 
   WHERE department_id = 10;

The CONTAINERS clause is unnecessary when a container map is defined. As shown in the first query with the CONTAINERS clause, when the query only pertains to a single application PDB, the query must specify the container ID of this application PDB in the WHERE clause, and this requirement might cause application changes. The second query that uses the container map, replacing the CONTAINERS clause, does not specify the container, because the container map directs the query to the correct application PDB. In addition, queries that use container maps are generally more efficient than queries that use the CONTAINERS clause. The container map must be created by a common user with ALTER DATABASE system privilege. Queries run against an object that is enabled for container map, and query privileges are determined by privileges granted on the object.

You create a container map by creating a map object and setting the CONTAINER_MAP database property to the map object.

1. In SQL*Plus, ensure that the current container is the application root.
2. Create the map object.
3. Set the CONTAINER_MAP database property to the map object.
   ALTER DATABASE SET CONTAINER_MAP = 'map_table_schema.map_table_name';
   Replace map_table_schema with the owner of the table, and replace map_table_name with the name of the table.
4. Start an application installation, upgrade, or patch.
5. If the metadata-linked table that will be used by the container map does not exist, then create it.
6. Enable the container map for the table to be queried by issuing an ALTER TABLE statement with the ENABLE CONTAINER_MAP clause.
7. Ensure that the table to be queried is enabled for the CONTAINERS clause by issuing an ALTER TABLE statement with the ENABLE CONTAINERS_DEFAULT clause.
8. End the application installation, upgrade, or patch started previously.