© Copyright 2013. Apps Associates LLC. 1
Oracle Database 12c – An Introduction -- Satyendra P
@pasalapudi
© Copyright 2013. Apps Associates LLC. 2
Satyendra Kumar Pasalapudi
Associate Practice Director – IMS @ Apps Associates
Co Founder & Vice President of AIOUG
@pasalapudi
© Copyright 2013. Apps Associates LLC. 3
Performance. Growth. Excellence.
• Global Reach, Broad Service Profile
• Founded in 2002, 600+ employees
• US, Europe, India, Middle East
• Service Offerings: Applications, CRM, Analytics, EPM, Cloud, Middleware, Application Development, App & Infrastructure Managed Services
• Significant Investment in R&D
• Cloud (IaaS, PaaS, SaaS)
• Business Process & System Integration
• Analytics & Big Data
• Strategic Partnerships, Certifications, Credentials
• Oracle Platinum Partner, Oracle Specialized Across Our Portfolio of Services
• AWS Advanced Consulting Partner, Certified Managed Services Provider
• Microsoft Certified
• CMMI Level 3 & SSAE 16
© Copyright 2013. Apps Associates LLC. 4
Rethinking Architecture for the Database Cloud
Multitenant Architecture
Capabilities Enabled
Managing Shared Resources
Upgrading to Multitenant
Use Cases
Agenda
Cloud Computing
Oracle Database 12c New Features
Database-as-a-Service (DBaaS):
Gives users access to databases running on a cloud computing platform
Oracle Database 12c New Features
Oracle Database 12c New Features
Oracle Database 12c New Features
Oracle Database Architecture Requires memory, processes and database files
System Resources
New Multitenant Architecture Memory and processes required at multitenant container level only
System Resources
New Multitenant Architecture Memory and processes required at multitenant container level only
System Resources
Advantages of Multitenant Architecture Reduced CapEx & OpEx, Increased Agility, Easy Adoption
Self-contained PDB for each application Applications run unchanged Rapid provisioning (via clones) Portability (via pluggability)
Shared memory and background processes More applications per server
Common operations performed at CDB level Manage many as one (upgrade, HA, backup) Granular control when appropriate
Rethinking Architecture for the Database Cloud
Multitenant Architecture
Capabilities Enabled
Managing Shared Resources
Upgrading to Multitenant
Use Cases
Multitenant Architecture
Components of a Multitenant Container Database (CDB)
Pluggable Databases (PDBs)
PDBs
Root
CDB
Multitenant Architecture
• Multitenant architecture can currently support up to 252 PDBs
• A PDB feels and operates identically to a non-CDB
• You cannot tell, from the viewpoint of a connected client, if you’re using a PDB or a non-CDB
Database Link
Unplug / plug
Simply unplug from the old CDB…
Unplug / plug
…and plug in to the new CDB…
• Moving between CDBs is a simple case of moving a PDB’s metadata
• An unplugged PDB carries with it lineage, opatch, encryption key info etc
Unplug / plug
Example
alter pluggable database HCM
unplug into '/u01/app/oracle/oradata/…/hcm.xml'
create pluggable database My_PDB
using '/u01/app/oracle/oradata/…/hcm.xml'
Plug
Unplug
Common Data Dictionary Before 12.1: dilution over time
Database Created
Data D
ictio
nary
User Data
Meta D
ata
Mature Database
Data D
ictio
nary
User Data
Meta D
ata
Tables, Code, Data added
Data D
ictio
nary
User Data
Meta D
ata
OBJ$ TAB$ SOURCE$
…
Oracle Data and User Data
OBJ$ TAB$ SOURCE$
…
EMP DEPT
…
OBJ$ TAB$ SOURCE$
…
Multitenant fix:
Horizontally-
partitioned data
dictionary
Only Oracle system
definition remains
Data dictionary is
diluted by customer’s
metadata
Horizontally Partitioned Data Dictionary
OBJ$ TAB$ SOURCE$
…
EMP DEPT
…
OBJ$ TAB$ SOURCE$
…
Oracle-supplied
objects such as
views, PL/SQL, etc.,
are shared across
all PDBs using
object “stubs”
In-database
virtualization
Multitenant Architecture – Dynamics
• PDBs share common SGA and background processes
• Foreground sessions see only the PDB they connect to
0
0.5
1
1.5
2
2.5
3
CRM HCM ERP BI
GB
Pluggable Database
MEMORY
0
0.5
1
1.5
2
2.5
3
CRM HCM ERP BI DW
GB
Pluggable Database
MEMORY
Multitenant Scalability
• Only small increments in memory as additional PDBs are added
0
0.5
1
1.5
2
2.5
3
CRM HCM ERP
GB
Pluggable Database
MEMORY
Files in the CDB
• Each PDB has its own set of tablespaces including SYSTEM and SYSAUX
• PDBs share UNDO, REDO and control files, (s)pfile
• By default the CDB has a single TEMP tablespace but PDBs may create their own
Namespaces
Users • Local users are the successors for
customer-created users in a non-CDB
• A local user is defined only in a PDB
• A local user can administer a PDB
A common user is defined in the root
and is represented in every PDB
A common user can log into any PDB
where it has “Create Session” and can
therefore administer a PDB
The Oracle system is owned by
common users
Container Database Architecture
To summarize a CDB is an Oracle Database that contains the root and eventually several pluggable databases. A CDB can contain upto 253 PDBs including the seed. 252 user defined PDBs can be created in one Container 12c Database.
© Copyright 2013. Apps Associates LLC. 30
Oracle Database 12c New Features
The new Oracle Database 12c, maintains system privileges SYSDBA, SYSOPER, SYSASM, 11g of its predecessor but includes three new system privileges, extremely important and contribute to building a more secure and robust, in the issue of security .
These privileges are:
SYSBACKUP
SYSDG
SYSKM
New administrative privileges in Oracle Database 12c: SYSBACKUP, SYSDG and SYSKM
Manage Many as One with Multitenant Backup databases as one; recover at pluggable database level
One Backup
Point-in-time recovery At pluggable database level
New Syntax and Clauses in RMAN
Manage Many as One with Multitenant One standby database covers all pluggable databases
Multitenant for Simplified Patching Apply changes once, all pluggable databases updated
Upgrade
in-place
Multitenant for Upgrades Flexible choice when patching & upgrading databases
Expand Cluster to Support Flexible Consolidation Model
Services
Single SGA per CDB Instance
Improved Agility With Changing Workloads
Node1
CDB Instance 1
Node2
CDB Instance 2
Multitenant Container Database (CDB)
Expand Cluster to Support Flexible Consolidation Model
Services
Single SGA per CDB Instance
Node1
CDB Instance 1
Node2
CDB Instance 2
Node3
CDB Instance 3
Improved Agility With Changing Workloads
Multitenant Container Database (CDB)
Multitenant for Fast Provisioning Pluggable databases can be quickly provisioned from seed
0
5
10
15
20
25
Non CDB PDB Clone PDB using Copy-on-Write File System
Time Taken to Provision New Database
Multitenant for Provisioning
PDBs can be cloned from remote CDBs
PDBs can be cloned from within the same CDB
Fast cloning of PDBs
Cloning a PDB
Example
create pluggable database HCMBI from HCM
create pluggable database HCMBI from [email protected]
Remote (DB Link)
Local
Cloning Made Easy within DB
Cloning Across DBs
Per PDB vs per CDB Common operations on CDB with granular control where appropriate
Single Oracle Software Version
Data Guard
Scheduled RMAN Backups
Some parameters/properties
e.g. homogeneous character set
Redo and Undo
RMAN point-in-time recovery
Ad hoc RMAN backups
Flush shared pool
Parameters where IsPDB_Modifiable = 'TRUE'
Per CDB Per PDB
• Rethinking Architecture for the Database Cloud • Multitenant Architecture • Capabilities Enabled • Managing Shared Resources • Upgrading to Multitenant • Use Cases
Managing Shared Resources
Resource management in multitenant environment
High Priority
Medium Priority
Low Priority
Managing Resources between PDBs
• Using Resource Manager, you can control
– CPU
– Exadata I/O
– Sessions
– Parallel execution servers
• Configure a policy that controls how resources are utilized
– Default configuration that works, even as PDBs are added or removed
– Hard limits, for “get what you pay for”
Manage CPU
Pluggable Database Shares Guaranteed CPU Maximum CPU
HCM 2 2/4 = 50% 100%
CRM 1 1/4 = 25% 100%
ERP 1 1/4 = 25% 100%
2 Shares 1 Share 1 Share
A CDB Resource Plan uses
shares to specify how CPU is
distributed between PDBs
Rethinking Architecture for the Database Cloud
Multitenant Architecture
Capabilities Enabled
Managing Shared Resources
Upgrading to Multitenant
Use Cases
Upgrading to Multitenant
Step 1: Upgrade databases in-place
Upgrade in Place
Upgrading to Multitenant Step 2: Plug-in upgraded databases
Upgrading to Multitenant
• No application changes required.
Step 3. Change applications to work with Multitenant Step 3. Change applications to work with Multitenant
Migrate using Replication
① Provision new PDB from Seed
② Replicate using technologies such as Oracle GoldenGate or Data Pump New in 12.1, you ask that full database export and full database import make maximum use of transportable tablespaces in the single expdb and impdb commands. (Backported to 11.2.0.3.)
© Copyright 2013. Apps Associates LLC. 54
• Rethinking Architecture for the Database Cloud • Multitenant Architecture • Capabilities Enabled • Managing Shared Resources • Upgrading to Multitenant • Use Cases
1. Multitenant for Test and Development
Fast, flexible copy and snapshot of pluggable databases
2. Consolidation of Disparate Applications
Shared overhead of memory and processes System Resources
RAC, Data Guard, Daily Incrementals
Data Guard Daily Incrementals
Pick from standard sizes and service levels
3. Self-Service Database as a Service (DBaaS)
✔
GOLD
SILVER
BRONZE Weekly Full Backups
✔
RAC, Data Guard, Daily Incrementals
Data Guard Daily Incrementals
Pick from standard sizes and service levels
3. Self-Service Database as a Service (DBaaS)
✔
GOLD
SILVER
BRONZE Weekly Full Backups
✔
4. Multitenant. Perfect for SaaS.
Multitenancy implemented by the Database, not the Application
Multitenant. Perfect for ISVs.
Packaged apps and reference data are easily distributed
Data file movement now online
• Data types VARCHAR2, NVARCHAR2, and RAW have been increased to 32K
• A temporary UNDO tablespace has been added to the database, linked to global temporary tables.
• Oracle Data Pump 12c, can turn the redo import processes for added load performance. This feature is only on import.
• To turn off mode "Archive log" is not necessary to down the database.
• Move or rename a "datafile" is now online
• Check paged. Keywords SQL level will limit the number of records that must be deployed. This replaces the old reference ROWNUM
Oracle Database 12c New Features
SQL> select * from pruebas;
CAMPO1 CAMPO2 CAMPO3 CAMPO4
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
3 te 21/05/13 3
4 encuentras 21/05/13 4
5 en 21/05/13 5
6 este 21/05/13 6
7 momento 21/05/13 7
7 filas seleccionadas.
SQL> select * from pruebas fetch first 2 rows only;
CAMPO1 CAMPO2 CAMPO3 CAMPO4
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
select * from pruebas fetch first 30 percent rows only;
CAMPO1 CAMPO2 CAMPO3 CAMPO4
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
3 te 21/05/13 3
select * from pruebas fetch first 50 percent rows only;
CAMPO1 CAMPO2 CAMPO3 CAMPO4
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
3 te 21/05/13 3
4 encuentras 21/05/13 4
select * from pruebas offset 2 rows fetch next 2 rows
only;
CAMPO1 CAMPO2 CAMPO3 CAMPO4
---------- ---------- -------- ----------
3 te 21/05/13 3
4 encuentras 21/05/13 4
Oracle Database 12c New Features
SQL*Plus: Release 12.1.0.0.2 Beta on Mar May 21 16:38:09 2013
Copyright (c) 1982, 2012, Oracle. All rights reserved. Enter the user name: system @ lab1 Enter the password: Right Connection last time: Mon May June 2013 20:26:44 -06:00 Connected to:Oracle Database 12c Enterprise Edition Release 12.1.0.0.2 - 64bit Beta With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> select to_char(sysdate,'dd-mon-yy hh24:mi') from dual; TO_CHAR(SYSDATE --------------- 21-may-13 16:39
Last login Time Information in SQL*Plus
Oracle Database 12c New Features
Optimizer evolution
In the beginning
there were rules
Optimizer evolved to be cost based
CBO
CBO
Optimizer proactively adapts to become self-learning
Rule are not enough
Databases became more feature rich
Reactive tuning with the use of advisors and auto jobs
As environment changes Potential for plan changes
Databases become more real-time, ad-hoc environments
Reactive tuning not enough
© Copyright 2014. Apps Associates LLC. 70
Adaptive Execution Plans
• A query plan changes during execution because runtime conditions indicate that optimizer estimates are inaccurate
• All adaptive execution plans rely on statistics that are collected during query execution.
• The database uses adaptive execution plans when OPTIMIZER_FEATURE_ENALBE is set to 12.1.01 or later and OPTIMIZER_ADAPTIVE_REPORTING_ONLY parameter set to false.
• The two adaptive plan techniques are
– Dynamic Plans
– Re optimization
Adaptive Plans Join methods Parallel distribution methods
Adaptive Statistics Discovered at compile time Discovered at run time
Adaptive Query Optimization
Overview Adaptive Query
Optimization
Adaptive Plans
Adaptive
Statistics
Join
Methods
Parallel
distribution
Methods
At compile
time
At run
time
Query: Find all of the products with a unit price of 15 that we have sold more that 1 of
Two possible join methods for this query
Nested Loops
Hash Join
Adaptive Execution Plans
Adapt join methods
Alternative sub-plans are pre-computed
Sub-plans stored in the cursor
Stats collect inserted before join
Rows buffered until final decision is made
Adaptive Execution Plans
Adapt join methods
Table scan
Order _items
NESTED LOOPS
Index Scan
Prod_info_ind
Statistics Collector
Default Plan is a nested loops join
HASH JOIN
Table scan
Prod_info
Rows coming out of order_items table are buffered up to a point If row count is less than the threshold use nested Loops otherwise switch to hash join
Number of rows seen in statistics collector exceeds threshold
Plan switches to hash join
Statistics collect disabled
Plan resolved on first execution & remains the same for subsequent executions
Adaptive Execution Plans
Adapt join methods
Final Plan is a hash join
Statistics collector disabled after decision is made and becomes a pass through operation
Table scan
Order _items
NESTED LOOPS
Index Scan
Prod_info_ind
HASH JOIN
Table scan
Prod_info
Statistics Collector
© Copyright 2014. Apps Associates LLC. 75
Dynamic Plan – Adaptive Execution Plan
Demo
Demo by Sukumar Chillakuru & Suneel Y on AWS EC2 Instance using EM12c on 12c Database