37 Creating and Configuring a CDB

Creating and configuring a  multitenant container database (CDB) includes tasks such as planning for CDB creation, creating the CDB, and optionally configuring EM Express for the CDB.

37.1 About Creating a CDB

The procedure for creating a multitenant container database (CDB) is very similar to the procedure for creating a non-CDB.

The procedure for creating a non-CDB is described in Creating and Configuring an Oracle Database. Before creating a CDB, you must understand the concepts and tasks described in Creating and Configuring an Oracle Database.

This chapter describes special considerations for creating a CDB. This chapter also describes differences between the procedure for creating a non-CDB in Creating and Configuring an Oracle Database and the procedure for creating a CDB.

After you plan your CDB using some of the guidelines presented in "Planning for CDB Creation", you can create the CDB either during or after Oracle Database software installation. The following are typical reasons to create a CDB after installation:

  • You used Oracle Universal Installer (OUI) to install software only, and did not create a CDB.

  • You want to create another CDB on the same host as an existing CDB or an existing non-CDB. In this case, this chapter assumes that the new CDB uses the same Oracle home as the existing database. You can also create the CDB in a new Oracle home by running OUI again.

The specific methods for creating a CDB are:

37.2 Planning for CDB Creation

CDB creation prepares several operating system files to work together as a CDB.

Note:

Before planning for CDBs, review the conceptual information about CDBs and PDBs in Oracle Database Concepts.

37.2.1 Decide How to Configure the CDB

Prepare to create the CDB by research and careful planning.

Table 37-1 lists some recommended actions and considerations that apply to CDBs. For more information about many of the actions in Table 37-1, see Table 2-1.

Table 37-1 Planning for a CDB

Action Considerations for a CDB Additional Information

Plan the tables and indexes for the pluggable databases (PDBs) and estimate the amount of space they will require.

In a CDB, most user data is in the PDBs. The root contains no user data or minimal user data. Plan for the PDBs that will be part of the CDB. The disk storage space requirement for a CDB is the space required for the Oracle Database installation plus the sum of the space requirements for all of the PDBs that will be part of the CDB. A CDB can contain up to 4,096 PDBs, but you can limit the CDB to a smaller number of PDBs by setting the MAX_PDBS initialization parameter.

You can also create application containers in a CDB. An application container is a collection of application PDBs that store the data for one or more applications. In addition, application containers support user-created application common objects that can be shared by the application PDBs in the application container.

" Oracle Database Structure and Storage"

Schema Objects

"Creating and Removing PDBs with SQL*Plus"

"Application Containers"

Plan the layout of the underlying operating system files your CDB will comprise.

There are separate data files for the root, the CDB seed, each PDB, each application root, and each application PDB.

There is one redo log for a single-instance CDB, or one redo log for each instance of an Oracle Real Application Clusters (Oracle RAC) CDB. Also, for Oracle RAC, all data files and redo log files must be on shared storage.

" Using Oracle Managed Files"

Oracle Automatic Storage Management Administrator's Guide

Oracle Database Performance Tuning Guide

Oracle Database Backup and Recovery User's Guide

Oracle Grid Infrastructure Installation Guide for information about configuring storage for Oracle RAC

Your Oracle operating system–specific documentation, including the appropriate Oracle Database installation guide.

Plan for the number of background processes that will be required by the CDB.

There is one set of background processes shared by the root and all PDBs.

"Specifying the Maximum Number of Processes"

Select the global database name, which is the name and location of the CDB within the network structure, and create the global database name for the root by setting both the DB_NAME and DB_DOMAIN initialization parameters.

The global database name of the root is the global database name of the CDB.

The global database name of a PDB is defined by the PDB name and the DB_DOMAIN initialization parameter.

"Determining the Global Database Name"

Familiarize yourself with the initialization parameters that can be included in an initialization parameter file. Become familiar with the concept and operation of a server parameter file (SPFILE). An SPFILE file lets you store and manage your initialization parameters persistently in a server-side disk file.

A CDB uses a single SPFILE or a single text initialization parameter file (PFILE). Values of initialization parameters set for the root can be inherited by PDBs. You can set some initialization parameters for a PDB by using the ALTER SYSTEM statement.

The root must be the current container when you operate on an SPFILE. The user who creates or modifies the SPFILE must be a common user with SYSDBA, SYSOPER, or SYSBACKUP administrative privilege, and the user must exercise the privilege by connecting AS SYSDBA, AS SYSOPER, or AS SYSBACKUP respectively.

To create a CDB, the ENABLE_PLUGGABLE_DATABASE initialization parameter must be set to TRUE.

"Specifying Initialization Parameters"

"Using the ALTER SYSTEM SET Statement in a CDB"

"Listing the Initialization Parameters That Are Modifiable in PDBs"

"About the Current Container"

Oracle Database Reference

Select the character set.

When the character set of the root is AL32UTF8, PDBs that are plugged into the CDB or cloned can have a different character set than the root. PDBs that are created from the CDB seed inherit the AL32UTF8 from it, but you can migrate the PDB to a different character set.

When the character set of the root is not AL32UTF8, all of the PDBs in the CDB use the character set of the root.

Oracle recommends AL32UTF8 for the CDB database character set and AL16UTF6 for the CDB national character set because they provide the most flexibility.

When selecting the database character set for the CDB, you must consider the current character sets of the databases that you want to consolidate (plug) into this CDB.

