The Evolution of Database Consolidation & How

Multitenant Solves It
Here is a summary of Globomantics' consolidation journey and the 12c
solution:

How
How Oracle
Consolidati Globoman Key Challenges (Mark's
Multitenant Solves
on Method tics Used Experience)
This
It

Solves: Drastically
reduces hardware
1.
Used for and software (OS)
Dedicated High cost, underutilized
large, footprint by
Server hardware, complex
critical hosting dozens of
(One per infrastructure.
systems. PDBs on a single
DB)
server and single
Oracle instance.

2. Used on "Waste": Each instance Solves: One SGA,

Instance larger has fixed memory one set of
Consolida servers 10 overhead (SGA, background
tion years ago. PGA). Management: M processes. A CDB
(Multiple anaging many instances has only one
DBs on on one OS is complex. instance,
one eliminating the
server) per-database
memory overhead.
You manage one
database instance,
 How
How Oracle
Consolidati Globoman Key Challenges (Mark's
Multitenant Solves
on Method tics Used Experience)
This
It

not twenty.

Name
Solves: This is
Collisions: Schema and
3. the primary
object
Schema value
names. Security: Super
Consolida Evaluated proposition. Multi
-users affect all
tion but tenant is designed
apps. Maintenance: D
(Many rejected. to overcome every
owntime and recovery
apps in single one of these
affect all
one DB) show-stopping
apps. Cloning: Comple
issues.
x with Data Pump.

How Multitenant Directly Addresses Mark's Specific

Concerns
Let's go through Mark's schema-consolidation problems one by one.

1. Problem: Name Collisions

 Issue: Two HR schemas, public synonyms, roles, or tablespaces with the

same name cannot coexist.

 Multitenant Solution:
o Complete Isolation: Each PDB is a separate logical database.
The HR schema in PDB1 is totally distinct from the HR schema in PDB2. They
are in different containers and cannot "see" each other.

o No Renaming Required: Third-party applications can be plugged in without

any modification to their schema names. This is a monumental advantage.

2. Problem: Weakened Security

 Issue: A super-user (e.g., DBA) in a consolidated database has privileges

over every application's data.

 Multitenant Solution:

o Two-Tiered User Model: Multitenant introduces Common Users (exist in

CDB$ROOT and every PDB) and Local Users (exist only in a single PDB).

o Isolated Privileges: A local user in PDB_SALES can be granted

the DBA role within that PDB only. They have no privileges or visibility
into PDB_HR. This provides true administrative isolation between tenants.

o Application Security is Preserved: Application users are created as local

users, making their privileges scoped exclusively to their own PDB.

3. Problem: Application Maintenance & Downtime

 Issue: Patching or putting one application in restricted mode forces

downtime for all applications in the same instance.

 Multitenant Solution:

o PDB-Level Operations: You can startup, shutdown, backup, recover,

and patch PDBs individually.

o Example: You can shut down PDB_DEV for maintenance

while PDB_PROD and PDB_QA remain fully open and serving users. This granular
control eliminates forced, organization-wide downtime for minor tasks.

4. Problem: Point-in-Time Recovery (PITR)

 Issue: Recovering one application's data to a previous point would recover

the entire database, affecting all applications.

 Multitenant Solution:
o PDB-Level Recovery: Using RMAN, you can perform a Tablespace Point-
in-Time Recovery (TSPITR) or a full recovery on a single PDB without
affecting any other PDB in the CDB. This is a game-changer for operational
recovery.

5. Problem: Cloning and Provisioning

 Issue: Reliance on slow and complex Data Pump exports/imports to create

new environments.

 Multitenant Solution:

o Lightning-Fast Cloning: Creating a new copy of a database is now a

metadata operation. You can clone a PDB in minutes, not hours.
sql

-- Create a full, independent copy of PDB_PROD for testing

