The document discusses pluggable databases (PDBs) in Oracle, detailing their architecture, use cases, and management capabilities. It highlights how PDBs enhance database consolidation, efficiency, and resource management while maintaining application transparency. Key features include rapid cloning, role separation, and the ability to upgrade multiple databases simultaneously.

1. Under the Hood of
Pluggable Databases
Alex Gorbachev
San Francisco, CA
September 2013

2. Alex Gorbachev
•
•
•
•
•
•
•
•
•
Chief Technology Officer at Pythian
Blogger
Cloudera Champion of Big Data
OakTable Network member
Oracle ACE Director
Founder of BattleAgainstAnyGuess.com
Founder of Sydney Oracle Meetup
IOUG Director of Communities
EVP, Ottawa Oracle User Group

3. Who is Pythian?
•
•
•
•
•
•
© 20133Pythian
15 Years of Data
infrastructure
management consulting
170+ Top brands
6000+ databases under
management
Over 200 DBA’s, in 26
countries
Top 5% of DBA work
force, 9 Oracle ACE’s, 2
Microsoft MVP’s
Oracle, Microsoft, MySQL
partners, Netezza,
Hadoop and MongoDB
plus UNIX Sysadmin and
Oracle apps

4. When to engage Pythian?
LOVE YOUR DATA
Strategic upside value
from data
Profit
Value of Data
Loss
Tier 3 Data
Local Retailer
Tier 2 Data
eCommerce
© 20134Pythian
Tier 1 Data
Health Care
Impact of an incident,
whether it be data loss,
security, human error,
etc.

6. Agenda
•
•
•
•
PDB introduction & use cases
How PDB works
Manipulating PDBs
Wrapping up

7. Consolidation options pre-12c
•
•
•
•
Multiple physical machines
Multiple virtual machines
Multiple databases
Multiple schemas
Flexibility
Efficiency

8. Consolidation options today
•
•
•
•
•
Multiple physical machines
Multiple virtual machines
Multiple databases
Multiple pluggable databases
Multiple schemas
Flexibility
Efficiency

9. Like a single database
•
•
•
•
•
One buffer cache and shared pool
One set of background processes
Can be backed up and data guard all at once
Single RAC cluster
Supports hundreds of fully isolated applications
in one DB
• Global resource management

10. Like separate databases
• Full isolation of each application
• No application changes required for
consolidation
• Support for public synonyms without conflicts
• Granular resource management
• Per-database startup/shutdown/recovery
• Internal PDB resource management

11. New Capabilities
•
•
•
•
•
•
Plug/unplug entire PDB database
Rapid PDB cloning
Separation of roles (PDB admin vs CDB admin)
Resource management
Recovery of individual PDBs
Saving resources

12. Use cases

13. Database consolidation
• The obvious one
• Increase efficiencies and drive down costs
• Simplify maintenance

14. Development and testing
environments
• Simple clones and refreshes

15. Cloud and SaaS hosting
• Host multiple environments efficiently

16. Simplified patches and upgrades
• Upgrade a whole set of databases at once
• Plug/unplug databases to upgrade to future
database versions

17. How it works
The technical part

18. Terminology
PDB$SEED
CDB$ROOT
CDB
PDB3
PDB4
PDB1
PDB2

19. Data Dictionary and PDBs
• DD metadata is stored in root only
– Like TAB$ and its columns definitions
– PDB links to that metadata in the root
– Cannot be changed from PDB
• DD content is stored in both root and PDBs
– Root contains rows about common entries
– PDB inherits data from root (read-only) + add its own
• Some objects are visible from both root and
PDBs

20. The split data dictionary
• PDB and CDB both have SYSTEM/SYSAUX
tablespaces
• Metadata Links and object links expose common
data and metadata to PDBs
– Built-in PL/SQL objects for example
• PDB sessions see a combination of common
and private data
– Think UNION

21. Changes to data dictionary views
• DBA_ views in a CDB root only show common
objects
• CDB_ views: show all objects, common and for
all PDBs
• CDB_PDBS: PDB associated with a given CDB
• CDB_PDB_HISTORY: history of plug/unplug
operations
• CON_ID column added to most data dictionary
and performance view; identifies container DB

22. Oracle database kernel for PDB
• Memory structures are instrumented
– Every entry gets con_id
– All X$ tables expose con_id
– V$ views on top of these X$ views utilize con_id filter
– PDB level views and tables filter records only for that
container
• Data dictionary becomes a merge of common
and PDB objects
– OBJ$, TAB$ and etc.

23. So what about:
•
•
•
•
•
•
•
•
•
•
Table SCOTT.TAB1
Database links
Controlfiles
Package DBMS_SHARED_POOL
Package SCOTT.PKG1
Redo logs
Undo tablespaces
Flashback logs
TDE encryption keys
Temp tablespace

24. More complex cases
• Table SYS.OBJ$
• Has metadata for both common and local
objects
• Remember: we must maintain application
transparency, even when querying the data
dictionary

25. Network Connectivity
• Separate service names
– Within CDB
– Within listeners

26. Separation of duties
• Local and common users

27. Resource management
• Making sure one PDB doesn’t monopolize
shared resources
• Database resource manager has been
enhanced with PDB awareness
• Can manage resources inside a PDB and
between PDBs
• I/O resource manager (Exadata) has too
• Storage limits can be applied to PDB objects.
Examples: total DB size, max shared temp
usage