When moving a non-CDB to a CDB, it is best to migrate the non-CDB to AL32UTF8 first. You can use Oracle Database Migration Assistant for Unicode (DMU) to migrate a non-CDB to AL32UTF8. After a CDB is created, you cannot migrate the CDB's character set using DMU.

Oracle Database Globalization Support Guide

Consider which time zones your CDB must support.

You can set the time zones for the entire CDB (including all PDBs). You can also set the time zones individually for each PDB.

"Specifying the Database Time Zone and Time Zone File"

Select the standard database block size. This is specified at CDB creation by the DB_BLOCK_SIZE initialization parameter and cannot be changed after the CDB is created.

The standard block size applies to the entire CDB.

"Specifying Database Block Sizes"

If you plan to store online redo log files on disks with a 4K byte sector size, then determine whether you must manually specify redo log block size. Also, develop a backup and recovery strategy to protect the CDB from failure.

There is a single redo log and a single control file for an entire CDB.

"Planning the Block Size of Redo Log Files"

" Managing the Redo Log"

" Managing Archived Redo Log Files"

"Managing Control Files"

Oracle Database Backup and Recovery User's Guide

Determine the appropriate initial sizing for the SYSAUX tablespace.

There is a separate SYSAUX tablespace for the root and for each PDB.

"About the SYSAUX Tablespace"

Plan to use a default tablespace for non-SYSTEM users to prevent inadvertently saving database objects in the SYSTEM tablespace.

You can specify a separate default tablespace for the root and for each PDB. Also, there is a separate SYSTEM tablespace for the root and for each PDB.

"Creating a Default Permanent Tablespace"

"About the Statements That Modify a CDB"

Plan to use default temporary tablespaces.

There is a default temporary tablespace for each container in the CDB, including the root and each PDB, application root, and application PDB.

The shared temporary tablespace is used is for recursive SQL only and is not used by hosted PDB tenants directly.

"Creating a Default Temporary Tablespace"

"About the Statements That Modify a CDB"

Plan to use an undo tablespace to manage your undo data.

A CDB can run in different undo modes. You can configure a CDB to have one active undo tablespace for the entire CDB or a separate undo tablespace for each container in the CDB. You can specify the undo mode during CDB creation, and you can change the undo mode after the CDB is created.

When you choose to have one active undo tablespace for the entire CDB, shared undo is used, and local undo is disabled. In this configuration, there is one active undo tablespace for a single-instance CDB. When local undo is enabled, there is one undo tablespace for each container in a single instance configuration. For an Oracle RAC CDB, each PDB has one undo tablespace in each node in which it is open. With shared undo, only a common user who has the appropriate privileges and whose current container is the root can create an undo tablespace.

The best practice is to use local undo for a CDB. Shared undo is supported primarily for upgrade and transitional purposes only. Although there is minor overhead associated with local undo when compared with shared undo, the benefits of local undo make it preferable in most environments. Local undo makes unplug operations and point in time recovery faster, and it is required for some features, such as relocating a PDB. By default, DBCA creates new CDBs with local undo enabled.

In a CDB, the UNDO_MANAGEMENT initialization parameter must be set to AUTO, and an undo tablespace is required to manage the undo data.

When local undo is not enabled, undo tablespaces are visible in static data dictionary views and dynamic performance (V$) views when the current container is the root. Undo tablespaces are visible only in dynamic performance views when the current container is a PDB.

Also, when local undo is disabled, Oracle Database silently ignores undo tablespace and rollback segment operations when the current container is a PDB.

"Managing the CDB Undo Mode"

" Managing Undo "

"About the Current Container"

Plan for the database services required to meet the needs of your applications.

The root and each PDB might require several services. You can create services for the root or for individual PDBs.

Database services have an optional PDB property. You can create services and associate them with a particular PDB by specifying the PDB property. Services with a null PDB property are associated with the CDB root.

You can also use the DBMS_SERVICE supplied PL/SQL package to create services and associate them with PDBs. When you run CREATE_SERVICE procedure, the service is associated with the current container.

You can manage services with the SRVCTL utility, Oracle Enterprise Manager Cloud Control, and the DBMS_SERVICE supplied PL/SQL package.

When you create a PDB, a new default service for the PDB is created automatically. The service has the same name as the PDB. You cannot manage this service with the SRVCTL utility. However, you can create user-defined services and customize them for your applications.

"Managing Application Workloads with Database Services "

"Managing Services Associated with PDBs"

"SRVCTL Command Reference for Oracle Restart" for information about using the SRVCTL utility with a single-instance database

Oracle Real Application Clusters Administration and Deployment Guide for information about using the SRVCTL utility with an Oracle RAC database

Familiarize yourself with the principles and options of starting up and shutting down an instance and mounting and opening a CDB.

In a CDB, the CDB root and all of the containers share a single instance, or, when using Oracle RAC, multiple concurrent instances. You can start up and shut down an entire CDB, which in turn determines the state of hosted PDBs. When the CDB is open, you can control the open mode of PDBs by using either an ALTER PLUGGABLE DATABASE statement in the context of the CDB or PDB to open or close hosted PDBs. To maintain backward compatibility, ALTER DATABASE OPEN and ALTER DATABASE CLOSE statements are supported when they are executed and a PDB is the current container. You can also use the SQL*Plus STARTUP command and the SQL*Plus SHUTDOWN command when a PDB is the current container. However, the SQL*Plus STARTUP MOUNT command is a CDB-only operation and cannot be used when a PDB is the current container.

"Starting Up a Database"

"Modifying the Open Mode of PDBs"

"Modifying a PDB with the ALTER PLUGGABLE DATABASE Statement"