CREATE PLUGGABLE DATABASE pdb_prod_test FROM pdb_prod
FILE_NAME_CONVERT=('/path/to/pdb_prod/', '/path/to/pdb_prod_test/');
ALTER PLUGGABLE DATABASE pdb_prod_test OPEN;

o Refreshable Clones: You can even create a clone that can be refreshed
from its source, perfect for keeping a test environment current.

Conclusion for Mark and Globomantics

Mark's previous conclusion—that schema-based consolidation was too costly
and risky—was 100% correct for the technology available at the time.

Oracle Multitenant Architecture is the direct, engineered response

to those exact problems.

It delivers the "holy grail" of consolidation:

 The ECONOMICS of schema consolidation (high density on one server).

 The ISOLATION of instance consolidation (security, management, and

availability are separated by PDB).

 The AGILITY of modern DevOps (quick cloning, plug/unplug, individual

recovery).

For Globomantics, this means they can:

1. Safely consolidate non-production environments (Dev, Test, QA) onto
a few powerful servers, realizing massive cost savings on hardware and
Oracle licenses (using the single free PDB perk per CDB).

2. Gain confidence in the model before considering a move for production

systems, where the benefits of rapid cloning, isolated patching, and
granular recovery are equally valuable.

Multitenant isn't just a new feature; it's a fundamental architectural shift that
makes consolidation projects like the one Mark attempted years ago not just
feasible, but practical and highly advantageous.

Thinking of it in terms of technologies like PostgreSQL and Docker is a

fantastic way to understand the Oracle Multitenant architecture.

Let's break down your analogy to make it even clearer.

The "PostgreSQL" Analogy

Your comparison is spot-on:

Oracle
PostgreSQL Term Multitenant Explanation
Equivalent

This is the system-wide catalog. It

CDB$ROOT (Roo holds cluster-wide metadata, roles
postgres database
t Container) (common users), and
management information.

This is the read-only template

used to create new user
template1 databas PDB$SEED (Seed databases quickly. createdb in PG
e PDB) uses template1; CREATE PLUGGABLE
DATABASE ... in Oracle
uses PDB$SEED.
 Oracle
PostgreSQL Term Multitenant Explanation
Equivalent

This is the actual "database" your

Pluggable
application connects to. It
User Database Database
contains its own schemas, tables,
(e.g., myapp_db) (PDB)
data, and a private data dictionary
(e.g., MYPLUG)
that links back to the root.

The Key Difference: In PostgreSQL, these databases are all part of a single
database cluster but are still somewhat isolated from each other. In Oracle
Multitenant, the isolation is more formalized and containerized, which leads
perfectly to your next analogy.

The "Docker" Analogy: A Perfect Fit

This is perhaps the best analogy for understanding the power of Multitenant.

Docker / Oracle Multitenant

Explanation
Container Term Equivalent

This is the running software and

Docker
memory processes
Daemon / The CDB Instance
(PMON, SMON, SGA, etc.). It's the
Container (ORACLE_SID)
engine that hosts the containers.
Runtime
There is one instance per CDB.

This is the portable, static

An Unplugged
artifact. It's a packaged set of
Docker Image PDB (.pdb file
datafiles and metadata that can
+ .xml)
be deployed.
Docker / Oracle Multitenant
Explanation
Container Term Equivalent

This is the actual live, running

Running A Plugged-in, "database" that applications can
Container Open PDB connect to. You can have many
running on the same engine.

CREATE PLUGGABLE
docker run / docker DATABASE ... / ALTER The commands to deploy an
start PLUGGABLE image into a running container.
DATABASE OPEN

ALTER PLUGGABLE Stops the container/PDB but

docker stop
DATABASE CLOSE keeps it deployed on the host.

Removes the container/PDB from

DROP PLUGGABLE
docker rm the runtime (can keep the
DATABASE ...
image/datafiles).

docker
ALTER PLUGGABLE Packages a running container
commit / docker
DATABASE UNPLUG into a static image for transport.
save

CREATE PLUGGABLE
docker Imports an image and makes it
DATABASE ...
pull / docker load available to the runtime.
USING ...