28. Management tools
• Plain old SQL works 
• OEM 12c has
pluggable database
awareness – dropdown
box to select a PDB
• SQL developer works
with pluggable
databases too

29. Backup and restore
• PDBs and CDBs have their own datafiles
• RMAN runs from the root CDB
• Can do operations on entire CDB, or individual
PDBs
• Remember undo and redo are common, so PDB
backups include this common data too

30. Four ways to get a PDB (1)
• From PDB$SEED
– Creates a blank database
– Can also create a local admin user, default tablespace,
local tempspace
• From an existing local PDB
– Like TTS, must be opened read-only
– Inherits attributed unless overridden
– file_name_convert for example
• From an existing remote PDB
– The source PDB can be on another CDB
– Metadata transferred using a database link
– Character set and endian format must match

31. Four ways to get a PDB (2)
• From an unplugged PDB
– Metadata saved in an XML file as part of the unplug
process
– Use dbms_pdb.check_plug_compatibility to
verify compatibility: character set, endian format
• File transfers
– Use either built-in Oracle copy or external transfer like
copy-on-write snapshots
– Oracle copy can run in parallel, but COW snapshots
are almost always faster
– file_name_convert option to change file location
pointers, or use OMF

32. Cloning a PDB: preparation
• File name conversion options:
– file_name_convert clause in plug operation
– Use Oracle managed files to guarantee uniqueness
– Set PDB_FILE_NAME_CONVERT initialization
parameter for default values
• Choose file copy method: use Oracle to copy
files (COPY clause), or externally like a copy-onwrite snapshot (NOCOPY clause)

33. Cloning a PDB
•
•
•
•
Connect to CDB root as an admin user
Reopen source pdb in read-only mode
alter pluggable database pdb1 close;
alter pluggable database pdb1 open
read only;
• create pluggable database pdb3 from
pdb1 admin user adm identified by
secret file_name_convert = (‘/u01/
oradata/pdb1’,’/u01/oradata/pdb3’);
• Open the database
• alter pluggable database pdb3 open;

34. Cloning a remote PDB
• You clone directly from another CDB
• Communication happens through a database link
• CDBs must be binary compatible (endian format,
character set, etc)
• file_name_convert and other parameters work
the same way
• create pluggable database pdb4 from
pdb1@remote_site admin user adm
identified by secret;
• alter pluggable database pdb4 open;

35. Creating an empty PDB
• Just like cloning, but you clone the Seed
database
• Seed database is initially empty
• Use regular create database syntax to create
additional users and tablespaces
• create pluggable database pdb5 admin
user adm identified by secret
default tablespace users datafile ‘/
u01/oradata/pdb5/users_01.dbf’ size
500m;
• alter pluggable database pdb5 open;

36. Unplugging and re-plugging
• Similar to transportable tablespaces
• XML file has PDB metadata
• Connect to source CDB as an administrative
user
• Shut down PDB
• alter pluggable database pdb2 close;
• alter pluggable database pdb2 unplug
into ‘/u01/oradata/pdb2/pdb2.xml’;
• drop pluggable database pdb2 keep
datafiles;

37. Unplugging and re-plugging (2)
• Like transportable tablespaces, you can check
compatibility
• Run from destination CDB
• select
dbms_pdb.check_plug_compatibility
( pdb_descr_file=>’/u01/oradata/
pdb2/pdb2.xml’, store_report=>true)
from dual;
• Errors are logged in the
pdb_plug_in_violations table

38. Unplugging and re-plugging (3)
• We’re now ready to plug in the PDB
• Use AS CLONE to create new unique IDs, if a
local clone already exists
• If files have been moved externally, use nocopy
source_file_convert
• create plugggable database pdb2
using ‘/u01/oradata/pdb2/pdb2.xml’
nocopy;

39. Migrating to pluggable databases
• Convert non-CDB 12c into a PDB by generating
PDB XML file
• Create a blank PDB and use logical replication
tools (data pump, GoldenGate, CTAS over DB
link) to bring data over from pre-12c
• Upgrade as a standalone database to 12c, and
then plug in as a PDB
• For future releases and patches, simply unplug
and plug into new-version CDB directly

40. Lessons learned
• Copy-on-write snapshots rock with PDBs
– They save storage space too
• PDBs do not open automatically on startup;
– use alter pluggable database all open;
• Naming: don’t prefix PDB names with CDB
• Avoid PDB names conflicts – moving between
CDBs is an issue + potential service names
conflict in listener registrations

41. Watch for
• More workload to shared processes and resources –
might require more efforts to make sure they don’t
become bottlenecks
–
–
–
–
–
–
–
–
LGWR process
DBWR processes
LMS processes
SQL Area
Data Dictionary
Audit trail
Buffer cache
Data Guard log shipment
• Not based on experience but just a simple thought
experiment

42. Is it worth extra cost?
• Single PDB deployment is free
– Plug/unplug upgrade use case
• Extra option costs 37% list on top of
pure EE
– Take in account other options you
have and it might only be around 10%
of incremental cost
– Easy to save more resources
(including licensed CPU capacity)
when consolidating at scale

43. Wrapping up
• PDB is a major improvement in Oracle database
functionality
– Main benefits – improved agility and reduce
consolidated resource usage
• PDBs give benefits of both multi-database and
multi-schema consolidation
• Transparent to applications
• Might require more attention to individual
components administration

44. Thanks and Q&A
Contact info
gorbachev@pythian.com
+1-877-PYTHIAN
To follow us
pythian.com/blog
@alexgorbachev
@pythian
linkedin.com/company/pythian