If you plan to use Oracle RAC, then plan for an Oracle RAC environment.

The Oracle RAC documentation describes special considerations for a CDB in an Oracle RAC environment.

See your platform-specific Oracle RAC installation guide for information about creating a CDB in an Oracle RAC environment.

Oracle Real Application Clusters Administration and Deployment Guide

Avoid unsupported features.

The Oracle Database Readme includes a list of Oracle Database features that are currently not supported in a CDB.

If you must use one or more of these features, then create a non-CDB.

Creating and Configuring an Oracle Database

37.2.2 Prerequisites for CDB Creation

You must complete prerequisites before creating a new CDB.

Before you can create a new CDB, the following prerequisites must be met:

  • Ensure that the prerequisites described in "Prerequisites for a Multitenant Environment" are met.

  • Sufficient memory must be available to start the Oracle Database instance.

    The memory required by a CDB should be sized to accommodate the workload of each of its containers and the number of containers.

  • Sufficient disk storage space must be available for the planned PDBs on the computer that runs Oracle Database. In an Oracle RAC environment, sufficient shared storage must be available.

    The disk storage space required by a CDB is the sum of the space requirements for all of the PDBs that will be part of the CDB.

All of these prerequisites are discussed in the Oracle Database Installation Guide or Oracle Grid Infrastructure Installation Guide specific to your operating system. If you use the Oracle Universal Installer, then it will guide you through your installation and provide help in setting environment variables and establishing directory structure and authorizations.

37.3 Using DBCA to Create a CDB

Oracle strongly recommends using the Database Configuration Assistant (DBCA) to create a CDB, because it is a more automated approach, and your CDB is ready to use when DBCA completes. DBCA enables you to specify the number of PDBs in the CDB when it is created.

DBCA can be launched by the Oracle Universal Installer (OUI), depending upon the type of install that you select. You can also launch DBCA as a standalone tool at any time after Oracle Database installation.

You can use DBCA to create a CDB in interactive mode or noninteractive/silent mode. Interactive mode provides a graphical interface and guided workflow for creating and configuring a CDB. Noninteractive/silent mode enables you to script a pre-configured CDB template deployment with pre-configured, customized PDB seed databases for cloning purposes. You can run DBCA in noninteractive/silent mode by specifying command-line arguments, a response file, or both.

After a CDB is created, you can use DBCA to plug PDBs into it and unplug PDBs from it.

See Also:

37.4 Using the CREATE DATABASE Statement to Create a CDB

You can create a CDB using the CREATE DATABASE SQL statement.

Note:

Oracle strongly recommends using the Database Configuration Assistant (DBCA) template deployment instead of the CREATE DATABASE SQL statement to create a CDB, because using DBCA is a more automated approach, and your CDB is ready to use when DBCA completes.

37.4.1 About Creating a CDB with the CREATE DATABASE Statement

Creating a CDB using the CREATE DATABASE SQL statement is very similar to creating a non-CDB. This section describes additional requirements for creating a CDB. When you create a CDB using the CREATE DATABASE SQL statement, you must enable PDBs and specify the names and locations of the root's files and the CDB seed's files.

Note:

Using the CREATE DATABASE SQL statement is a more manual approach to creating a CDB than using DBCA.

See Also:

Oracle Database Concepts for information about a CDB's files

37.4.1.1 About Enabling PDBs

To create a CDB, the CREATE DATABASE statement must include the ENABLE PLUGGABLE DATABASE clause. When this clause is included, the statement creates a CDB with the root and the CDB seed.

When the ENABLE PLUGGABLE DATABASE clause is not included in the CREATE DATABASE statement, the newly created database is a non-CDB. The statement does not create the root and the CDB seed, and the non-CDB can never contain PDBs.

37.4.1.2 About the Names and Locations of the Root's Files and the CDB Seed's Files

The CREATE DATABASE statement uses the root's files (such as data files) to generate the names of the CDB seed's files. You must specify the names and locations of the root's files and the CDB seed's files. After the CREATE DATABASE statement completes successfully, you can use the CDB seed and its files to create new PDBs. The CDB seed cannot be modified after it is created.

You must specify the names and locations of the CDB seed's files in one of the following ways:

  1. The SEED FILE_NAME_CONVERT clause

  2. Oracle Managed Files

  3. The PDB_FILE_NAME_CONVERT initialization parameter

If you use more than one of these methods, then the CREATE DATABASE statement uses one method in the order of precedence of the previous list. For example, if you use all of the methods, then the CREATE DATABASE statement only uses the specifications in the SEED FILE_NAME_CONVERT clause.

37.4.1.2.1 The SEED FILE_NAME_CONVERT Clause

The SEED FILE_NAME_CONVERT clause of the CREATE DATABASE statement specifies how to generate the names of the CDB seed's files using the names of root's files.

You can use this clause to specify one of the following options:

  • One or more file name patterns and replacement file name patterns, in the following form:

    'string1' , 'string2' , 'string3' , 'string4' , ...
    

    The string2 file name pattern replaces the string1 file name pattern, and the string4 file name pattern replaces the string3 file name pattern. You can use as many pairs of file name pattern and replacement file name pattern strings as required.

    If you specify an odd number of strings (the last string has no corresponding replacement string), then an error is returned. Do not specify more than one pattern/replace string that matches a single file name or directory.

    File name patterns cannot match files or directories managed by Oracle Managed Files.

  • NONE when no file names should be converted. Omitting the SEED FILE_NAME_CONVERT clause is the same as specifying NONE.

