Oracle database 12c introduction- Satyendra Pasalapudi

© Copyright 2013. Apps Associates LLC.
1
Oracle Database 12c – An Introduction
-- Satyendra P
@pasalapudi

2
Satyendra Kumar Pasalapudi
Associate Practice Director – IMS @ Apps Associates
Co Founder & Vice President of AIOUG
@pasalapudi

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

4
Rethinking Architecture for the Database Cloud
Multitenant Architecture
Capabilities Enabled
Managing Shared Resources
Upgrading to Multitenant
Use Cases
Agenda

Oracle Database 12c New Features

Database-as-a-Service (DBaaS):
Gives users access to databases running on a cloud computing platform

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

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

Components of a Multitenant Container Database (CDB)
Pluggable Databases (PDBs)
PDBs
Root
CDB

•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 Dictionary
User Data
Me ta Data
Mature Database
Data Dicti onary
User Data
Me ta Data
Tables, Code, Data added
Data Dicti onary
User Data
Me ta Data

OBJ$
TAB$
SOURCE$
…
Oracle Data and User Data
EMP
DEPT
…
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

Pluggable Database
MEMORY
2
2.5
3
ERP
BI
DW
Pluggable Database
MEMORY
Multitenant Scalability
•Only small increments in memory as additional PDBs are added
0
0.5
1
1.5
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.

30

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 HCM@us.acme.db1
Remote (DB Link)
Local

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

Step 1: Upgrade databases in-place
Upgrade in Place

Step 2: Plug-in upgraded databases

•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.)

54

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 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

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;
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
select * from pruebas fetch first 30 percent rows only;
---------- ---------- -------- ----------
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;
---------- ---------- -------- ----------
1 Hola 21/05/13 1
2 como 21/05/13 2
3 te 21/05/13 3
select * from pruebas offset 2 rows fetch next 2 rows only;
---------- ---------- -------- ----------
3 te 21/05/13 3

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

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

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
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
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
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

75
Dynamic Plan – Adaptive Execution Plan

Demo
Demo by Sukumar Chillakuru & Suneel Y on AWS EC2 Instance using EM12c on 12c Database

Thank You!
Satyendra.kumar@aioug.org
Satyendra.pasalapudi@appsassociates.com
@pasalapudi

Oracle database 12c introduction- Satyendra Pasalapudi

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à Oracle database 12c introduction- Satyendra Pasalapudi

Similaire à Oracle database 12c introduction- Satyendra Pasalapudi (20)

Plus de pasalapudi123

Plus de pasalapudi123 (10)

Dernier

Dernier (20)

Oracle database 12c introduction- Satyendra Pasalapudi