Administering a CDB

Administering a multitenant container database (CDB) includes tasks such as accessing a container, modifying a CDB, executing DDL statements, and running Oracle-supplied SQL scripts.

Administering a CDB is similar to administering a non-CDB, with some differences.

Most differences occur because some administrative tasks apply to the entire CDB, whereas others apply to specific containers.

Current Container

The data dictionary in each container in a CDB is separate, and the current container is the container whose data dictionary is used for name resolution and for privilege authorization.

The current container can be the CDB root, an application root, a PDB, or an application PDB. Each session has exactly one current container at any point in time. However, a session can switch from one container to another.

Each container has a unique ID and name in a CDB. You can use the CON_ID and CON_NAME parameters in the USERENV namespace to determine the current container ID and name with the SYS_CONTEXT function. For example, the following query returns the current container name:

SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

You can access a container in various ways. For example, you can use the SQL*Plus CONNECT command, and you can use an ALTER SESSION SET CONTAINER statement to switch the container of the current session.

The following rules apply to the current container in a CDB:

  • The current container can be CDB$ROOT (CDB root) only for common users.
  • The current container can be a specific PDB for common users and local users.
  • The current container can be an application root only for common users or for application common users created in the application root.
  • The current container can be a specific application PDB for common users, application common users, and local users.
  • The current container must be the CDB root or an application root when a SQL statement includes CONTAINER = ALL.

You can include the CONTAINER clause in several SQL statements, such as the CREATE USERALTER USERCREATE ROLEGRANTREVOKE, and ALTER SYSTEM statements. Note the following rules about CONTAINER = ALL:

  • When a SQL statement includes CONTAINER = ALL and the current container is the CDB root, the SQL statement affects all containers in the CDB, including all PDBs, application roots, and application PDBs.
    • When a SQL statement includes CONTAINER = ALL and the current container is an application root, the SQL statement affects all containers in the application container, including the application root and all the application PDBs that belong to the application root. The SQL statement does not affect the CDB root or any PDBs or application PDBs that do not belong to the current application root.
    • Only a common user or application common user with the commonly granted SET CONTAINER privilege can run a SQL statement that includes CONTAINER = ALL.

Administrative Tasks in a CDB

Common users perform administrative tasks for a CDB.

A common user has a single identity and can log in to the CDB root, any application root, PDB, or application PDB in which it has privileges. Some tasks, such as starting up a CDB instance, can be performed only by a common user.

Other administrative tasks are the same for a CDB and a non-CDB. The following table describes some of these tasks and provides pointers to the relevant documentation.

Administrative Tasks Common to CDBs and Non-CDBs

TaskDescription
Starting up a CDB instanceTo start a CDB instance, the current user must be a common user whose current container is the CDB root. When you open a CDB, the CDB root is opened, but its other containers are mounted. Use the ALTER PLUGGABLE DATABASE statement to modify the open mode of one or more containers.
Managing processesA CDB has one set of background processes shared by the CDB root and all containers.
Managing memoryA CDB has a single system global area (SGA) and a single aggregate program global area (PGA). The memory required by a CDB is the sum of the memory requirements for all containers that will be part of the CDB.
Managing securityYou can create and drop common users, application common users, and local users in a CDB. You can also grant privileges to and revoke privileges from these users. You can also manage the CONTAINER_DATA attributes of common users and application common users. In addition, grant the following roles to the appropriate users: Grant the CDB_DBA role to CDB administrators.Grant the PDB_DBA role to application container administrators and PDB administrators.
Monitoring errors and alertsA CDB has one alert log for the entire CDB. The name of an application container, PDB, or application PDB is included in records in trace files, when appropriate.
Managing diagnostic dataIn a CDB, you can use the Oracle Database fault diagnosability infrastructure and the Automatic Diagnostic Repository (ADR).
Managing control filesA CDB has one control file.
Managing the online redo log and the archived redo log filesA CDB has one online redo log and one set of archived redo log files.
Managing tablespacesYou can create, modify, and drop tablespaces and temporary tablespaces for the CDB root and for individual containers. You can also specify a default tablespace, default tablespace type, and a default temporary tablespace for the CDB root. The CDB root has its own set of Oracle-supplied tablespaces, such as the SYSTEM tablespace, and other containers have their own set of Oracle-supplied tablespaces.
Managing data files and temp filesThe CDB root has its own data files, and other containers have their own data files. In a CDB, you can manage data files and temp files in basically the same way you would manage them for a non-CDB. However, the following exceptions apply to CDBs: You can limit the amount of storage used by the data files for a container by using the STORAGE clause in a CREATE PLUGGABLE DATABASE or ALTER PLUGGABLE DATABASE statement.There is a default temporary tablespace for the CDB root and for individual containers.
Managing undoA CDB can run in local undo mode or shared undo mode. Local undo mode means that every container in the CDB uses local undo. Shared undo mode means that there is one active undo tablespace for a single-instance CDB, or for an Oracle RAC CDB, there is one active undo tablespace for each instance. In a CDB, the UNDO_MANAGEMENT initialization parameter must be set to AUTO, and an undo tablespace is required to manage the undo data.
Moving data between containersYou can move data between containers using the same methods that you would use to move data between non-CDBs. For example, you can transport the data or use Data Pump export/import to move the data.
Using Oracle Managed FilesUsing Oracle Managed files can simplify administration for both a CDB and a non-CDB.
Using Transparent Data EncryptionTransparent Data Encryption is a feature that enables encryption of individual table columns before storing them in the data file, or enables encryption of entire tablespaces. In a CDB, each container has its own master key for Transparent Data Encryption, and, where applicable, the ADMINISTER KEY MANAGEMENT SQL statement enables key management at the CDB level and for individual containers.
Using a standby databaseOracle Data Guard can configure a physical standby or a logical standby of a CDB. Data Guard operates on the entire CDB, not on individual containers in a CDB.
Using Oracle Database VaultOracle Database Vault common realms can be scoped to an application root on common objects. Database Vault common command rules can be scoped to either the CDB or an application root. Local realms and command rules can be locally scoped to individual PDBs or application PDBs. When Oracle Database Vault security objects are in the CDB root or an application root, enforcement of the security objects only applies to the containers that have Oracle Database Vault enabled.
Dropping a databaseWhen you drop a CDB, all containers in the CDB are dropped along with their data. These containers include the CDB root and PDB seed and all application containers, application seeds, PDBs, and application PDBs. You can also drop individual application containers, application seeds, PDBs, and application PDBs with the DROP PLUGGABLE DATABASE statement.

Using Manageability Features in a CDB

For each of Oracle Database’s manageability features in a CDB, it is important to understand the data location and the data visibility.

When feature data resides in the CDB root, the data is not included when a PDB is unplugged. When the data resides in a PDB, however, the data remains both when the PDB is unplugged and when it is plugged in.

Generally, in a CDB, a common user can view data for the CDB root and for multiple PDBs when the common user’s current container is the CDB root. A common user can view this data by querying container data objects. The specific data that is visible varies for the manageability features. A user whose current container is a PDB can view data for that PDB only.

The following table describes how the manageability features work in a CDB.