Example 37-1 SEED FILE_NAME_CONVERT Clause

This SEED FILE_NAME_CONVERT clause generates file names for the CDB seed's files in the /oracle/pdbseed/ directory using file names in the /oracle/dbs directory.

SEED
FILE_NAME_CONVERT = ('/oracle/dbs/', '/oracle/pdbseed/')

See Also:

Oracle Database SQL Language Reference for the syntax of the SEED FILE_NAME_CONVERT clause

37.4.1.2.2 Oracle Managed Files

When Oracle Managed Files is enabled, it can determine the names and locations of the CDB seed's files.

37.4.1.2.3 The PDB_FILE_NAME_CONVERT Initialization Parameter

The PDB_FILE_NAME_CONVERT initialization parameter can specify the names and locations of the seed's files.

To use this technique, ensure that the PDB_FILE_NAME_CONVERT initialization parameter is included in the initialization parameter file when you create the CDB.

File name patterns specified in this initialization parameter cannot match files or directories managed by Oracle Managed Files.

37.4.1.3 About the Attributes of the CDB Seed's Data Files

The CDB seed can be used as a template to create new containers.

The attributes of the data files for the root's SYSTEM and SYSAUX tablespaces might not be suitable for the CDB seed. In this case, you can specify different attributes for the CDB seed's data files by using the tablespace_datafile clauses. Use these clauses to specify attributes for all data files comprising the SYSTEM and SYSAUX tablespaces in the CDB seed. The values inherited from the root are used for any attributes whose values have not been provided.

The syntax of the tablespace_datafile clauses is the same as the syntax for a data file specification, excluding the name and location of the data file and the REUSE attribute. You can use the tablespace_datafile clauses with any of the methods for specifying the names and locations of the CDB seed's data files described in "About the Names and Locations of the Root's Files and the CDB Seed's Files".

The tablespace_datafile clauses do not specify the names and locations of the CDB seed's data files. Instead, they specifies attributes of SYSTEM and SYSAUX data files in the CDB seed that differ from those in the root. If SIZE is not specified in the tablespace_datafile clause for a tablespace, then data file size for the tablespace is set to a predetermined fraction of the size of a corresponding root data file.

Example 37-2 Using the tablespace_datafile Clauses

Assume the following CREATE DATABASE clauses specify the names, locations, and attributes of the data files that comprise the SYSTEM and SYSAUX tablespaces in the root.

DATAFILE '/u01/app/oracle/oradata/newcdb/system01.dbf' SIZE 325M REUSE
SYSAUX DATAFILE '/u01/app/oracle/oradata/newcdb/sysaux01.dbf' SIZE 325M REUSE

You can use the following tablespace_datafile clauses to specify different attributes for these data files:

SEED
SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
SYSAUX DATAFILES SIZE 100M

In this example, the data files for the CDB seed's SYSTEM and SYSAUX tablespaces inherit the REUSE attribute from the root's data files. However, the following attributes of the CDB seed's data files differ from the root's:

  • The data file for the SYSTEM tablespace is 125 MB for the CDB seed and 325 MB for the root.

  • AUTOEXTEND is enabled for the CDB seed's SYSTEM data file, and it is disabled by default for the root's SYSTEM data file.

  • The data file for the SYSAUX tablespace is 100 MB for the CDB seed and 325 MB for the root.

See Also:

Oracle Database SQL Language Reference for information about data file specifications

37.4.1.4 About the CDB’s Undo Mode

Add the undo_mode_clause to an ENABLE PLUGGABLE DATABASE clause to specify the undo mode of the CDB.

The undo_mode_clause specifies whether the CDB undo mode is local or shared. Local undo mode means that every container in the CDB uses local undo. To configure local undo mode for the CDB, specify LOCAL UNDO ON. 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. To configure shared undo mode for the CDB, specify LOCAL UNDO OFF. If the undo_mode_clause is not added to the ENABLE PLUGGABLE DATABASE clause, then shared undo mode is the default.

37.4.2 Creating a CDB with the CREATE DATABASE Statement

When you use the CREATE DATABASE statement to create a CDB, you must complete additional actions before you have an operational CDB.

These actions include building views on the data dictionary tables and installing standard PL/SQL packages in the root. You perform these actions by running the supplied catcdb.sql script.

The instructions in this section apply to single-instance installations only. See the Oracle Real Application Clusters (Oracle RAC) installation guide for your platform for instructions for creating an Oracle RAC CDB.

Note:

Single-instance does not mean that only one Oracle instance can reside on a single host computer. In fact, multiple Oracle instances (and their associated databases) can run on a single host computer. A single-instance database is a database that is accessed by only one Oracle instance at a time, as opposed to an Oracle RAC database, which is accessed concurrently by multiple Oracle instances on multiple nodes. See Oracle Real Application Clusters Administration and Deployment Guide for more information on Oracle RAC.

Tip:

If you are using Oracle ASM to manage your disk storage, then you must start the Oracle ASM instance and configure your disk groups before performing these steps. See Oracle Automatic Storage Management Administrator's Guide.

The examples in the following steps create a CDB named newcdb.

