Your SlideShare is downloading. ×
Under The Hood of Pluggable Databases by Alex Gorbachev, Pythian, Oracle OpeWorld 2013 UTHPDB
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Under The Hood of Pluggable Databases by Alex Gorbachev, Pythian, Oracle OpeWorld 2013 UTHPDB


Published on

Peek under the hood of Oracle Pluggable Database feature - part of the new Oracle Database 12c Multitenant Option

Peek under the hood of Oracle Pluggable Database feature - part of the new Oracle Database 12c Multitenant Option

Published in: Technology
1 Comment
1 Like
  • Very nice, concise, presentation that describes Oracle DB12c pluggable concepts in a manner that cuts away the marketing-heavy aspects of Oracle's presentations on the subject.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 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.
  • 5. Agenda •  •  •  •  PDB introduction & use cases How PDB works Manipulating PDBs Wrapping up
  • 6. Consolidation options pre-12c •  •  •  •  Multiple physical machines Multiple virtual machines Multiple databases Multiple schemas Flexibility Efficiency
  • 7. Consolidation options today •  •  •  •  •  Multiple physical machines Multiple virtual machines Multiple databases Multiple pluggable databases Multiple schemas Flexibility Efficiency
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. Use cases
  • 12. Database consolidation •  The obvious one •  Increase efficiencies and drive down costs •  Simplify maintenance
  • 13. Development and testing environments •  Simple clones and refreshes
  • 14. Cloud and SaaS hosting •  Host multiple environments efficiently
  • 15. Simplified patches and upgrades •  Upgrade a whole set of databases at once •  Plug/unplug databases to upgrade to future database versions
  • 16. How it works The technical part
  • 17. Terminology PDB$SEED CDB$ROOT CDB PDB3 PDB4 PDB1 PDB2
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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.
  • 22. 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
  • 23. 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
  • 24. Network Connectivity •  Separate service names –  Within CDB –  Within listeners
  • 25. Separation of duties •  Local and common users
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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)
  • 32. 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;
  • 33. 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;
  • 34. 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;
  • 35. 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;
  • 36. 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
  • 37. 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;
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. Thanks and Q&A Contact info +1-877-PYTHIAN To follow us @alexgorbachev @pythian