Manageability Features in a CDB

Manageability FeatureData LocationData Visibility
Active Session History (ASH) ASH collects information about active database sessions. You can use this information to analyze and identify performance issues.Most of the ASH data is stored in memory. A small percentage of the ASH data samples are stored in the CDB root. ASH data related to a PDB is not included if the PDB is unplugged.A common user whose current container is the CDB root can view ASH data for the CDB root and for PDBs. A user whose current container is a PDB can view ASH data for the PDB only.
Alerts An alert is a notification of a possible problem.Threshold settings that pertain to a PDB are stored in the PDB. Alerts posted when thresholds are violated are enqueued into the alert queue in the CDB root. Threshold settings that pertain to a PDB are included if the PDB is unplugged. Alerts related to a PDB are not included if the PDB is unplugged.A common user whose current container is the CDB root can view alerts for the CDB root and for PDBs. A user whose current container is a PDB can view alert thresholds and alerts for the PDB only.
Automated Database Maintenance Tasks Automated database maintenance tasks are tasks that are started automatically at regular intervals to perform maintenance operations on the database. Automated tasks include automatic optimizer statistics collection, Automatic Segment Advisor tasks, and Automatic SQL Tuning Advisor tasks. The ENABLE_AUTOMATIC_MAINTENANCE_PDB initialization parameter can enable or disable the running of automated maintenance tasks for all the PDBs in a CDB or for individual PDBs in a CDB. The AUTOTASK_MAX_ACTIVE_PDBS initialization parameter limits the number of PDBs that can schedule automated maintenance tasks at the same time (during a maintenance window).A user can schedule maintenance windows and enable or disable maintenance tasks for the current container only. If the current container is the CDB root, then the changes only apply to the CDB root. If the current container is a PDB, then the changes only apply to the PDB. Data related to a PDB is stored in the PDB for automatic optimizer statistics collection and the Automatic Segment Advisor. This data is included if the PDB is unplugged. Automatic SQL Tuning Advisor runs only in the CDB root. See the SQL Tuning Advisor row in this table for information about data collected by Automatic SQL Tuning Advisor.See the appropriate row in this table for data visibility information about the following manageability features: automatic optimizer statistics collection, Optimizer Statistics Advisor, Automatic Segment Advisor, and Automatic SQL Tuning Advisor.
Automatic Database Diagnostic Monitor (ADDM) ADDM can diagnose the performance of a CDB or PDB and determine how identified problems can be resolved.ADDM executions occur in a PDB or in the CDB root. ADDM analyzes data using one of the following sources: AWR data stored inside the PDB through an AWR snapshot taken inside the PDBAWR data from a non-CDB, CDB root, or PDB that is imported into the AWR storage of a PDBAWR data stored in the root container through an AWR snapshot taken in root Before the start of the analysis, ADDM determines the source of the AWR data (PDB or CDB root) and applies the rules applicable to each data type. Note: Automatic ADDM for a PDB is enabled only when automatic snapshots are enabled for the PDB.A common user whose current container is the CDB root can review results for the entire CDB. The ADDM results can include information about multiple PDBs. ADDM results related to a PDB are not included if the PDB is unplugged. The ADDM results cannot be viewed when the current container is a PDB. A user whose current container is a PDB can view ADDM results data for the current PDB only. The results exclude findings that apply to the CDB as a whole, for example, I/O problems relating to the buffer cache size.
Automatic Optimizer Statistics Collection Automatic optimizer statistics collection gathers optimizer statistics for all schema objects in the database for which there are no statistics or only stale statistics. The statistics gathered by this task are used by the SQL query optimizer to improve the performance of SQL execution.When an automatic optimizer statistics collection task gathers data for a PDB, it stores this data in the PDB. This data is included if the PDB is unplugged.A common user whose current container is the CDB root can view optimizer statistics data for PDBs. A user whose current container is a PDB can view optimizer statistics data for the PDB only.
Automatic Segment Advisor The Automatic Segment Advisor identifies segments that have space available for reclamation and makes recommendations on how to defragment those segments.When Automatic Segment Advisor gathers data for a PDB, it stores this data in the PDB. This data is included if the PDB is unplugged.A common user whose current container is the CDB root can view Automatic Segment Advisor data for PDBs. A user whose current container is a PDB can view the Automatic Segment Advisor data for the PDB only.
Automatic Workload Repository (AWR) The AWR collects, processes, and maintains performance statistics for problem detection and self-tuning purposes. This data is stored in the database. The gathered data can be displayed in both reports and views.AWR reports can be generated in the CDB root or in any PDB. AWR reports generated in the CDB root pertain to the entire CDB, while AWR reports generated when a PDB is the current container only pertain to that PDB. AWR data generated in the CDB root is stored in the CDB root. AWR data generated in a PDB is stored in the PDB. When a PDB is unplugged, AWR data stored in the CDB root is not included. When a PDB is unplugged, AWR data stored in the PDB is included.A common user whose current container is the CDB root can view AWR data for the CDB root and for PDBs. A user whose current container is a PDB can view AWR data for the PDB only.
Database Replay Database Replay is a feature of Oracle Real Application Testing. Database Replay captures the workload for a CDB or PDB and replays it exactly on a test database.Capture files are always stored in operating system files, regardless of whether the capture and replay is at the CDB level or PDB level.For CDB-level workloads, a common user whose current container is the CDB root can view database capture and replay information. For PDB-level workloads, a local or common PDB administrator with the SELECT_CATALOG_ROLE privilege can view this information in DBA_WORKLOAD_CAPTURES and DBA_WORKLOAD_REPLAYS.
Optimizer Statistics Advisor Optimizer Statistics Advisor analyzes how statistics are being gathered and suggests changes that can be made to fine tune statistics collection.Data related to a PDB is stored in the PDB for Optimizer Statistics Advisor. This data is included if the PDB is unplugged.A common user whose current container is the CDB root can view Optimizer Statistics Advisor data for PDBs. A user whose current container is a PDB can view the Optimizer Statistics Advisor data for the PDB only.
SQL Management Base (SMB) SMB stores statement logs, plan histories, SQL plan baselines, and SQL profiles in the data dictionary.SMB data related to a PDB is stored in the PDB. The SMB data related to a PDB is included if the PDB is unplugged.A common user whose current container is the CDB root can view SMB data for PDBs. A user whose current container is a PDB can view the SMB data for the PDB only.
SQL Performance Analyzer (SPA) SPA can analyze the SQL performance impact of SQL tuning and other system changes. SPA is often used with Database Replay.A common user whose current container is the CDB root can run SPA for any PDB. In this case, the SPA results data is stored in the CDB root and is not included if the PDB is unplugged. A user whose current container is a PDB can run SPA on the PDB. In this case, the SPA results data is stored in the PDB and is included if the PDB is unplugged.A common user whose current container is the CDB root can view SPA results data for PDBs. A user whose current container is a PDB can view the SPA results data for the PDB only.
SQL Tuning Sets (STS) An STS is a database object that includes one or more SQL statements along with their execution statistics and execution context, and could include a user priority ranking. You can use an STS to tune a group of SQL statements or test their performance using SPA.An STS can be stored in the CDB root or in any PDB. If it is stored in the CDB root, then you can load SQL statements from any PDB into it. When a PDB is unplugged, an STS stored in the CDB root is not included, even if the STS contains SQL statements from the PDB. When a PDB is unplugged, an STS stored in the PDB is included.A common user whose current container is the CDB root can view STS data stored in the CDB root only. A user whose current container is a PDB can view STS data for the PDB only.
SQL Tuning Advisor SQL Tuning Advisor optimizes SQL statements that have been identified as high-load SQL statements.Automatic SQL Tuning Advisor data is stored in the CDB root. It might have results about SQL statements executed in a PDB that were analyzed by the advisor, but these results are not included if the PDB is unplugged. A common user whose current container is the CDB root can run SQL Tuning Advisor manually for SQL statements from any PDB. When a statement is tuned, it is tuned in any container that runs the statement. A user whose current container is a PDB can also run SQL Tuning Advisor manually for SQL statements from the PDB. When SQL Tuning Advisor is run manually from a PDB, the results are stored in the PDB from which it is run. In this case, a statement is tuned only for the current PDB, and the results related to a PDB are included if the PDB is unplugged.When SQL Tuning Advisor is run automatically, the results are visible only to a common user whose current container is the CDB root. These results cannot be viewed when the current container is a PDB. When SQL Tuning Advisor is run manually by a user whose current container is a PDB, the results are only visible to a user whose current container is that PDB.