To create a CDB with the CREATE DATABASE statement:

  1. Complete steps 1 - 8 in "Creating a Database with the CREATE DATABASE Statement".

    To create a CDB, the ENABLE_PLUGGABLE_DATABASE initialization parameter must be set to TRUE.

    In a CDB, the DB_NAME initialization parameter specifies the name of the root. Also, it is common practice to set the SID to the name of the root. The maximum number of characters for this name is 30. For more information, see the discussion of the DB_NAME initialization parameter in Oracle Database Reference.

  2. Use the CREATE DATABASE statement to create a new CDB.

    The following examples illustrate using the CREATE DATABASE statement to create a new CDB:

    Example 1: Creating a CDB Without Using Oracle Managed Files

    The following statement creates a CDB named newcdb. This name must agree with the DB_NAME parameter in the initialization parameter file. This example assumes the following:

    • The initialization parameter file specifies the number and location of control files with the CONTROL_FILES parameter.

    • The directory /u01/app/oracle/oradata/newcdb exists.

    • The directory /u01/app/oracle/oradata/pdbseed exists.

    • The directories /u01/logs/my and /u02/logs/my exist.

    This example includes the ENABLE PLUGGABLE DATABASE clause to create a CDB with the root and the CDB seed. This example also includes the SEED FILE_NAME_CONVERT clause to specify the names and locations of the CDB seed's files. This example also includes tablespace_datafile clauses that specify attributes of the CDB seed's data files for the SYSTEM and SYSAUX tablespaces that differ from the root's. This example includes the undo_mode_clause to specify that the CDB undo mode is local.

    CREATE DATABASE newcdb
      USER SYS IDENTIFIED BY sys_password
      USER SYSTEM IDENTIFIED BY system_password
      LOGFILE GROUP 1 ('/u01/logs/my/redo01a.log','/u02/logs/my/redo01b.log') 
                 SIZE 100M BLOCKSIZE 512,
              GROUP 2 ('/u01/logs/my/redo02a.log','/u02/logs/my/redo02b.log') 
                 SIZE 100M BLOCKSIZE 512,
              GROUP 3 ('/u01/logs/my/redo03a.log','/u02/logs/my/redo03b.log') 
                 SIZE 100M BLOCKSIZE 512
      MAXLOGHISTORY 1
      MAXLOGFILES 16
      MAXLOGMEMBERS 3
      MAXDATAFILES 1024
      CHARACTER SET AL32UTF8
      NATIONAL CHARACTER SET AL16UTF16
      EXTENT MANAGEMENT LOCAL
      DATAFILE '/u01/app/oracle/oradata/newcdb/system01.dbf'
        SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
      SYSAUX DATAFILE '/u01/app/oracle/oradata/newcdb/sysaux01.dbf'
        SIZE 550M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
      DEFAULT TABLESPACE deftbs
         DATAFILE '/u01/app/oracle/oradata/newcdb/deftbs01.dbf'
         SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
      DEFAULT TEMPORARY TABLESPACE tempts1
         TEMPFILE '/u01/app/oracle/oradata/newcdb/temp01.dbf'
         SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED
      UNDO TABLESPACE undotbs1
         DATAFILE '/u01/app/oracle/oradata/newcdb/undotbs01.dbf'
         SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
      ENABLE PLUGGABLE DATABASE
        SEED
        FILE_NAME_CONVERT = ('/u01/app/oracle/oradata/newcdb/', 
                             '/u01/app/oracle/oradata/pdbseed/')
        SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
        SYSAUX DATAFILES SIZE 100M
      USER_DATA TABLESPACE usertbs
        DATAFILE '/u01/app/oracle/oradata/pdbseed/usertbs01.dbf'
        SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
      LOCAL UNDO ON;
    

    A CDB is created with the following characteristics:

    • The CDB is named newcdb. Its global database name is newcdb.us.example.com, where the domain portion (us.example.com) is taken from the initialization parameter file. See "Determining the Global Database Name".

    • Three control files are created as specified by the CONTROL_FILES initialization parameter, which was set before CDB creation in the initialization parameter file. See "Sample Initialization Parameter File" and "Specifying Control Files ".

    • The passwords for user accounts SYS and SYSTEM are set to the values that you specified. The passwords are case-sensitive. The two clauses that specify the passwords for SYS and SYSTEM are not mandatory in this release of Oracle Database. However, if you specify either clause, then you must specify both clauses. For further information about the use of these clauses, see "Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM".

    • The new CDB has three online redo log file groups, each with two members, as specified in the LOGFILE clause. MAXLOGFILES, MAXLOGMEMBERS, and MAXLOGHISTORY define limits for the redo log. See "Choosing the Number of Redo Log Files". The block size for the redo logs is set to 512 bytes, the same size as physical sectors on disk. The BLOCKSIZE clause is optional if block size is to be the same as physical sector size (the default). Typical sector size and thus typical block size is 512. Permissible values for BLOCKSIZE are 512, 1024, and 4096. For newer disks with a 4K sector size, optionally specify BLOCKSIZE as 4096. See "Planning the Block Size of Redo Log Files" for more information.

    • MAXDATAFILES specifies the maximum number of data files that can be open in the CDB. This number affects the initial sizing of the control file. For a CDB, set MAXDATAFILES to a high number that anticipates the aggregate number of data files for all containers, in addition to the CDB root files.

      Note:

      You can set several limits during CDB creation. Some of these limits are limited by and affected by operating system limits. For example, if you set MAXDATAFILES, then Oracle Database allocates enough space in the control file to store MAXDATAFILES filenames, even if the CDB has only one data file initially. However, because the maximum control file size is limited and operating system dependent, you might not be able to set all CREATE DATABASE parameters at their theoretical maximums.

      For more information about setting limits during CDB creation, see the Oracle Database SQL Language Reference and your operating system–specific Oracle documentation.

    • The AL32UTF8 character set is used to store data in this CDB.

    • The AL16UTF16 character set is specified as the NATIONAL CHARACTER SET used to store data in columns specifically defined as NCHAR, NCLOB, or NVARCHAR2.

    • The SYSTEM tablespace, consisting of the operating system file /u01/app/oracle/oradata/newcdb/system01.dbf, is created as specified by the DATAFILE clause. If a file with that name already exists, then it is overwritten.

    • The SYSTEM tablespace is created as a locally managed tablespace. See "Creating a Locally Managed SYSTEM Tablespace".

    • A SYSAUX tablespace is created, consisting of the operating system file /u01/app/oracle/oradata/newcdb/sysaux01.dbf as specified in the SYSAUX DATAFILE clause. See "About the SYSAUX Tablespace".

    • The DEFAULT TABLESPACE clause creates and names a default permanent tablespace for this CDB.

    • The DEFAULT TEMPORARY TABLESPACE clause creates and names a default temporary tablespace for the root of this CDB. See "Creating a Default Temporary Tablespace".

    • The UNDO TABLESPACE clause creates and names an undo tablespace that is used to store undo data for this CDB. In a CDB, an undo tablespace is required to manage the undo data, and the UNDO_MANAGEMENT initialization parameter must be set to AUTO. If you omit this parameter, then it defaults to AUTO. See "Using Automatic Undo Management: Creating an Undo Tablespace".

    • Redo log files will not initially be archived, because the ARCHIVELOG clause is not specified in this CREATE DATABASE statement. This is customary during CDB creation. You can later use an ALTER DATABASE statement to switch to ARCHIVELOG mode. The initialization parameters in the initialization parameter file for newcdb relating to archiving are LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_FORMAT. See Managing Archived Redo Log Files.

    • The ENABLE PLUGGABLE DATABASE clause creates a CDB with the root and the CDB seed.

    • SEED is required for the FILE_NAME_CONVERT clause and the tablespace_datafile clauses.

    • The FILE_NAME_CONVERT clause generates file names for the CDB seed's files in the /u01/app/oracle/oradata/pdbseed directory using file names in the /u01/app/oracle/oradata/newcdb directory.

    • The SYSTEM DATAFILES clause specifies attributes of the CDB seed's SYSTEM tablespace data file(s) that differ from the root's.

    • The SYSAUX DATAFILES clause specifies attributes of the CDB seed's SYSAUX tablespace data file(s) that differ from the root's.

    • The USER_DATA TABLESPACE clause creates and names the CDB seed's tablespace for storing user data and database options such as Oracle XML DB. PDBs created using the CDB seed include this tablespace and its data file. The tablespace and data file specified in this clause are not used by the root.

    • The LOCAL UNDO ON clause sets the CDB’s undo mode to local, which means that each container in the CDB uses local undo.

      When the CDB is created in local undo mode, the CDB seed includes an undo tablespace so that any new PDB created from the CDB seed has an undo tablespace. When a PDB is created by plugging it in or cloning a remote PDB, and the source PDB was in shared undo mode, an undo tablespace is created for the PDB automatically the first time the PDB is opened.

    Note:

    • Ensure that all directories used in the CREATE DATABASE statement exist. The CREATE DATABASE statement does not create directories.

    • If you are not using Oracle Managed Files, then every tablespace clause must include a DATAFILE or TEMPFILE clause.

    • If CDB creation fails, then you can look at the alert log to determine the reason for the failure and to determine corrective actions. See "Viewing the Alert Log". If you receive an error message that contains a process number, then examine the trace file for that process. Look for the trace file that contains the process number in the trace file name. See "Finding Trace Files" for more information.

    • To resubmit the CREATE DATABASE statement after a failure, you must first shut down the instance and delete any files created by the previous CREATE DATABASE statement.

    Example 2: Creating a CDB Using Oracle Managed Files

    This example illustrates creating a CDB with Oracle Managed Files, which enables you to use a much simpler CREATE DATABASE statement. To use Oracle Managed Files, the initialization parameter DB_CREATE_FILE_DEST must be set. This parameter defines the base directory for the various CDB files that the CDB creates and automatically names.

    The following statement is an example of setting this parameter in the initialization parameter file:

    DB_CREATE_FILE_DEST='/u01/app/oracle/oradata'
    

    This example sets the parameter Oracle ASM storage:

    DB_CREATE_FILE_DEST = +data
    

    This example includes the ENABLE PLUGGABLE DATABASE clause to create a CDB with the root and the CDB seed. This example does not include the SEED FILE_NAME_CONVERT clause because Oracle Managed Files determines the names and locations of the CDB seed's files. However, this example does include tablespace_datafile clauses that specify attributes of the CDB seed's data files for the SYSTEM and SYSAUX tablespaces that differ from the root's.

    With Oracle Managed Files and the following CREATE DATABASE statement, the CDB creates the SYSTEM and SYSAUX tablespaces, creates the additional tablespaces specified in the statement, and chooses default sizes and properties for all data files, control files, and redo log files. Note that these properties and the other default CDB properties set by this method might not be suitable for your production environment, so it is recommended that you examine the resulting configuration and modify it if necessary.

    CREATE DATABASE newcdb
    USER SYS IDENTIFIED BY sys_password
    USER SYSTEM IDENTIFIED BY system_password
    EXTENT MANAGEMENT LOCAL
    DEFAULT TABLESPACE users
    DEFAULT TEMPORARY TABLESPACE temp
    UNDO TABLESPACE undotbs1
    ENABLE PLUGGABLE DATABASE
       SEED
       SYSTEM DATAFILES SIZE 125M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
       SYSAUX DATAFILES SIZE 100M;
    

    A CDB is created with the following characteristics:

    • The CDB is named newcdb. Its global database name is newcdb.us.example.com, where the domain portion (us.example.com) is taken from the initialization parameter file. See "Determining the Global Database Name".

    • The passwords for user accounts SYS and SYSTEM are set to the values that you specified. The passwords are case-sensitive. The two clauses that specify the passwords for SYS and SYSTEM are not mandatory in this release of Oracle Database. However, if you specify either clause, then you must specify both clauses. For further information about the use of these clauses, see "Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM".

    • The DEFAULT TABLESPACE clause creates and names a default permanent tablespace for this CDB.

    • The DEFAULT TEMPORARY TABLESPACE clause creates and names a default temporary tablespace for the root of this CDB. See "Creating a Default Temporary Tablespace".

    • The UNDO TABLESPACE clause creates and names an undo tablespace that is used to store undo data for this CDB. In a CDB, an undo tablespace is required to manage the undo data, and the UNDO_MANAGEMENT initialization parameter must be set to AUTO. If you omit this parameter, then it defaults to AUTO. See "Using Automatic Undo Management: Creating an Undo Tablespace".

    • Redo log files will not initially be archived, because the ARCHIVELOG clause is not specified in this CREATE DATABASE statement. This is customary during CDB creation. You can later use an ALTER DATABASE statement to switch to ARCHIVELOG mode. The initialization parameters in the initialization parameter file for newcdb relating to archiving are LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_FORMAT. See Managing Archived Redo Log Files.

    • The ENABLE PLUGGABLE DATABASE clause creates a CDB with the root and the CDB seed.

    • SEED is required for the tablespace_datafile clauses.

    • The SYSTEM DATAFILES clause specifies attributes of the CDB seed's SYSTEM tablespace data file(s) that differ from the root's.

    • The SYSAUX DATAFILES clause specifies attributes of the CDB seed's SYSAUX tablespace data file(s) that differ from the root's.

    Tip:

    If your CREATE DATABASE statement fails, and if you did not complete Step 7 in "Creating a Database with the CREATE DATABASE Statement", then ensure that there is not a pre-existing server parameter file (SPFILE) for this instance that is setting initialization parameters in an unexpected way. For example, an SPFILE contains a setting for the complete path to all control files, and the CREATE DATABASE statement fails if those control files do not exist. Ensure that you shut down and restart the instance (with STARTUP NOMOUNT) after removing an unwanted SPFILE. See "Managing Initialization Parameters Using a Server Parameter File" for more information.

  3. Run the catcdb.sql SQL script. This script installs all of the components required by a CDB.

    Enter the following in SQL*Plus to run the script:

    @?/rdbms/admin/catcdb.sql
    
  4. Complete steps 12 - 14 in "Creating a Database with the CREATE DATABASE Statement".

