Upload
alex-gorbachev
View
1.094
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Peek under the hood of Oracle Pluggable Database feature - part of the new Oracle Database 12c Multitenant Option
Citation preview
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
+1-877-PYTHIAN
To follow us pythian.com/blog
@alexgorbachev @pythian
linkedin.com/company/pythian