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

Under the Hood of Pluggable Databases

Alex Gorbachev San Francisco, CA September 2013

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

Who is Pythian? •  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

© 2013 Pythian 3

When to engage Pythian?

© 2013 Pythian 4

Tier 3 Data Local Retailer

Strategic upside value from data

Value of Data

Tier 2 Data eCommerce

Tier 1 Data Health Care

Profit

Loss

LOVE YOUR DATA

Impact of an incident, whether it be data loss, security, human error, etc.

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

Consolidation options pre-12c •  Multiple physical machines •  Multiple virtual machines •  Multiple databases •  Multiple schemas

Flexibility

Efficiency

Consolidation options today •  Multiple physical machines •  Multiple virtual machines •  Multiple databases •  Multiple pluggable databases •  Multiple schemas

Flexibility

Efficiency

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

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

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

Use cases

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

Development and testing environments •  Simple clones and refreshes

Cloud and SaaS hosting •  Host multiple environments efficiently

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

database versions

How it works

The technical part

Terminology

CDB CDB$ROOT

PDB$SEED

PDB1 PDB2

PDB3 PDB4

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

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

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

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.

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

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

Network Connectivity •  Separate service names

–  Within CDB –  Within listeners

Separation of duties •  Local and common users

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

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

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

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

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

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-on-write snapshot (NOCOPY clause)

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;

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;

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;

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;

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

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;

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

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

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

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

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

Thanks and Q&A Contact info

gorbachev@pythian.com

+1-877-PYTHIAN

To follow us pythian.com/blog

@alexgorbachev @pythian

linkedin.com/company/pythian