37.5 Configuring EM Express for a CDB

For a CDB, you can configure Oracle Enterprise Manager Database Express (EM Express) for the root and for each PDB by setting a global HTTPS port, or you can set a different port for every container in the CDB.

To configure EM Express for a CDB:

You can set a global port, which enables you to use EM Express to connect to all of the PDBs in the CDB using the HTTP or HTTPS port for the CDB. Alternatively, you can set a different HTTP or HTTPS port for every container in a CDB.

  1. In SQL*Plus, access a container in a CDB.

    The user must have common SYSDBA administrative privilege, and you must exercise this privilege using AS SYSDBA at connect time. The container can be the root or a PDB.

    See "Accessing a Container in a CDB with SQL*Plus".

  2. Set the port in one of the following ways:

    • To set the global port, connect to the CDB$ROOT, and issue the following SQL statement to configure the global port for the CDB:

      exec DBMS_XDB_CONFIG.SETGLOBALPORTENABLED(TRUE);
      
    • To set the HTTP port for the current container, run the following procedure:

      exec DBMS_XDB_CONFIG.SETHTTPPORT(http_port_number);
      

      Replace http_port_number with the appropriate HTTP port number.

    • To set the HTTPS port for the current container , run the following procedure:

      exec DBMS_XDB_CONFIG.SETHTTPSPORT(https_port_number);
      

      Replace https_port_number with the appropriate HTTPS port number.