You can allocate and cap CPU,

Resource memory, and I/O for individual
Resource
Limits (CPU, PDBs within the CDB, preventing
Manager Plans
Mem) "noisy neighbors" just like in
Docker.
 Why This Analogy is So Powerful
It explains the core benefits you discovered:

1. Density: You can run dozens of "databases" (PDBs) on a single "runtime"

(CDB instance), saving huge amounts of memory and CPU compared to
running dozens of independent database instances (the old way).
2. Isolation: Each PDB is self-contained. An app in PDB A cannot see data in
PDB B, just like two apps in separate Docker containers are isolated.
3. Portability: The ability to unplug a PDB from one CDB and plug it into
another is exactly like moving a Docker container from one host to another.
This enables:
o Easy migration from on-prem to cloud.
o Rapid cloning of production data for development/testing.
o Load balancing across servers.

Your final point is crucial: The CDB itself is mostly "runtime" and system
metadata. The application's data and its specific metadata
(your EMPLOYEES table, its structure, etc.) live entirely within the
PDB. This is why you can so cleanly unplug it and move it around.

So yes, your understanding is 100% correct. Oracle Multitenant is essentially

a database containerization platform built directly into the Oracle
Database engine, and it solves the exact same class of problems that Docker
solves for operating systems: agility, density, isolation, and portability.

Your analogies are spot on:

 Container Ship (CDB): The engine, the hull, the crew. It provides the power
(memory/CPU), the steering (background processes), and the navigation
(root data dictionary).

 Shipping Containers (PDBs): The isolated, standardized cargo. Each

contains a complete, self-contained application database. They don't have
their own engine; they rely on the ship.

 USB Drives (PDBs): The pluggability. They are self-contained units of data
and metadata that can be unplugged from one port (CDB) and plugged into
another.
 Now, let's address Mark's concerns one by one.

Addressing Mark's Concerns About Multitenancy

1. Performance Problems & Resource Allocation ("Noisy Neighbors")

 Concern: Will a runaway query in PDB_A bring PDB_B to its knees?

 Answer: This is the #1 feature. Oracle introduced the Multitenant

Resource Manager for this exact reason.

o You can create directives that guarantee a minimum amount of CPU, I/O, or
parallel server slots to a specific PDB.

o You can also cap the maximum resources a PDB can use, preventing any
single PDB from hogging all the CDB's resources.

o Conclusion: Resource control is not just possible; it's more granular and
enforceable than in a traditional consolidated server with multiple instances.

2. Single Point of Failure & Backup/Recovery

 Concern: If the CDB instance fails, don't all PDBs fail with it? How do I
recover just one?

 Answer: Yes, the CDB is a single instance, so it is a single point of

failure from an instance perspective. However, the backup/recovery story is
a major benefit.

o Backup: You can still use RMAN. You can back up the entire CDB (all PDBs
at once) or back up individual PDBs.

o Recovery: This is the killer feature. You can perform a Point-in-Time

Recovery (PITR) on a single PDB without affecting any other PDB in the
 CDB. This was nearly impossible with schema consolidation and complex
with instance consolidation.

o High Availability: Solutions like Data Guard and Oracle RAC operate at
the CDB level. You fail over the entire CDB, protecting all PDBs within it
simultaneously.

3. Security & Cross-PDB Access

 Concern: Can a user in PDB_HR see data in PDB_SALES?

 Answer: No, by default, absolutely not. The isolation is strict.

o A user in one PDB cannot even see that another PDB exists, let alone access
its data. They are logically separate databases.