To run SPA or SQL Tuning Advisor for SQL statements from a PDB, a common user must have the following privileges:

  • Common SET CONTAINER privilege or local SET CONTAINER privilege in the PDB
  • The privileges required to execute the SQL statements in the PDB

To connect to the root using the SQL*Plus CONNECT command:

  1. Configure your environment so that you can open SQL*Plus.
  2. Start SQL*Plus with the /NOLOG argument:
sqlplus /nolog
  • Issue a SQL*Plus CONNECT command to connect to the root, as shown in the following examples.

Connecting to the Root with a Local Connection

This example connects to the root in the local CDB as user SYSTEM. SQL*Plus prompts for the SYSTEM user password.

connect system

Connecting to the Root with Operating System Authentication

This example connects locally to the root with the SYSDBA administrative privilege with operating system authentication.

connect / as sysdba

Connecting to the Root with a Net Service Name

Assume that clients are configured to have a net service name for the root in the CDB. For example, the net service name can be part of an entry in a tnsnames.ora file.

This example connects as common user c##dba to the database service designated by the net service name mycdb. SQL*Plus prompts for the c##dba user password.

connect c##[email protected]
Connecting to a PDB Using the SQL*Plus CONNECT Command

To connect to a PDB with the SQL*Plus CONNECT command, you can use easy connect or a net service name.

To connect to a PDB, a user must be one of the following:

  • A common user with a CREATE SESSION privilege granted commonly or granted locally in the PDB
  • A local user defined in the PDB with CREATE SESSION privilege

Only a user with SYSDBASYSOPERSYSBACKUP, or SYSDG privilege can connect to a PDB that is in mounted mode.

To connect to a PDB using the SQL*Plus CONNECT command:

  1. Configure your environment so that you can open SQL*Plus.
  2. Start SQL*Plus with the /NOLOG argument:
sqlplus /nolog
  • Issue a SQL*Plus CONNECT command using easy connect or a net service name to connect to the PDB.

Connecting to a PDB

Assume that clients are configured to have a net service name for each PDB that matches each PDB name. For example, the net service name can be part of an entry in a tnsnames.ora file.

The following command connects to the sh local user in the salespdb PDB:

CONNECT [email protected]

The following command connects to the SYSTEM common user in the salespdb PDB:

CONNECT [email protected]
Switching to a Container Using the ALTER SESSION Statement

When you are connected to a container as a common user, you can switch to a different container and application service using the ALTER SESSION statement.

You can use the following statement to switch to a different container and application service:

ALTER SESSION SET CONTAINER = container_name [SERVICE = service_name]

For container_name, specify one of the following:

  • CDB$ROOT to switch to the CDB root
  • PDB$SEED to switch to the PDB seed
  • A PDB name to switch to the PDB

When the current container is the root, you can view the names of the PDBs in a CDB by querying the DBA_PDBS view.

For service_name, specify a service that is running in the PDB. You can list the services running in the containers of a CDB, excluding the CDB root, by issuing the following query with the CDB root as the current container:

COL NAME FORMAT A30
COL CON_NAME FORMAT A20
 
SELECT NAME,CON_NAME, CON_ID
  FROM V$ACTIVE_SERVICES
  WHERE UPPER(NAME) != CON_NAME
  AND CON_ID !=1
  ORDER BY CON_ID;

By default, when you switch to a container, the session uses the default service for the container. However, the default PDB service does not support all service attributes and features such as service metrics, Fast Application Notification (FAN), load balancing, Resource Manager, Transaction Guard, Application Continuity, and so on. It is best practice to use a nondefault service for the container by specifying SERVICE = service_name, where service_name is the name of the service.

With this new capability, connection pools can switch the service, and, when needed the PDB, on a connection when a connection is borrowed from the pool. Starting with Oracle Database 12c Release 2 (12.2.0.1), connection pools support more than one database service with universal connection pools (UCPs). It can also be used standalone.

When switching to a service, applications can consolidate to a CDB, while keeping the database services identified, prioritized, measured, and highly available. Switching to a nondefault service provides the following benefits:

  • It preserves the service attributes and features.
  • It eliminates too many connection pools with too many connections serving these tenants.
  • It allows applications to use more database services for workload control without consuming too many connection pools. Customers can identify and prioritize workloads using services without over sizing the database connections.

To switch to a container using the ALTER SESSION statement:

  1. In SQL*Plus, connect to a container as a common user with the required privileges.
  2. Check the current open mode of the container to which you are switching.

To check the current open mode of the root or a PDB, query the OPEN_MODE column in the V$CONTAINERS view when the current container is the root.

The open mode of the root imposes limitations on the open mode of PDBs. For example, the root must be open before any PDBs can be open. Therefore, you might need to change the open mode of the root before changing the open mode of a PDB.

  • If you are switching to a specific service, then ensure that the service is running.

To check the active status of the service, query the V$ACTIVE_SERVICES view when the current container is the CDB root.

If the service is not running, then use the SRVCTL utility or the DBMS_SERVICE package to start the service.

  • Run the ALTER SESSION SET CONTAINER statement and specify the container to which you want to switch.

Include the SERVICE clause to switch to a specific application service.

The following examples switch to various containers using ALTER SESSION.

Switching to the PDB salespdb and Using the salesrep Service

ALTER SESSION SET CONTAINER = salespdb SERVICE = salesrep;

Switching to the PDB salespdb and Using the Default Service

ALTER SESSION SET CONTAINER = salespdb;

Switching to the CDB Root

ALTER SESSION SET CONTAINER = CDB$ROOT;

Switching to the PDB Seed

ALTER SESSION SET CONTAINER = PDB$SEED;

