oracle database 12c introduction- satyendra pasalapudi

© Copyright 2013. Apps Associates LLC. 1

Oracle Database 12c – An Introduction -- Satyendra P

@pasalapudi


Satyendra Kumar Pasalapudi

Associate Practice Director – IMS @ Apps Associates

Co Founder & Vice President of AIOUG

@pasalapudi

http://www.aioug.org/index.php


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


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






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


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


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






Use Cases


Step 1: Upgrade databases in-place

Upgrade in Place

Upgrading to Multitenant 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.)

• 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

✔

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


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


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


Dynamic Plan – Adaptive Execution Plan

Demo

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

Thank You! [email protected]

[email protected]

@pasalapudi

oracle database 12c introduction- satyendra pasalapudi

Technology

c database

xmlcreate pluggable

pdbthe oracle system

new system privileges

new cdbmoving

apps associates llc

oraclesupplied objects

user defined pdbs