o The Exception: A specially created Common User (e.g., C##ADMIN) can

connect to the root and, if granted privileges, to individual PDBs. But even
then, to access data in PDB_SALES from PDB_HR, you would need a dedicated
database link, just like you would between two separate, traditional
databases. There is no implicit access.

4. Administration & Maintenance

 Concern: Do I have to grant admin rights to all PDBs? Will patching one
affect others?

 Answer: This is where the simplification shines.

o Common Users: You can create a common DBA user (C##DBA) that has
privileges across all PDBs. This simplifies overall administration.

o Local Users: You can also have local DBAs in each PDB whose privileges are
confined to that PDB alone—perfect for application owners.
o Patching: You patch the CDB once (the "ship"), and all PDBs ("containers")
inherit the patch. This drastically reduces maintenance windows.

o PDB-Specific Operations: Crucially, you can startup, shutdown, and put

into restricted mode each PDB individually. Maintenance on PDB_DEV does
not require an outage for PDB_PROD.

5. Monitoring and Script Changes

 Concern: How do I adapt my scripts?

 Answer: This is a key operational change. Your scripts must become

"container-aware."

o New Views: You must switch from DBA_* views to CDB_* views
(e.g., CDB_USERS instead of DBA_USERS) and filter by CON_ID to see information
across all PDBs.

o Connection Context: Always know which container (SHOW CON_NAME) you

are connected to when running scripts. A script run from the root will see
everything; run from a PDB, it sees only itself.

o Conclusion: Scripts need updating, but the new views provide a more
powerful, consolidated view of your entire database estate.

6. Connecting to a PDB

 Concern: Is connecting different?

 Answer: No, and this is critical for application compatibility. An

application has no idea it's connecting to a PDB.

o You connect via Oracle Net using a service name (e.g., myplug) instead of a
SID.
o This service name is dynamically registered by the CDB's listener, pointing
directly to the PDB.

o The connection string in your

application (jdbc:oracle:thin:@server:1521/myplug) does not change from what it
would be for a non-CDB. The application is blissfully unaware it's part of a
multitenant architecture.

Summary for Mark

Mark's concerns are classic and correct. The Oracle Multitenant architecture
doesn't dismiss these concerns; it provides engineered solutions for each
one:

1. Isolation: Achieved through logical separation and the Resource Manager.

2. Availability: Enhanced with granular PDB-level backup and recovery.

3. Security: Strengthened with the Common User/Local User model.

4. Manageability: Dramatically improved through unified patching and

granular control.

5. Compatibility: Preserved for applications and connections.

The multitenant option isn't just a new way to store data; it's a new
operational model for the Oracle Database that is designed to provide the
consolidation benefits of schema pooling while maintaining the isolation and
manageability of separate instances. It directly answers the challenges Mark
faced in his previous consolidation attempts.
Oracle 12c Container Database (CDB) Tutorial

Introduction to Oracle 12c Container Architecture

Oracle 12c introduced a new multitenant architecture that allows multiple

pluggable databases (PDBs) to exist within a single container database
(CDB). This tutorial will explore the key concepts and commands for working
with this architecture.

Checking Database Processes

Viewing Oracle Processes on Linux

To check Oracle database processes on a Linux system, use the ps command

with filtering:
bash
# Check for Oracle processes using pmon
ps -ef | grep pmon

Explanation:

 ps -ef lists all running processes

 grep pmon filters for Oracle Process Monitor processes
 Each running database will have its own pmon process

Comparing Process Counts

bash
# Count processes for UPGR database
ps -ef | grep UPGR | wc -l
# Count processes for CDB1 database
ps -ef | grep CDB1 | wc -l

Explanation:

 The UPGR database (version 11i) shows 26 processes

 The CDB1 container database shows 47 processes
 Container databases have more processes because they manage
multiple PDBs

Exploring Container Database Views

Viewing Containers in a CDB

sql
-- Show all containers in the CDB
SELECT * FROM v$containers;

Expected Output:
text
CON_ID NAME OPEN_MODE RESTRICTED
------ ---------- ---------- ----------
1 CDB$ROOT READ WRITE NO
2 PDB$SEED READ ONLY NO
3 MYPLUG READ WRITE NO

Explanation:

 CDB$ROOT: The root container containing Oracle system metadata

 PDB$SEED: Read-only template used to create new PDBs
 MYPLUG: A user-created pluggable database

Comparing V$CONTAINERS and V$PDBS

sql
-- Describe the v$containers view
DESC v$containers;

-- Show only pluggable databases (excludes root)

SELECT * FROM v$pdbs;

Explanation:

 v$containers shows all containers including the root

 v$pdbs shows only pluggable databases (excluding the root)

Examining System Parameters in CDB

Viewing Parameter Modifiability

sql
-- Check system parameters and their modifiability
SELECT name, value, ispdb_modifiable, con_id
FROM v$system_parameter
ORDER BY con_id, name;

Explanation:

 ispdb_modifiable indicates if a parameter can be modified at the PDB level

 con_id shows which container the parameter applies to
 Some parameters (like control files) apply to the entire CDB
 Others (like sessions) can be set differently for each PDB

Parameter Inheritance
sql
-- Check parameter values across containers
SELECT name, value, con_id
FROM v$system_parameter
WHERE name = 'sort_area_size';

Explanation:
  PDBs inherit parameter values from the CDB unless explicitly set
 In the example, MYPLUG inherits the sort_area_size value from
CDB$ROOT

Exploring Storage Architecture

Viewing Tablespaces Across Containers

sql
-- Show tablespaces and their container associations
SELECT ts#, name, con_id
FROM v$tablespace
ORDER BY con_id, ts#;

Expected Output:
text
TS# NAME CON_ID
--- --------- ------
0 SYSTEM 1
1 SYSAUX 1
2 UNDOTBS1 1
3 TEMP 1
0 SYSTEM 2
1 SYSAUX 2
3 TEMP 2
0 SYSTEM 3
1 SYSAUX 3
3 TEMP 3
4 MYPLUG_TS 3

Explanation:

 Each container has its own SYSTEM and SYSAUX tablespaces

 UNDO tablespace exists only at the CDB level
 TEMP tablespace exists in each container
 PDBs can have additional tablespaces (like MYPLUG_TS)
Examining Data Files
sql
-- View data files across all containers
SELECT con_id, file_name, tablespace_name
FROM cdb_data_files
ORDER BY con_id;

-- Compare with dba_data_files (current container only)

SELECT file_name, tablespace_name
FROM dba_data_files;

Explanation:

 cdb_data_files shows data files across all containers (includes CON_ID)

 dba_data_files shows only data files in the current container

Joining Container and Data File Information

sql
-- Detailed view of PDB data files
SELECT p.name AS pdb_name, d.file_name, d.tablespace_name
FROM cdb_data_files d, cdb_pdbs p
WHERE d.con_id = p.con_id
ORDER BY p.name;

Explanation:

 This query joins container information with data file information

 Shows only pluggable databases (excludes root)
 Demonstrates how data files are separated by PDB

Viewing Data Files from Within a PDB

sql
-- Connect to a specific PDB
ALTER SESSION SET CONTAINER = myplug;
-- View data files in the current PDB
SELECT con_id, file_name, tablespace_name
FROM cdb_data_files;

Explanation:

 When connected to a PDB, CDB views show only that PDB's information
 The CON_ID column helps identify which container the data belongs to

Parameter Storage in CDB Architecture

Checking the SPFILE

bash
# View the spfile content
strings $ORACLE_HOME/dbs/spfileCDB1.ora | grep -i cdb1

Explanation:

 The spfile only contains parameters for the CDB instance

 PDB-specific parameters are stored in each PDB's system tables
 This allows PDBs to be unplugged and plugged into different CDBs

Key Takeaways

1. Process Architecture: CDBs have more processes than non-CDBs to

manage multiple PDBs
2. Container Types:

o Root container (CDB$ROOT) - contains system metadata

o Seed container (PDB$SEED) - template for creating new PDBs
o Pluggable databases (PDBs) - user-created containers
3. Data Dictionary Views:

o CDB_ views - show information across all containers

 o DBA_ views - show information for the current container only
o V$ views - often include CON_ID to identify the container
4. Parameter Management:

o Some parameters are CDB-level only

o Others can be set at the PDB level
o PDBs inherit CDB parameter values unless explicitly set
5. Storage Architecture:

o Each PDB has its own set of data files

o Data files are associated with specific containers
o This enables plug/unplug operations
6. Parameter Storage:

o CDB parameters are stored in the spfile

o PDB parameters are stored in each PDB's system tables

This architecture provides both isolation between databases (through

separate data files and parameter settings) and consolidation benefits
(shared background processes and memory).

Oracle Multitenant Architecture: A Practical

Tutorial

Part 1: Core Concepts & Summary

Based on your demonstration, let's formalize the key concepts you
discovered.

1. What is a Multitenant Container Database (CDB)?

A CDB is a single Oracle database that acts as a container for
multiple pluggable databases (PDBs). It's the "umbrella" database that
owns the memory structures, background processes, and the overall
instance.
 2. Key Components of a CDB

Component Name Description

The master container. It stores the Oracle

system metadata (data dictionary) and
Root
CDB$ROOT common users (users known in every
Container
container). There is exactly one root
per CDB.

A read-only template used to create new

PDBs. Cloning this seed is the fastest way
Seed PDB PDB$SEED
to provision a new PDB. You cannot
modify this PDB.

These are the "tenant" databases. Each

Pluggable (User- PDB is a self-contained set of schemas,
Databases defined, objects, and data that appears to
(PDBs) e.g., MYPLUG) applications and users as a regular, non-
CDB Oracle database.

3. Summary of Your Findings

 Isolation & Consolidation: PDBs are logically separate (their own data
dictionary, schemas) but physically consolidated
(shared PMON, SMON, DBWn processes, and SGA).
 Process Overhead: As you correctly observed (26 vs 47 processes), a CDB has
more background processes than a non-CDB to manage the complexity of
multiple PDBs.
 Storage: Each tablespace (like MYPLUG_TS) has datafiles that belong to a
single PDB. This is what allows a PDB to be unplugged (its datafiles are
packaged up) and plugged into a different CDB.
 Data Dictionary: The "magic" of multitenancy. The root (CDB$ROOT) holds
the system metadata, while each PDB has its own "application-specific" data
dictionary, which links back to the root.
 Parameters: Some parameters are set at the CDB level and inherited by all
PDBs (e.g., MEMORY_TARGET). Others can be set uniquely for each PDB
(e.g., SESSIONS), allowing for customized resource management.
Part 2: Essential Commands for CDB/PDB
Management
Now, let's move on to the commands you'll need to create and manage
these environments.

1. Connecting to the Database

First, you need to know how to connect to the different containers.
sql
-- 1. Connect to the CDB as a privileged user (like the old SYS)
-- Using SQL*Plus from the OS:
sqlplus / as sysdba

-- This will typically connect you to the root container (CDB$ROOT).

-- Check which container you are in:
SHOW CON_NAME

-- 2. Connect to a specific PDB from the root

ALTER SESSION SET CONTAINER = myplug;

-- 3. Connect directly to a PDB using Oracle Net

-- You need a TNS entry for the PDB service name.
-- The service name is usually the PDB name.
sqlplus sys@myplug as sysdba

2. Viewing Containers and PDBs

You already saw the most important views. Here are the key queries.
sql
-- See all containers (including root and seed)
SELECT con_id, name, open_mode FROM v$containers;

-- See only Pluggable Databases (excludes root)

SELECT con_id, name, open_mode FROM v$pdbs;

-- Get detailed info about PDBs (very useful!)

SELECT pdb_name, status FROM dba_pdbs;

3. Starting and Stopping PDBs

PDBs have their own open modes, independent of the CDB.
sql
-- From the root container, open a single PDB
ALTER PLUGGABLE DATABASE myplug OPEN;

-- Open all PDBs

ALTER PLUGGABLE DATABASE ALL OPEN;

-- Close a specific PDB

ALTER PLUGGABLE DATABASE myplug CLOSE;

-- Close all PDBs

ALTER PLUGGABLE DATABASE ALL CLOSE;

-- Put a PDB into read-only mode

ALTER PLUGGABLE DATABASE myplug OPEN READ ONLY;

4. Creating a New PDB

There are several ways to create a PDB. The most common is cloning the
seed.
sql
-- 1. Create a PDB by cloning the SEED (Most Common)
CREATE PLUGGABLE DATABASE salespdb
ADMIN USER salesadmin IDENTIFIED BY password
ROLES=(DBA)
FILE_NAME_CONVERT=('/opt/oracle/oradata/CDB1/pdbseed/',
'/opt/oracle/oradata/CDB1/salespdb/');

-- 2. Create a PDB by cloning an existing PDB

CREATE PLUGGABLE DATABASE devpdb FROM salespdb
FILE_NAME_CONVERT=('/opt/oracle/oradata/CDB1/salespdb/',
'/opt/oracle/oradata/CDB1/devpdb/');

-- After creation, you MUST open the new PDB!

ALTER PLUGGABLE DATABASE salespdb OPEN;

Explanation of FILE_NAME_CONVERT:
This clause tells Oracle where to find the template files (from the seed or
source PDB) and where to put the new datafiles for the PDB you are creating.
In a real environment, you might use CREATE PLUGGABLE DATABASE ...
CREATE_FILE_DEST instead to let Oracle manage the file locations
automatically.

5. Unplugging and Plugging In a PDB

This is the core feature that enables database mobility.
sql
-- 1. From the CDB, close the PDB
ALTER PLUGGABLE DATABASE myplug CLOSE;

-- 2. Unplug it. This generates an XML metadata file.

ALTER PLUGGABLE DATABASE myplug UNPLUG INTO '/path/to/myplug.xml';

-- 3. Now you can drop it (but keep the datafiles!)

DROP PLUGGABLE DATABASE myplug KEEP DATAFILES;

-- 4. To plug it into the SAME or a DIFFERENT CDB

CREATE PLUGGABLE DATABASE myplug USING '/path/to/myplug.xml'
NOCOPY; -- Use NOCOPY if the datafiles are already in the right place
-- OR use COPY/MOVE if you need to relocate the files.

ALTER PLUGGABLE DATABASE myplug OPEN;

Part 3: Addressing Mark's Concerns

 You mentioned Mark's excitement and his valid concern about larger, critical
systems. This is a common and important discussion point.

Is Multitenant for Production and Critical Systems?

Absolutely. Yes. This was a major point of validation for Oracle. While it's
perfect for development/QA consolidation (for the reasons Mark guessed), it
is also designed and fully supported for the most critical OLTP and Data
Warehouse workloads.

1. Performance Isolation: Oracle has invested heavily in features

like IOPS, memory, and CPU resource management at the PDB level. You
can guarantee a minimum amount of resources for your critical PDB and cap
resources for others, preventing "noisy neighbors."
2. Manageability: Patching and upgrades are dramatically faster. You patch
the CDB once, and all PDBs within it inherit the patch. This is a game-
changer for maintenance windows.
3. High Availability: RMAN backups, Data Guard, and GoldenGate all operate
with multitenancy. You can fail over an entire CDB or, with more advanced
configurations, even individual PDBs.
4. License: The Multitenant Option requires a separate license. However, you
are allowed to create one user-created PDB (plus the seed) without this
license. This lets you test the technology and use it for development without
extra cost before committing to the full licensed option for production.

Conclusion: Multitenant is not just for "smaller" systems. It is the future of

the Oracle database platform and is intended for all workloads, offering
superior consolidation, management, and agility benefits. The key is
understanding how to properly configure resource management for a
production environment.

This tutorial should give you a strong foundation to start experimenting with
creating your own CDBs and PDBs. The next logical step is to practice these
commands in your lab environment.