After the port is set, you can access EM Express in one of the following ways:

  • To use the global port, enter the EM Express URL provided by Database Configuration Assistant (DBCA) when it configured the CDB that includes the PDB. When the EM Express login screen appears, specify your administrator credentials, and enter the name of the PDB that you want to connect to in the Container Name field.

  • The URL for the HTTP port for a container:

    http://database_hostname:http_port_number/em/
    

    Replace database_hostname with the host name of the computer on which the database instance is running, and replace http_port_number with the appropriate HTTP port number.

  • The URL for the HTTPS port for a container:

    https://database_hostname:https_port_number/em/
    

    Replace database_hostname with the host name of the computer on which the database instance is running, and replace https_port_number with the appropriate HTTPS port number.

When connected to the root, EM Express displays data and enables actions that apply to the entire CDB. When connected to a PDB, EM Express displays data and enables actions that apply to the PDB only.

Note:

If the listener is not configured on port 1521, then you must manually configure the port for EM Express. See Oracle Database 2 Day DBA for instructions.

See Also:

Oracle Database 2 Day DBA for more information about EM Express

37.6 After Creating a CDB

After you create a CDB, it consists of the root and the CDB seed.

The root contains system-supplied metadata and common users that can administer the PDBs. The CDB seed is a template that you can use to create new PDBs. Figure 37-1 shows a newly created CDB.

