Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
Under The Hood of Pluggable Databases by Alex Gorbachev, Pythian, Oracle OpeWorld 2013 UTHPDB
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
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
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.
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
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