Switching Services Using a Dummy Service in the CDB Root

To design connection pooling that switches the container and the service, one method is to create a dummy service in the CDB root and set all required service attributes on this dummy service (for example, drain_timeout, TAF or Application Continuity). The service attributes must match across the CDB root and the PDB. To use this method, complete the following steps:

  1. Connect to the dummy service when first creating the connection pool and when creating new connections.
  2. As services are added to each PDB, set the same attributes on these real services.
  3. When an application requires a connection, complete one of the following actions:
    1. Create a new connection to the dummy service, and switch to the PDB and service.
    1. Borrow a free connection in the pool and switch to the PDB and service.

You do not need to return to the CDB root when switching across PDBs.

You do not need to return to the CDB root when switching across PDBs.

Modifying a CDB at the System Level

You can set initialization parameters at the CDB level. In some cases, you can override these parameters at the PDB level.

The ALTER SYSTEM SET statement dynamically sets an initialization parameter in one or more containers.

A CDB uses an inheritance model for initialization parameters in which PDBs inherit initialization parameter values from the root. In this case, inheritance means that the value of a specific parameter in the root applies to a specific PDB.

A PDB can override the root setting for some parameters. In such cases, a PDB has an inheritance property for each initialization parameter that is either true or false. The inheritance property is true for a parameter when the PDB inherits the root’s value for the parameter; otherwise, the property is false.

The inheritance property for some parameters must be true. For other parameters, when the current container is the PDB, you can change the inheritance property by running the ALTER SYSTEM SET statement. If V$SYSTEM_PARAMETER.ISPDB_MODIFIABLE is TRUE for an initialization parameter, then the inheritance property can be false for the parameter.

When the current container is the root, the CONTAINER clause of the ALTER SYSTEM SET statement controls which PDBs inherit the parameter value being set. The CONTAINER clause has the following syntax:

CONTAINER = { CURRENT | ALL }

The following settings are possible:

  • CURRENT

The parameter setting applies only to the current container. This is the default setting for CONTAINER. When the current container is the root, the parameter setting applies to the root and to any PDB with an inheritance property of true for the parameter.

  • ALL

The parameter setting applies to all containers in the CDB, including the root and all PDBs. Specifying ALL sets the inheritance property to true for the parameter in all PDBs.

Modifying a CDB with ALTER SYSTEM

To modify a CDB at the system level, use the ALTER SYSTEM statement.

To use ALTER SYSTEM SET in the root in a CDB:

  1. In SQL*Plus, ensure that the current container is the root.
  2. Run the ALTER SYSTEM SET statement.
ALTER SYSTEM RESET OPEN_CURSORS SCOPE = SPFILE;

Setting an Initialization Parameter for All Containers

This ALTER SYSTEM SET statement sets the OPEN_CURSORS initialization parameter to 200 for the all containers and sets the inheritance property to TRUE in each PDB.

ALTER SYSTEM SET OPEN_CURSORS = 200 CONTAINER = ALL;

Setting an Initialization Parameter for the Root

This ALTER SYSTEM SET statement sets the OPEN_CURSORS initialization parameter to 200 for the root and for PDBs with an inheritance property of true for the parameter.

ALTER SYSTEM SET OPEN_CURSORS = 200 CONTAINER = CURRENT;

Modifying Containers When Connected to the CDB Root

You can modify the entire CDB or the root with the ALTER DATABASE statement.

The ALTER DATABASE statement modifies a CDB. When you are connected to the CDB root, the ALTER PLUGGABLE DATABASE statement can modify the open mode of one or more PDBs.

The behavior of ALTER DATABASE and ALTER PLUGGABLE DATABASE depends on which container you are connected to when you use the statement:

  • Connected as a common user to CDB root

In this case, the ALTER DATABASE statement works the same as in a non-CDB. When an ALTER DATABASE statement with the RENAME GLOBAL_NAME clause modifies the domain of a CDB, it affects the domain of each PDB with a domain that defaults to that of the CDB. The ALTER PLUGGABLE DATABASE statement with the pdb_change_state clause modifies the open mode of one or more PDBs.

  • Connected to a PDB

In this case, the ALTER DATABASE and ALTER PLUGGABLE DATABASE statements modify the current PDB only.

The following table lists which containers are modified by clauses in ALTER DATABASE and ALTER PLUGGABLE DATABASE statements.

Statements That Modify Containers in a CDB

Modify Entire CDBModify Root OnlyModify One or More PDBs
When connected as a common user whose current container is the root, ALTER DATABASE statements with the following clauses modify the entire CDB: startup_clausesrecovery_clauseslogfile_clausescontrolfile_clausesstandby_database_clausesinstance_clausessecurity_clauseRENAME GLOBAL_NAME clauseENABLE BLOCK CHANGE TRACKING clauseDISABLE BLOCK CHANGE TRACKING clauseWhen connected as a common user whose current container is the root, ALTER DATABASE statements with the following clauses modify the root only: database_file_clausesDEFAULT EDITION clauseDEFAULT TABLESPACE clauseDEFAULT TEMPORARY TABLESPACE clause ALTER DATABASE statements with the following clauses modify the root and set default values for PDBs: flashback_mode_clauseSET DEFAULT {BIGFILE|SMALLFILE} TABLESPACE clauseset_time_zone_clause You can use these clauses to set nondefault values for specific PDBs.When connected as a common user whose current container is the root, ALTER PLUGGABLE DATABASE statements with the following clause can modify the open mode of one or more PDBs: pdb_change_state When the current container is a PDB, ALTER PLUGGABLE DATABASE statements with this clause can modify the open mode of the current PDB. When connected as a common user whose current container is the root, ALTER PLUGGABLE DATABASE statements with the following clause can preserve or discard the open mode a PDB when the CDB restarts: pdb_save_or_discard_state

Modifying an Entire CDB Using ALTER DATABASE

You can use the ALTER DATABASE statement to modify an entire CDB, including the root and all PDBs. Most ALTER DATABASE statements modify the entire CDB.

Prerequisites

To modify an entire CDB, the following prerequisites must be met:

  • The current user must be a common user with the ALTER DATABASE privilege.
  • To use an ALTER DATABASE statement with a recovery_clause, the current user must have the SYSDBA administrative privilege commonly granted. In this case, you must exercise this privilege using AS SYSDBA at connect time.

To modify an entire CDB:

  1. In SQL*Plus, ensure that the current container is the root.
  2. Use an ALTER DATABASE statement with a clause that modifies an entire CDB.

Backing Up the Control File for a CDB

The following ALTER DATABASE statement uses a recovery_clause to back up a control file.

ALTER DATABASE BACKUP CONTROLFILE TO '+DATA/dbs/backup/control.bkp';

Adding a Redo Log File to a CDB

The following ALTER DATABASE statement uses a logfile_clause to add redo log files.

ALTER DATABASE cdb ADD LOGFILE
  GROUP 4 ('/u01/logs/orcl/redo04a.log','/u02/logs/orcl/redo04b.log')
  SIZE 100M BLOCKSIZE 512 REUSE;

Setting the Undo Mode in a CDB Using ALTER DATABASE