Figure 37-1 A Newly Created CDB

Description of Figure 37-1 follows
Description of "Figure 37-1 A Newly Created CDB"

In a CDB, the root contains minimal user data or no user data. User data resides in the PDBs. Therefore, after creating a CDB, one of the first tasks is to add the PDBs that will contain the user data. See "Creating and Removing PDBs with SQL*Plus" for instructions.

Figure 37-2 shows a CDB with PDBs.

You have the option of creating one or more application containers. An application container consists of an application root and application PDBs, and it stores data for one or more applications. An application container can store application common objects, which contain user data that can be shared by the application PDBs in the application container. It can also contain an application seed for fast creation of application PDBs in an application container.

Figure 37-3 Application Containers in a CDB

Description of Figure 37-3 follows
Description of "Figure 37-3 Application Containers in a CDB"

When you have added the PDBs and application containers to the CDB, the physical structure of a CDB is very similar to the physical structure of a non-CDB. A CDB contains the following files:

  • One control file

  • One active online redo log for a single-instance CDB, or one active online redo log for each instance of an Oracle RAC CDB

  • Sets of temp files

    There is one default temporary tablespace for the root of the CDB and one for each PDB, application root, and application PDB.

  • Sets of system data files

    The primary physical difference between a CDB and a non-CDB is in the data files. A non-CDB has only one set of system data files. In contrast, a CDB includes one set of system data files for each container in the CDB, including a set of system data files for each PDB, application root, and application PDB. In addition, a CDB has one set of user-created data files for each container. If the CDB is in local undo mode, then each container also has its own undo tablespace and associated data files.

  • Sets of user-created data files

    Each PDB has its own set of non-system data files. These data files contain the user-defined schemas and database objects for the PDB.

See Oracle Database Concepts for more information about the physical architecture of a CDB.

For backup and recovery of a CDB, Recovery Manager (RMAN) is recommended. PDB point-in-time recovery (PDB PITR) must be performed with RMAN. By default, RMAN turns on control file autobackup for a CDB. It is strongly recommended that control file autobackup is enabled for a CDB, to ensure that PDB PITR can undo data file additions or deletions.

Because the physical structure of a CDB and a non-CDB are similar, most management tasks are the same for a CDB and a non-CDB. However, some administrative tasks are specific to CDBs. The following chapters describe these tasks:

  • "Creating and Removing PDBs with SQL*Plus"

    This chapter documents the following tasks:

    • Creating a PDB using the CDB seed with SQL*Plus

    • Creating a PDB by cloning an existing PDB or Non-CDB with SQL*Plus

    • Creating a PDB by relocating it with SQL*Plus

    • Creating a PDB as a proxy PDB with SQL*Plus

    • Plugging in a PDB with SQL*Plus

    • Unplugging a PDB with SQL*Plus

    • Dropping a PDB with SQL*Plus

  • "Creating and Removing PDBs with Cloud Control "

    This chapter documents the following tasks:

    • Creating a PDB with Cloud Control

    • Plugging in a PDB with Cloud Control

    • Unplugging a PDB with Cloud Control

  • "Creating and Removing Application Containers and Seeds with SQL*Plus"

    This chapter documents the following tasks:

    • Creating application containers with SQL*Plus

    • Creating application seeds with SQL*Plus

    • Unplugging application containers with SQL*Plus

    • Unplugging application seeds with SQL*Plus

    • Dropping application containers with SQL*Plus

    • Dropping application seeds with SQL*Plus

  • " Administering a CDB with SQL*Plus"

    This chapter documents the following tasks:

    • Connecting to a container

    • Switching into a container

    • Modifying a CDB

    • Modifying the root

    • Changing the open mode of a PDB

    • Executing DDL statements in a CDB

    • Shutting down the CDB instance

  • " Administering CDBs and PDBs with Cloud Control"

    This chapter documents the following tasks:

    • Managing CDB storage and schema objects

    • Managing per-container storage and schema objects

    • Monitoring storage and schema alerts

    • Switching into a container

    • Changing the open mode of a PDB

  • " Administering PDBs with SQL*Plus"

    This chapter documents the following tasks:

    • Connecting to a PDB

    • Modifying a PDB

    • Managing services associated with PDBs

  • "Administering Application Containers with SQL*Plus"

    This chapter documents the following tasks:

    • Managing applications in an application container, including installing, upgrading, and patching applications

    • Managing application common objects

    • Issuing DML statements on containers in an application container

    • Partitioning by PDB with container maps

  • " Viewing Information About CDBs and PDBs with SQL*Plus"

    This chapter documents the following tasks:

    • Querying views for monitoring a CDB and its PDBs

    • Running sample queries that provide information about a CDB and its PDBs

  • " Using Oracle Resource Manager for PDBs with SQL*Plus"

    This chapter documents the following tasks:

    • Creating resource plans in a CDB with SQL*Plus

    • Managing resource plans in a CDB with SQL*Plus

  • " Using Oracle Resource Manager for PDBs with Cloud Control"

    This chapter documents the following tasks:

    • Creating resource plans in a CDB with Cloud Control

    • Monitoring the system performance under a CDB resource plan with Cloud Control

    • Creating a PDB resource plan

  • " Using Oracle Scheduler with a CDB"

    This chapter documents the following topics:

    • DBMS_SCHEDULER invocations in a CDB

    • Job coordinator and slave processes in a CDB

    • Using DBMS_JOB

    • Processes to close a PDB

    • New and changed views

See Also: