NEW IN ORACLE12C AND ORACLE18C
Oracle12c R2 Multitenant Container Database Architecture
Oracle12c R2 Database Architecture
The
following are changes in the Oracle Multitenant option documentation
for Oracle Database 12c Release 2 (12.2.0.1).
The
following features are new in this Oracle12c second release:
- Application
containers
An
application container is an optional component of a multitenant container
database (CDB) that consists of an application root and the application PDBs
associated with it. An application container stores data for one or more
applications.
- Application
common objects
Besides,
application common objects are created in an application root and are shared
with the application PDBs that belong to the application root.
- Support
for thousands of pluggable databases (PDBs) in a single CDB
A CDB
can contain up to 4,096 PDBs; oh, what a great improvement!
- Use
different character sets for PDBs
When the
character set of the CDB root is AL32UTF8, any container in the CDB can use a
character set that is different from the CDB root and different from other
containers in the CDB, which is great for multiple deployment of website
content for localization and globalization purposes as appropriate.
- Relocate
a PDB from one CDB to another
A PDB
can be easily relocated in one operation with minimal down time.
- Proxy
PDB
Indeed,
a proxy PDB references a PDB in a different CDB and provides fully functional
access to the referenced PDB, which represents a fundamental improvement.
- Hot
PDB cloning
Now, the
source PDB can be in open read/write mode during a PDB clone operation.
- Rename
services during PDB creation
Similarly,
the SERVICE_NAME_CONVERT clause
of the CREATE PLUGGABLE DATABASE statement
renames the user-defined services of the new PDB based on the service names of
the source PDB.
- Switch
to a specific service for a container in a CDB
The DBA
can specify a service name in an ALTER SESSION SET CONTAINER statement.
- Manage
the memory usage of PDBs in a CDB
The DBA
can configure guarantees and limits for SGA and PGA memory, using PDB
initialization parameters.
- Limit
the I/O generated by specific PDBs
Conveniently,
two new initialization parameters, MAX_IOPS and MAX_MBPS,
enable the administrator to limit disk I/O generated by a PDB. MAX_IOPS limits the number of I/O operations, and MAX_MBPS limits the megabytes for I/O operations.
- PDB
performance profiles
The DBA
can specify Resource Manager directives for a set of PDBs using PDB performance
profiles.
- Monitor
PDBs managed by Oracle Database Resource Manager
A set of
dynamic performance views enables an administrator to monitor the results of
his Oracle Database Resource Manager settings for PDBs.
- Prioritize
PDB upgrades
The DBA
can prioritize the PDBs in a CDB when he upgrades the CDB. The PDBs with higher
priority are upgraded before PDBs with lower priority.
- CDB
undo mode
A 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. For an Oracle RAC CDB,
there is one active undo tablespace for each instance.
- Parallelized
PDB creation
The PARALLEL clause of the CREATE PLUGGABLE DATABASE statement specifies whether to use parallel execution
servers during PDB creation and, optionally, the degree of parallelism.
- Unplugging
PDBs and plugging in PDBs with an archive file
A PDB can
be unplugged into compressed archive of the XML file that describes the PDB and
the files used by the PDB (such as the data files and wallet file). The
archive file has a .pdb extension, and it can be used to plug the PDB into a
CDB or application container.
- PDB
refresh
The DBA
can create a PDB as a refreshable clone and refresh the PDB with changes made
to the source PDB.
- Improved
support for default tablespace specification during PDB creation
The DBA
can specify a default tablespace for a PDB that is created using techniques
such as cloning and plugging in the PDB. Previously, a default tablespace could
be specified only if the PDB was created from PDB$SEED.
- Extended USER_TABLESPACES clause during PDB creation
The
creation mode of user tablespaces can be different than the creation mode of
the PDB. For example, during PDB creation, the user tablespaces can move a
tablespace’s files even when file copy is specified for the PDB.
The
following are changes in the Oracle Multitenant option for Oracle Database 12c Release 1 (12.1.0.2).
The
following features are new in this release:
- Preserving
the open mode of PDBs when the CDB restarts
Off
course, the administrator can preserve the open mode of one or more PDBs when
the CDB restarts by using the ALTER PLUGGABLE DATABASE SQL statement with a pdb_save_or_discard_state clause.
- The USER_TABLESPACES clause of the CREATE PLUGGABLE DATABASE statement
An
administrator can use this clause to separate the data for multiple schemas
into different PDBs. For example, assume that each schema in a non-CDB uses a
separate tablespace. When the DBA moves a non-CDB to a PDB, and when the
non-CDB has schemas that supported different applications, he can use this
clause to separate the data belonging to each schema into a separate PDB,
- Excluding
data when cloning a PDB
The NO DATA clause of the CREATE PLUGGABLE DATABASE statement specifies that a PDB's data model definition is
cloned but not the PDB's data.
- Default
Oracle Managed Files file system directory or Oracle ASM disk group for a
PDB's files
The CREATE_FILE_DEST clause specifies the default location.
- Create
a PDB by cloning a non-CDB
The DBA
can create a PDB by cloning a non-CDB with a CREATE
PLUGGABLE DATABASE statement that
includes the FROM clause.
- The logging_clause of
the CREATE
PLUGGABLE DATABASE and ALTER PLUGGABLE
DATABASE statement
This
clause specifies the logging attribute of the PDB. The logging attribute
controls whether certain DML operations are logged in the redo log file (LOGGING) or not (NOLOGGING).
- The pdb_force_logging_clause of
the ALTER
PLUGGABLE DATABASE statement
This
clause places a PDB into force logging or force nologging mode or takes a PDB
out of force logging or force nologging mode.
- The STANDBYS clause of the CREATE PLUGGABLE DATABASE statement
This
clause specifies whether the new PDB is included in standby CDBs.
- Querying
user-created tables and views across all PDBs
The CONTAINERS clause enables administrators to query user-created tables
and views across all PDBs in a CDB.
Oracle18c Release 1 Database SGA (basic view)
The
following are changes to be highlited in Oracle 18c Multitenant, release
18.1.0.1.
The
newly established CDB fleet [concept] is a collection of
different CDBs that can be managed as one logical CDB.
- PDB
snapshot carousel
A PDB
snapshot is a point-in-time copy of a PDB. Thus, when a PDB is
enabled for snapshots, the administrator can create multiple snapshots
(point-in-time copies) of the PDB. The library of snapshots is called
a PDB snapshot carousel. The DBA can quickly clone a new PDB based on any
snapshot in the carousel. In this way, the DBA can perform point-in-time
recovery to any snapshot in the carousel, or rapidly create a PDB by cloning
any snapshot.
- Logical
partitioning
A
container map enables a session to issue SQL statements that are routed to the
appropriate PDB, depending on the value of a predicate used in the SQL
statement. Indeed, the partitioning column in the map table does not need to
match a column in the metadata-linked table. For example, if the table sales is enabled for the container map pdb_map_tbl, and if sales does
not have the column used to partition pdb_map_tbl, then queries with the predicate CONTAINERS(sales) are still routed to the PDBs specified in the map table.
- Refreshable
PDB switchover
A refreshable
clone PDB is a read-only clone that can periodically synchronize
with its source PDB. The DBA can reverse the roles, transforming the
source PDB into the clone and the clone into the source. This technique can be
useful for load balancing. Also, if the source PDB fails, then administrators
can resume operations on the clone PDB, rendering a CDB-level Oracle Data Guard
failover unnecessary.
- Lockdown
profile enhancements
The DBA
can create, alter, or drop lockdown profiles in application containers. Also, administrators
can create lockdown profiles based on a static or a dynamic base profile.
- DBCA
enhancements
The DBA
can use DBCA to clone a local PDB or duplicate a CDB. Duplication is only
supported in silent mode.
- Usable
backups of non-CDBs and relocated PDBs
When administrators
are cloning a non-CDB as a PDB or relocating a PDB, the DBA can use the DBMS_PDB.EXPORTRMANBACKUP procedure to export RMAN backup metadata into the PDB
dictionary. This metadata enables backups of the source non-CDB or PDB to be
usable for restore and recovery of the target PDB.
- RMAN
duplication of a PDB to another CDB
The DBA
can clone a PDB from a source CDB to an existing CDB that is open read/write.
- Relocation
of sessions during planned maintenance
Application
Continuity can drain database sessions during planned maintenance when the
application submits a connection test, at request boundaries, and at good
places to fail over. The relocation is transparent to applications. This
feature is on by default for all maintenance operations invoked at the database
service and PDB levels: stop service, relocate service, relocate PDB, and stop
PDB..
- Copying
a PDB in an Oracle Data Guard environment
Suitably,
when performing a remote clone in a primary database, or plugging in a PDB in a
primary database, administrators can set initialization parameters in a standby
database that automates copying the data files for the newly created PDB.
- Parallel
statement queuing at the PDB level
A DBA
can configure parallel statement queuing for a PDB just as for a non-PDB using
the PARALLEL_SERVERS_TARGET initialization
parameter. At the PDB level, the default is based on the CPU_COUNT setting for the PDB. In contrast, at the CDB level, the
default value is the value of the PARALLEL_MAX_SERVERS initialization parameter.
- Split
mirror clone PDBs
When a
PDB resides in Oracle ASM, administrators can use a split mirroring technique
to clone a PDB. The cloned PDB is independent of the original PDB. The
principal use case is to rapidly provision test and development PDBs in an
Oracle ASM environment.