When local undo is enabled, each container has its own undo tablespace for every instance in which it is open. When local undo is disabled, there is one undo tablespace for the entire CDB.

CDB Undo Mode

You can configure a CDB to use local undo in every container or to use shared undo (default) for the entire CDB.

A CDB runs either in local or shared undo mode. The undo mode applies to the entire CDB. Therefore, every container either uses shared undo or local undo.

You can specify the undo mode of a CDB during CDB creation in the ENABLE PLUGGABLE DATABASE clause of the CREATE DATABASE statement. If you do not specify the UNDO clause, then shared undo mode is the default. You can change the undo mode of a CDB after it is created by issuing an ALTER DATABASE statement and restarting the CDB.

To determine the current CDB undo mode, run the following query in the CDB root:

SELECT PROPERTY_NAME, PROPERTY_VALUE
FROM   DATABASE_PROPERTIES
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';

If the query returns TRUE for the PROPERTY_VALUE, then the CDB is in local undo mode. Otherwise, the CDB is in shared undo mode.

Local Undo Mode

Local undo mode means that each container has its own undo tablespace for every instance in which it is open.

In this mode, Oracle Database automatically creates an undo tablespace for every container in the CDB. For an Oracle RAC CDB, there is one active undo tablespace for each instance for each PDB in local undo mode.

Local undo mode provides increased isolation for each container and improves the efficiency of some operations, such as unplugging the container or performing point-in-time recovery on the container. In addition, local undo mode is required for some operations to be supported, such as relocating a PDB or cloning a PDB that is in open read/write mode.

When a CDB is in local undo mode, the following applies:

  • Any user who has the appropriate privileges for the current container can create an undo tablespace for the container.
  • Undo tablespaces are visible in static data dictionary views and dynamic performance (V$) views in every container in the CDB.
Shared Undo Mode

Shared undo mode means that only one active undo tablespace exists for a single-instance CDB. For an Oracle RAC CDB, there is one active undo tablespace for each instance.

When a CDB is in shared undo mode, the following applies:

  • Only a common user who has the appropriate privileges and whose current container is the CDB root can create an undo tablespace.
  • When the current container is not the CDB root, an attempt to create an undo tablespace fails and returns an error.
  • Undo tablespaces are visible in static data dictionary views and dynamic performance (V$) views when the current container is the CDB root. Undo tablespaces are visible only in dynamic performance views when the current container is a PDB, an application root, or an application PDB.
Configuring a CDB to Use Local Undo Mode

You can change a CDB to local undo mode by issuing an ALTER DATABASE LOCAL UNDO ON statement and restarting the database.

When a CDB is in local undo mode, each container has its own undo tablespace for every instance in which it is open. Oracle Database automatically creates an undo tablespace in any container in the CDB that does not have one. If a PDB without an undo tablespace is cloned, relocated, or plugged into a CDB that is configured to use local undo mode, then Oracle Database automatically creates an undo tablespace for the PDB the first time it is opened.

When a CDB is changed from shared undo mode to local undo mode, Oracle Database creates the required undo tablespaces automatically.

  1. If the CDB instance is open, then shut it down.
  2. Start up the CDB instance in OPEN UPGRADE mode. For example:

STARTUP UPGRADE

  1. In SQL*Plus, ensure that the current container is the CDB root. For example, enter the following:
SHOW CON_NAME
 
CON_NAME
------------------------------
CDB$ROOT
  1. Query the current undo mode of the CDB:
SELECT PROPERTY_NAME, PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
  1. To enable local undo, issue the following SQL statement:

ALTER DATABASE LOCAL UNDO ON;

  1. Shut down and restart the CDB instance.
  2. Optional: Manually create an undo tablespace in the PDB seed.

While Oracle Database creates an undo tablespace in the PDB seed automatically in local undo mode, you might want to control the size and configuration of the undo tablespace by creating an undo tablespace manually. To ensure the PDBs created from the PDB seed use the manually-created undo tablespace and not the automatically-created undo tablespace, you must set the UNDO_TABLESPACE initialization parameter to the manually-created undo tablespace, or drop the automatically-created undo tablespace.

  1. In SQL*Plus, ensure that the current container is the root.
  2. Place the PDB seed in open read/write mode:

ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ WRITE FORCE;

  1. Switch container to the PDB seed:

ALTER SESSION SET CONTAINER=PDB$SEED;

  1. Create an undo tablespace in the PDB seed. For example:
CREATE UNDO TABLESPACE seedundots1
   DATAFILE 'seedundotbs_1a.dbf'
   SIZE 10M AUTOEXTEND ON
RETENTION GUARANTEE;
  1. Switch container to the root:

ALTER SESSION SET CONTAINER=CDB$ROOT;

  1. Place the PDB seed in open read-only mode:

ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ ONLY FORCE;

Configuring a CDB to Use Shared Undo Mode

To change a CDB to use shared undo mode, use an ALTER DATABASE LOCAL UNDO OFF statement.

  1. If the CDB instance is open, then shut it down.
  2. Start up the CDB instance in OPEN UPGRADE mode. For example:

STARTUP UPGRADE

  1. In SQL*Plus, ensure that the current container is the CDB root. For example, enter the following:
SHOW CON_NAME
 
CON_NAME
------------------------------
CDB$ROOT
  1. Optionally, query the current undo mode of the CDB:
SELECT PROPERTY_NAME, PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';
  1. To turn off local undo, issue the following SQL statement:

ALTER DATABASE LOCAL UNDO OFF;

  1. Shut down and restart the CDB instance.

When in shared undo mode, the CDB ignores any local undo tablespaces that were created when it was in local undo mode. Oracle recommends that you delete the unused local undo tablespaces.

Modifying the CDB Root Using ALTER DATABASE

To modify only the root of a CDB, use the ALTER DATABASE statement.

When the current container is the root, some ALTER DATABASE statements modify the root without directly modifying any of the PDBs.

Some statements set the defaults for the PDBs in the CDB. You can overwrite these defaults for a PDB by using the ALTER PLUGGABLE DATABASE statement.

Prerequisites

To modify the root, the current user must have the ALTER DATABASE privilege in the root.

To modify the root:

  1. In SQL*Plus, ensure that the current container is the root.
  2. Run an ALTER DATABASE statement with a clause that modifies the root.

The following examples modify the root.

A user whose current container is the root that is not explicitly assigned a tablespace uses the default permanent tablespace for the root. The tablespace specified in the ALTER DATABASE statement must exist in the root.

After executing this statement, the default type of subsequently created tablespaces in the root is bigfile. This setting is also the default for PDBs.

The tablespace or tablespace group specified in the ALTER DATABASE statement must exist in the root.

Changing the Default Permanent Tablespace for the Root

This ALTER DATABASE statement uses a DEFAULT TABLESPACE clause to set the default permanent tablespace to root_tbs for the root.

ALTER DATABASE DEFAULT TABLESPACE root_tbs;

Bringing a Data File Online for the Root

This ALTER DATABASE statement uses a database_file_clause to bring the /u02/oracle/cdb_01.dbf data file online.

ALTER DATABASE DATAFILE '/u02/oracle/cdb_01.dbf' ONLINE;

Changing the Default Tablespace Type for the Root

This ALTER DATABASE statement uses a SET DEFAULT TABLESPACE clause to change the default tablespace type to bigfile for the root.

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

Changing the Default Temporary Tablespace for the Root

This ALTER DATABASE statement uses a DEFAULT TEMPORARY TABLESPACE clause to set the default temporary tablespace to root_temp for the root.

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE root_temp;

Executing SQL in a Different Container

To execute SQL in a different container, use the CONTAINERS clause for DML or the CONTAINER clause for DDL.

Issuing DML Statements on a Container in a CDB

A DML (data manipulation language) statement issued in a CDB or application root can modify a different container in the CDB. In addition, you can specify a default container target for DML statements.

DML statements can affect database objects in a specified container in a CDB.

The container is specified by container ID. Because the container ID can appear in more than one location, the database uses the following order of precedence:

  1. The CON_ID specified in the WHERE clause of a DML statement
  2. The CONTAINERS_DEFAULT_TARGET database property
  3. The current container, which is either the CDB root or application root

In a CDB root or an application root, a DML statement that includes the CONTAINERS clause can modify a table or view in a single container in the CDB or application container. To use the CONTAINERS clause, specify the table or view being modified in the CONTAINERS clause and the container ID affected in the WHERE clause.

You can specify a target container in an INSERT VALUES statement by specifying a value for CON_ID in the VALUES clause. Also, you can specify a target container in an UPDATE or DELETE statement by specifying a CON_ID predicate in the WHERE clause. For example, the following DML statement updates the sales.customers table in the container with a CON_ID of 7:

UPDATE CONTAINERS(sales.customers) ctab 
   SET ctab.city_name='MIAMI' 
   WHERE ctab.CON_ID=7 
   AND CUSTOMER_ID=3425;
Specifying the Default Container for DML Statements in a CDB

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

When a DML statement is issued in a CDB root without specifying containers in the WHERE clause, the DML statement affects the default container for the CDB. The default container can be any container in the CDB, including the CDB root, a PDB, an application root, or an application PDB. Only one default container is allowed.

The CONTAINERS_DEFAULT_TARGET database property sets the default container. By default, this property is not set. You can determine the default target containers for a CDB by running the following query:

SELECT PROPERTY_VALUE 
FROM   DATABASE_PROPERTIES 
WHERE  PROPERTY_NAME='CONTAINERS_DEFAULT_TARGET';
  1. In SQL*Plus, ensure that the current container is the CDB root or application root.

The current user must have the commonly granted ALTER DATABASE privilege.

  1. Run the ALTER DATABASE statement with the CONTAINERS DEFAULT TARGET clause.

Specifying the Default Container for DML Statements in a CDB

This example specifies that PDB1 is the default container for DML statements in the CDB.

ALTER DATABASE CONTAINERS DEFAULT TARGET = (PDB1);

Clearing the Default Container

This example clears the default container setting. When it is not set, the default container is the CDB root.

ALTER DATABASE CONTAINERS DEFAULT TARGET = NONE;

Executing DDL Statements in a CDB

In a CDB, you can execute a data definition language (DDL) statement in the current container or in all containers.

In a CDB, some DDL statements can apply to all containers or to the current container only.

To specify which containers are affected, use the CONTAINER clause:

CONTAINER = { CURRENT | ALL }

The following settings are possible:

  • CURRENT means that the statement applies only to the current container.
  • ALL means that the statement applies to all containers in the CDB, including the root and all PDBs.

The following restrictions apply to the CONTAINER clause in DDL statements:

  • You can use the CONTAINER clause only with the DDL statements.

Statements and the CONTAINER Clause in a CDB

DDL StatementCONTAINER = CURRENTCONTAINER = ALL
CREATE USERCreates a local user in the current PDB.Creates a common user.
ALTER USERAlters a local user in the current PDB.Alters a common user.
CREATE ROLECreates a local role in the current PDB.Creates a common role.
GRANTGrants a privilege in the local container to a local user, common user, or local role. The SET CONTAINER privilege can be granted to a user-created common user in the current PDB.Grants a system privilege or object privilege on a common object to a common user or common role. The specified privilege is granted to the user or role across the entire CDB.
REVOKERevokes a privilege in the local container from a local user, common user, or local role. This statement can revoke only a privilege granted with CURRENT specified in the CONTAINER clause from the specified user or role in the local container. The statement does not affect privileges granted with ALL specified in the CONTAINER clause. The SET CONTAINER privilege can be revoked from a user-created common user in the current PDB.Revokes a system privilege or object privilege on a common object from a common user or common role. The specified privilege is revoked from the user or role across the entire CDB. This statement can revoke only a privilege granted with ALL specified in the CONTAINER clause from the specified common user or common role. The statement does not affect privileges granted with CURRENT specified in the CONTAINER clause. However, any privileges granted locally that depend on the privilege granted commonly that is being revoked are also revoked.

All other DDL statements apply to the current container only.

In addition to the usual rules for user, role, and profile names, the following rules and best practices apply when you create a user, role, or profile in a CDB:

  • It is best practice for common user, role, and profile names to start with a prefix to avoid naming conflicts between common users, roles, and profiles and local users, roles, and profiles. You specify this prefix with the COMMON_USER_PREFIX initialization parameter in the CDB root. By default, the prefix is C## or c## in the CDB root.
  • In an application container, it is best practice for application common user, role, and profile names to start with a prefix to avoid naming conflicts between application common users, roles, and profiles and local users, roles, and profiles. You specify this prefix with the COMMON_USER_PREFIX initialization parameter in the application root. By default, the prefix is NULL in an application root.
  • When the COMMON_USER_PREFIX initialization parameter is set in an application root, the setting applies to the application common user, role, and profile names in the application container. The prefix can be different in the CDB root and in an application root, and the prefix can be different in different application containers.
  • Common user, role, and profile names must consist only of ASCII characters. This restriction does not apply to application common user, role, and profile names.
  • Local user, role, and profile names cannot start with the prefix specified for common users with the COMMON_USER_PREFIX initialization parameter.
  • Local user, role, and profile names cannot start with C## or c##.
  • Regardless of the value of COMMON_USER_PREFIX in the CDB root, application common user, role, and profile names cannot start with C## or c##.
  • Application common user, role, and profile names cannot start with the prefix specified for common users with the COMMON_USER_PREFIX initialization parameter.
Executing a DDL Statement in the Current Container

Specify CURRENT in the CONTAINER clause of a DDL statement to execute the statement in the current container.

The current user must be granted the required privileges to execute the DDL statement in the current container. For example, to create a user, the current user must be granted the CREATE USER system privilege in the current container.

To execute a DDL statement in the current container:

  1. In SQL*Plus, access a container.
  2. Execute the DDL statement with CONTAINER set to CURRENT.

A local user’s user name cannot start with the prefix specified by the COMMON_USER_PREFIX initialization parameter. By default, in the CDB root, the prefix is C## or c##. An application root can specify its own prefix for an application container. In addition, a common user’s name must consist only of ASCII characters. The specified tablespace must exist in the PDB.

Creating Local User in a PDB

This example creates the local user testpdb in the current PDB.

CREATE USER testpdb IDENTIFIED BY password 
   DEFAULT TABLESPACE pdb1_tbs
   QUOTA UNLIMITED ON pdb1_tbs
   CONTAINER = CURRENT;
Executing a DDL Statement in All Containers in a CDB

Specify ALL in the CONTAINER clause of a DDL statement to execute the statement in all containers in a CDB.

To execute a DDL statement in all containers in a CDB:

  1. In SQL*Plus, ensure that the current container is the root.
  2. Execute the DDL statement with CONTAINER set to ALL.

A common user’s user name must start with the prefix specified by the COMMON_USER_PREFIX initialization parameter. By default, in the CDB root, the prefix is C## or c##. An application root can specify its own prefix for an application container. In addition, a common user’s name must consist only of ASCII characters. The specified tablespace must exist in the root and in all PDBs.

Creating Common User in a CDB

This example creates the common user c##testcdb.

CREATE USER c##testcdb IDENTIFIED BY password 
   DEFAULT TABLESPACE cdb_tbs
   QUOTA UNLIMITED ON cdb_tbs
   CONTAINER = ALL;

Running Oracle-Supplied SQL Scripts in a CDB

You can use the catcon.pl script to run Oracle-supplied SQL or SQL scripts within a CDB. You can run the script against any specified containers.

In a CDB, the catcon.pl script is the best way to run SQL scripts and SQL statements.

An Oracle Database installation includes several SQL scripts. These scripts perform operations such as creating data dictionary views and installing options.

The catcon.pl script can run scripts in the root and in specified PDBs in the correct order, and it generates log files that you can view to confirm that the SQL script or SQL statement did not generate unexpected errors. It also starts multiple processes and assigns new scripts to them as they finish running scripts previously assigned to them.

Syntax and Parameters for catcon.pl

The catcon.pl script is a Perl script that must be run at an operating system prompt.

The catcon.pl script has the following syntax and parameters:

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl  
[--usr username[/password]] 
[--int_usr username[/password]] 
[--script_dir directory] 
[--log_dir directory] 
[{--incl_con|--excl_con} container] 
[--echo] 
[--spool] 
[--error_logging { ON | errorlogging-table-other-than-SPERRORLOG } ] 
[--app_con application_root] 
[--no_set_errlog_ident] 
[--diag] 
[-ignore_unavailable_pdbs] 
[--verbose] 
[--force_pdb_mode pdb_mode] 
[--recover] 
--log_file_base log_file_name_base 
-- { SQL_script [arguments] | --x'SQL_statement' }

Ensure that --x SQL_statement is preceded by -- if it follows any single-letter parameter. If --x SQL_statement is preceded by a script name or another --x SQL_statement, then do not precede it with --. Also, note that the SQL statement must be inside single quotation marks.

Command line parameters to SQL scripts can be introduced using --p. Interactive (or secret) parameters to SQL scripts can be introduced using --P.

To view the help for the catcon.pl script, change directories to $ORACLE_HOME/perl/bin/, and then run the following command:

perl $ORACLE_HOME/rdbms/admin/catcon.pl --help

The following table describes the catcon.pl parameters. A parameter is optional unless it is indicated that it is required.

The short parameter names in the following table are for backward compatibility. Some parameters do not have short names.

catcon.pl Parameters

ParameterShort NameDescription
--usr-uSpecifies the user name and password to connect to the root and the specified PDBs. Specify a common user with the required privileges to run the SQL script or the SQL statement. The default is “/ AS SYSDBA“. If no password is supplied, then catcon.pl prompts for a password.
--int_usr-USpecifies the user name and password to connect to the root and the specified PDBs. Specify a common user with the required privileges to perform internal tasks, such as querying CDB metadata. The default is / AS SYSDBA. If no password is supplied, then catcon.pl prompts for a password.
--script_dir-dDirectory that contains the SQL script. The default is the current directory.
--log_dir-lDirectory into which catcon.pl writes log files. The default is the current directory.
{--incl_con|--excl_con}{-c|-C}The containers in which the SQL script is run or is not run. The --incl_con parameter lists the containers in which the SQL script is run. The --excl_con parameter lists the containers in which the SQL script is not run. Specify containers in a space-delimited list of PDB names enclosed in single quotation marks. The --incl_con and --excl_con parameters are mutually exclusive. When this parameter is used, the --app_con parameter cannot be used.
--echo-eSets echo ON while running the script. The default is echo OFF.
--spool-sSpools the output of every script into a file with the following name: log-file-name-base_script-name-without-extension_[container-name-if-any].default-extension
--error_logging-EWhen set to ON, the default error logging table is used. ON is the default setting. When set to ON, errors are written to the table SPERRORLOG in the current schema in each container in which the SQL script runs. If this table does not exist in a container, then it is created automatically. When a table other than SPERRORLOG is specified, errors are written to the specified table. The table must exist in each container in which the SQL script runs, and the current user must have the necessary privileges to perform DML operations on the table in each of these containers.
--app_con-FSpecify an application root. The scripts are run in the application root and in the application PDBs that are plugged into the application root. When this parameter is used, the --incl_con and --excl_con parameters cannot be used.
--no_set_errlog_ident-IDo not issue a SET ERRORLOGGING identifier. This option is intended for cases in which the SET ERRORLOGGING identifier is already set and should not be overwritten.
--diag-gTurns on the generation of debugging information.
--verbose-vTurns on verbose output.
--ignore_unavailable_pdbs-fIgnore PDBs that are closed or, if the --incl_con or --excl_con option is used, do not exist and process only open PDBs that were specified explicitly or implicitly. When this option is not specified and some specified PDBs do not exist or are not open, an error is returned and none of the containers are processed.
--force_pdb_moden/aThe required open mode for all PDBs against which the scripts are run. Specify one of the following values: UNCHANGEDREAD WRITEREAD ONLYUPGRADEDOWNGRADE When a value other than UNCHANGED is specified, all of the PDBs against which the script is run are changed to the specified open mode. If a PDB is open in a different mode, then the PDB is closed and re-opened in the specified mode. After all of the scripts are run, each PDB is restored to its original open mode. When UNCHANGED, the default, is specified, the open mode of the PDBs is not changed.
--recover-RCauses catcon.pl to attempt to recover if a SQL*Plus process that it spawned ends unexpectedly. When this parameter is not specified, catcon.pl does not attempt to recover the process and closes.
--log_file_base-b(Required) The base name for log file names.
Running the catcon.pl Script

Examples illustrate running the catcon.pl script.

If a SQL script or SQL statement run by catcon.pl performs data manipulation language (DML) or data definition language (DDL) operations, then the containers being modified must be in read/write mode.

To run the catcon.pl script:

  1. Open a command line prompt.
  2. Run the catcon.pl script and specify one or more SQL scripts or SQL statements:
cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl parameters SQL_script
perl $ORACLE_HOME/rdbms/admin/catcon.pl parameters -- --xSQL_statement

Running the catblock.sql Script in All Containers in a CDB

The following example runs the catblock.sql script in all of the containers of a CDB (the backslash indicates line continuation):

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_file_base catblock_output catblock.sql

The following parameters are specified:

  • The --usr parameter specifies that SYS user runs the script in each container.
  • The --script_dir parameter specifies that the SQL script is in the $ORACLE_HOME/rdbms/admin directory.
  • The --log_file_base parameter specifies that the base name for log file names is catblock_output.

Default parameter values are used for all other parameters. Neither the --incl_con nor the --excl_con parameter is specified. Therefore, catcon.pl runs the script in all containers by default.

Running the catblock.sql Script in Specific PDBs

The following example runs the catblock.sql script in the hrpdb and salespdb PDBs in a CDB.

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --int_usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_dir '/disk1/script_output' --incl_con 'HRPDB SALESPDB' \
--log_file_base catblock_output catblock.sql

The following parameters are specified:

  • The --usr parameter specifies that SYS user runs the script in each container.
  • The --int_usr parameter specifies that SYS user performs internal tasks.
  • The --script_dir parameter specifies that the SQL script is in the $ORACLE_HOME/rdbms/admin directory.
  • The --log_dir parameter specifies that the output files are placed in the /disk1/script_output directory.
  • The --incl_con parameter specifies that the SQL script is run in the hrpdb and salespdb PDBs. The script is not run in any other containers in the CDB.
  • The --log_file_base parameter specifies that the base name for log file names is catblock_output.

Running the catblock.sql Script in All Containers Except for Specific PDBs

The following example runs the catblock.sql script in all of the containers in a CDB except for the hrpdb and salespdb PDBs.

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl \
--usr SYS --script_dir $ORACLE_HOME/rdbms/admin \
--log_dir '/disk1/script_output' --excl_con 'HRPDB SALESPDB' \ 
--log_file_base catblock_output catblock.sql

The following parameters are specified:

  • The --usr parameter specifies that SYS user runs the script in each container.
  • The --script_dir parameter specifies that the SQL script is in the $ORACLE_HOME/rdbms/admin directory.
  • The --log_dir parameter specifies that the output files are placed in the /disk1/script_output directory.
  • The --excl_con parameter specifies that the SQL script is run in all of the containers in the CDB except for the hrpdb and salespdb PDBs.
  • The --log_file_base parameter specifies that the base name for log file names is catblock_output.

Running a SQL Script with Command Line Parameters

The following example runs the custom_script.sql script in all of the containers of a CDB.

cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl --usr SYS --script_dir /u01/scripts \
--log_file_base custom_script_output custom_script.sql '--phr' \
'--PEnter password for user hr:'

The following parameters are specified:

  • The --usr parameter specifies that SYS user runs the script in each container.
  • The --script_dir parameter specifies that the SQL script is in the /u01/scripts directory.
  • The --log_file_base parameter specifies that the base name for log file names is custom_script_output.
  • The --p parameter specifies hr for a command line parameter
  • The --P parameter specifies an interactive parameter that prompts for the password of user hr.

Default parameter values are used for all other parameters. Neither the -incl_con nor the -excl_con parameter is specified. Therefore, catcon.pl runs the script in all containers by default.

Running a SQL Statement in All Containers in a CDB

The following example runs a SQL statement in all of the containers of a CDB.

cd $ORACLE_HOME/perl/bin/
perl $ORACLE_HOME/rdbms/admin/catcon.pl --usr SYS --echo \
--log_file_base select_output -- --x"SELECT * FROM DUAL"

The following parameters are specified:

  • The --usr parameter specifies that SYS user runs the script in each container.
  • The --echo parameter shows output for the SQL statement.
  • The --log_file_base parameter specifies that the base name for log file names is select_output.
  • The SQL statement SELECT * FROM DUAL is inside quotation marks and is preceded by --x. Because --x is preceded by a parameter (--log_file_base), it must be preceded by --.

Default parameter values are used for all other parameters. Neither the -incl_con nor the -excl_con parameter is specified. Therefore, catcon.pl runs the SQL statement in all containers by default.

Executing Code in Containers Using the DBMS_SQL Package

When you are executing PL/SQL code in a container in a CDB, and you want to execute one or more SQL statements in a different container, use the DBMS_SQL package to switch containers.

For example, you can use the DBMS_SQL package to switch containers when you need to perform identical actions in more than one container.

The following are considerations for using DBMS_SQL to switch containers:

  • A transaction cannot span multiple containers.

If the set of actions you must perform in the target container requires a transaction, then consider using an autonomous transaction and perform a commit or rollback as the last action.

  • SET ROLE statements are not allowed.

Performing Identical Actions in More Than One Container

This example includes a PL/SQL block that creates the identact table in the hr schema in two PDBs (pdb1 and pdb2). The example also inserts a row into the identact table in both PDBs.

DECLARE
  c1 INTEGER;
  rowcount INTEGER;
  taskList VARCHAR2(32767) :=
    'DECLARE
      PRAGMA AUTONOMOUS TRANSACTION;
     BEGIN
       -- Create the hr.identact table.
       EXECUTE IMMEDIATE
         ''CREATE TABLE hr.identact
             (actionno NUMBER(4) NOT NULL,
              action VARCHAR2 (10))'';
       EXECUTE IMMEDIATE
         ''INSERT INTO identact VALUES(1, 'ACTION1')'';
       -- A commit is required if the tasks include DML.
       COMMIT;
       EXCEPTION
         WHEN OTHERS THEN
           -- If there are errors, then drop the table.
           BEGIN
             EXECUTE IMMEDIATE ''DROP TABLE identact'';
           EXCEPTION
            WHEN OTHERS THEN
              NULL;
            END;
        END;';
  TYPE containerListType IS TABLE OF VARCHAR2(128) INDEX BY PLS_INTEGER;
  containerList  containerListType;
BEGIN
  containerList(1) := 'PDB1';
  containerList(2) := 'PDB2';
  c1 := DBMS_SQL.OPEN_CURSOR;
  FOR conIndex IN containerList.first..containerList.last LOOP
    DBMS_OUTPUT.PUT_LINE('Creating in container: ' || containerList(conIndex));
    DBMS_SQL.PARSE(
      c => c1 ,
      statement                  => taskList,
      language_flag              => DBMS_SQL.NATIVE,
      edition                    => NULL,
      apply_crossedition_trigger => NULL,
      fire_apply_trigger         => NULL,
      schema                     => 'HR',
      container                  => containerList(conIndex));
     rowcount := DBMS_SQL.EXECUTE(c=>c1);
  END LOOP;
  DBMS_SQL.CLOSE_CURSOR(c=>c1);
END;
/

Shutting Down a CDB Instance

You can shut down a CDB instance in the same way that you shut down a non-CDB instance.

Prerequisites

The following prerequisites must be met:

  • The CDB instance must be mounted or open.
  • The current user must be a common user with SYSDBASYSOPERSYSBACKUP, or SYSDG administrative privilege. To shut down a CDB, you must exercise this privilege using AS SYSDBAAS SYSOPERAS SYSBACKUP, or AS SYSDG, respectively, at connect time.