Transcript con3075_oow16 - Kai Yu`s Oracle Blog

Leveraging
Oracle Database 12c Release 2
Multitenant Features
[CON3075]
Anuj Mohan, Technical Account Manager, Data Intensity
Deiby Gomez, CEO, Nuvola, S.A.
James Czuprynski, Strategic Solutions Architect, OnX USA LLC
Kai Yu, Senior Principal Engineer,
Andy Colvin, Infrastructure Principal Director, Accenture
Safe Harbor Statement
The following is intended to outline Oracle’s general
product direction. It is intended for information
purposes only, and may not be incorporated into any
contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decisions. The
development, release, and timing of any features or
functionality described for Oracle’s products remains
at the sole discretion of Oracle.
Our Agenda
 PDB Migration Features and Techniques
 Application Containers
 Relocate / Clone / Refresh
 Controlling PDB Resources




Instance Caging
I/O Limits
Performance Profiles
ADO and HeatMaps
 Other Neat PDB Stuff
 RAC Capabilities
 FLASHBACK Pluggable Database
Application Containers
Anuj Mohan
Oracle ACE , Founder Oracle 12c SIG (IOUG)
Technical Account Manager , Data Intensity LLC
Oracle Certified Exadata Implementer
Oracle Certified RAC Expert
Oracle 11g/12c Certified Professional (OCP)
Multitenant Architecture
 CDB is a normal database with additional capability of storing one or more
non CDB
 These non CDB's within CDB are called PDB
 PDB's can be plugged and unplugged easily from one container to another
container.
 ***CDB Container database
 ***PDB pluggable database
SGA and PGA
and
BG Processes
Multitenant Architecture
Container Database Instance
PDB3
PDB1
PDB2
Pluggable Databases
Why Application Containers
 One of the goals of the multitenant architecture is that each container has
a one-to-one relationship with an application
 If we are using PDBs for applications and we need database to be upgraded
or patched in the same CDB or across many CDBs
 Pluggable databases until 12.1 has no single master definition of
application
 You were bound to run upgrade script in all PDBs individually - a time and
resource intensive operation
Multitenant Architecture
NEW IN
SGA and PGA
and
BG Processes
with Application Containers
App
PDB
root
User_01,User_02,User_n….
Use “as Application
container” clause
PDB3
To install application Use
“Begin/End install” clause
PDB1
Synchronize App. PDBs with
“SYNC” clause
PDB2
 Container Database
Pluggable Databases
12.2
Application Containers: Installation
 Create application root
CREATE PLUGGABLE DATABASE applications_PDB
AS APPLICATION CONTAINER
ADMIN USER ADMIN
IDENTIFIED BY MANAGER;
 Open application container
ALTER PLUGGABLE DATABASE applications_PDB OPEN;
 Set current container as application container
ALTER SESSION SET CONTAINER = applications_PDB ;
SHOW CON_NAME
Application Containers: Installation
 Start application installation
ALTER PLUGGABLE DATABASE APPLICATION App_install_0919 BEGIN
INSTALL 'CDB-2.1.0';
DDLs /DMLs
 End application installation
ALTER PLUGGABLE DATABASE APPLICATION App_install_0919 END INSTALL
'CDB-2.1.0‘ ;
Application Containers: Clone and Sync
 Clone
 Connect to application root (Application PDB) and run clone command
SQL>conn sys/cdb1@//localhost/applications_PDB as sysdba
SQL>ALTER USER app_owner SET CONTAINER_DATA=ALL
CONTAINER=CURRENT;
SQL>CREATE PLUGGABLE DATABASE applications_PDB_clone1
ADMIN USER ADMIN IDENTIFIED BY ADMIN;
SQL>ALTER PLUGGABLE DATABASE applications_PDB_clone1 OPEN;
Application Containers: Clone and Sync
 Make some changes in applications root pdb
 SYNC newly created clone
ALTER SESSION SET CONTAINER = APPLICATIONS_PDB_CLONE1;
SQL>conn system/cdb1@//localhost/applications_PDB_clone1
SQL>ALTER PLUGGABLE DATABASE application App_install_0919 SYNC;
Multitenant Architecture
Application Containers
patching/upgrade
SGA and PGA
and
BG Processes
Pdb_app
Pdb_app_
clone1
Container
Database
Instance
Pluggable
Databases
•
Connect to pdb_app pdb as app root user
•
Start upgrade with “begin upgrade”
•
Run the ddl’s for upgrade
•
End upgrade with “end upgrade to”
•
Connect to pdb_app_clone1 pdb as app user
•
Check current version of application
•
SYNC applications using alter pdb command
•
Check current version of application
NEW IN
12.2
Application Containers: Patching and Upgrading
 Connect to pdb_app pdb as app root user
connect app_owner/app_owner@//localhost/pdb_app ;
 Check current application version
SQL>SELECT APP_NAME,APP_ID,APP_VERSION FROM DBA_APPLICATIONS;
 Begin upgrade/patching
ALTER PLUGGABLE DATABASE APPLICATION App_install_0919 BEGIN UPGRADE
'CDB-2.4.4' TO 'CDB-2.5.0‘ ;
Application Containers: Patching and Upgrading
• End upgrade /patching
ALTER PLUGGABLE DATABASE APPLICATION App_install_0919 END UPGRADE
TO 'CDB-2.5.0';
• Check current application version
SELECT APP_NAME,APP_ID,APP_VERSION FROM DBA_APPLICATIONS;
Application Containers: Patching and Upgrading (SYNC)
• Connect to pdb_app_clone1 pdb as app user
connect app_owner/app_owner@//localhost/pdb_app_clone1 ;
• Check current application version
SELECT APP_NAME,APP_ID,APP_VERSION FROM DBA_APPLICATIONS;
• SYNC application
ALTER PLUGGABLE DATABASE APPLICATION App_install_0919 SYNC;
• Check current application version
SELECT APP_NAME,APP_ID,APP_VERSION FROM DBA_APPLICATIONS;
PDB Migration Features
and Techniques
Assess. Design. Build. Secure. Manage.
Jim Czuprynski
•
•
•
•
•
•
35+ years of database-centric IT experience
Oracle DBA since 2001
Oracle 10g, 11g, 12c OCP
Oracle ACE Director
100+ articles on databasejournal.com and ioug.org
Regular speaker at Oracle OpenWorld, IOUG
COLLABORATE, and OTN ACE Tours
• Oracle-centric blog (Generally, It Depends)
19
Multitenant: New Handling for UNDO and REDO
CDB1
AP
AP_ROLE
HR
MFG
MFG_ROLE
HR_ROLE
PDB2
SYSTEM
SYSAUX
SYSTEM
SYSTEM
SYSAUX
A significant change to 12c
Multitenant architecture is
the [optional] addition of an
UNDO tablespace to an
individual PDB.
This enables tracking of
transactions back to
individual PDBs …
SYSAUX
UNDO
TEMP
UNDO
TEMP
TEMP
UNDO
AP_DATA
HR_DATA
MFG_DATA
… so PDB transactions can
continue during PDB migration
and cloning activities!
NEW IN
12.2
PDBs: Pretty Fast Provisioning
CDB1
PDB3
PDB5
PDB2
PDB4
11gR2
DB
STILL JUST
12.1
Four ways to provision PDBs:
1. Clone from PDB$SEED
2. Clone from existing PDB
3. “Replugging” previously “unplugged”
PDB
4. Plug in non-CDB as new PDB
All PDBs already plugged into CDB stay
alive during these operations! *
* Unfortunately, to accomplish each of
these operations, it was necessary to
bring the source PDB into READ ONLY
mode for at least several seconds.
PDB Creation On Steroids
STILL JUST
NEW IN
12.1
12.2
Relocate
Copy from
PDB$SEED
Copy
Local
Clone from
Existing PDB
Creating PDBs
From PDB
Remote
Plug In
Previously
Unplugged PDB
Plug In
Plug In Non-CDB
as PDB
Reference as a
Proxy PDB
From Non-CDB
Local and Remote Proxy PDBs
A proxy PDB can
be either local
(within the same
CDB) …
CDB1
NEW IN
12.2
CDB2
… or it can be a
remote proxy PDB
(across two CDBs)
PDB2
PDB5
MainLINK
benefits
of Proxy PDBs:
SQL@CDB1> CREATE DATABASE
CDB1
SQL@CDB1>
SQL@CDB2>CREATE
CREATEPLUGGABLE
DATABASE DATABASE
LINK CDB1PDB3
Create
new
remote
Create
new
local
Create
an
intra-CDB
Create
a DB
Link
SQL@CDB2>
CREATE
PLUGGABLE
DATABASE
PDB4
CONNECT
TO C#ADMIN
 Aggregate
data
from
multiple
application
back
ends
AS PROXY
CONNECT
TO C#ADMIN
proxy
PDB
(PDB4)
for
proxy
PDB
(PDB3)
DB
Link
for
PDB1
on
between
CDB1
andfor
CDB2
AS
PROXY
IDENTIFIED
BY PDBs
R3alS3cur
 Access more
than
4,096
(the
new
limit
for
a
12.2
CDB)
FROM
PDB1@CDB1;
IDENTIFIED
BY R3alS3cur
source
PDB
(PDB1)
source
PDB
(PDB1)
CDB1
FROM PDB1@CDB1;
USING
cdb1;
 PropagateUSING
changes
between different application roots in two different CDBs
cdb1;
Refreshable PDB Clones
NEW IN
12.2
CDB1
CDB2
PDB2
PDB5
Advantages of Refreshable Clones:
SQL@CDB2>
CREATE
LINK
CDB1 PDB6
SQL@CDB2>
CREATE DATABASE
PLUGGABLE
DATABASE
 Build “materialized
PDBs”
CONNECT
TO C#ADMIN
FROM
PDB3@CDB1
 RefreshesIDENTIFIED
can happen at
scheduled
intervals …
BY
R3alS3cur
REFRESH MODE EVERY 120 MINUTES;
 … or on-demand
via manual DBA command
USING cdb1;
PDB6 is kept synchronized
with PDB3 … but in READ
ONLY mode!
PDB6
is created
so it’s
Create
an inter-CDB
automatically
refreshed
DB Link between
CDB1
every 2 hours!
and CDB2
Relocating PDBs Live
NEW IN
12.2
CDB1
CDB2
PDB2
PDB5
PDB5 is migrated to
CDB2 … even while
transactions continue!
SQL@CDB2>
CDB1 PDB5
LiveLINK
Relocation
of PDBs:
SQL@CDB2> CREATE
CREATE DATABASE
PLUGGABLE
DATABASE
Issue command to
Create a DB Link
CONNECT
TO
C#ADMIN
 Goal: Simpler
to hybrid cloud environments
FROM migration
PDB2@CDB1
relocate PDB2 from
between CDB1 and CDB2
IDENTIFIED
BY R3alS3cur
RELOCATE;
CDB1 to CDB2:
 DML activity
continues
on
original
PDB
until
file
relocation
is completed
USING cdb1;
 Once last COMMIT is registered, automatic switchover to relocated PDB
FLASHBACK PLUGGABLE DATABASE
FLASHBACK PLUGGABLE DATABASE






DEIBY GOMEZ
Oracle ACE - Youngest in the world, 23.
Oracle ACE Director - Youngest in the world, 25.
President of Guatemala Oracle Users Group
Oracle Certified Master 11g (OCM 11g) – Youngest in Latin America, 24.
Oracle Certified Master 12c (OCM 12c) – Youngest in Latin America, 26.
SELECT Journal Editor’s Choice Award 2016 (Vegas, given by IOUG)
FLASHBACK PLUGGABLE DATABASE
Flashback operations in 12.1:
• CDB Level
• Flashback operation
Impacts all the PDB in the
CDB.
Flashback operations in 12.2:
• CDB Level
• PDB Level
• Using SCN
• Using Restore Point
• Using Clean Restore Point
• Using Guarantee Restore Point
It can work with:
PDB using Local Undo (12c New Feature), The flashback operation will be in-place like if it were 11g!!
If Shared Undo (12.1), We must use an auxiliary instance. Similar to Recover table from RMAN Backup in
12.1.
FLASHBACK PLUGGABLE DATABASE
1. Connect to CDB$ROOT
Assumptions: ARCHIVELOG Mode and Flashback Enabled.
1. Ensure that the PDB is closed (Other PDBs can be open)
ALTER PLUGGABLE DATABASE pdb1 CLOSE;
2. -- Flashback PDB –
It depends on (Local | Shared) Undo.
1. Open PDB with Resetlogs:
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
FLASHBACK PLUGGABLE DATABASE
When using Local Undo:
FLASHBACK
FLASHBACK
FLASHBACK
FLASHBACK
PLUGGABLE
PLUGGABLE
PLUGGABLE
PLUGGABLE
DATABASE
DATABASE
DATABASE
DATABASE
pdb1
pdb1
pdb1
pdb1
TO
TO
TO
TO
SCN 12345;
RESTORE POINT ResPoint1;
CLEAN RESTORE POINT CleanResPoint1;
TIME "TO_DATE(’09/22/16','MM/DD/YY');
When using Shared Undo:
FLASHBACK PLUGGABLE DATABASE pdb1 TO SCN 12345 AUXILIARY DESTINATION '+data';
FLASHBACK PLUGGABLE DATABASE pdb1 TO RESTORE POINT ResPoint1
AUXILIARY DESTINATION '/temp/aux_dir';
FLASHBACK PLUGGABLE DATABASE pdb1 TO TIME "TO_DATE(’09/22/16','MM/DD/YY')”
AUXILIARY DESTINATION '+data’;
FLASHBACK PLUGGABLE DATABASE
Benefits
•
•
•
•
•
All data files for a PDB are flashed back
All undo for a PDB is applied in-place
Flashback a PDB without impact others PDBs
Recover a PDB from Logical Data corruption or User Errors
Useful for Testing / Upgrades
Heat Map and Automatic Data
Optimization in Oracle 12c Multitenant
Database
Oracle RAC Support for Oracle 12c
Multitenant Database
Senior Principal Engineer, Dell Database Engineering
 21 years working with Oracle Technology
 Specializing in Oracle RAC/DB, Virtualization and Cloud
• Oracle ACE Director, Oracle papers author and frequent
presenter (presented last consecutive 11 OOWs)
 2011 OAUG Innovator of Year, 2012 Oracle Excellence
Award: Technologist of the Year: Cloud Architect by Oracle
Magazine
 My Oracle Blog: http://kyuoracleblog.wordpress.com/
 Co-author Apress Book “Expert Oracle RAC 12c”

Kai Yu
Database Storage Challenges
 Exponential data growth posts great challenges to IT organization
• Exposition in data for online access , data retention,
• Database performance impacted by volumes of data
• IT budgets on storage : performance/cost/volums
• Adapting storage tiring to improve the storage efficiency
 ILM (Information Lifecycle Management (ILM): practices of applying specific policies for
effective information management
 With respect to databases, ILM refers to the processes and practices of aligning digital
records—table “rows”—with the most appropriate and cost effective IT infrastructure at each
phase of its useful life
New Features in Oracle Database 12cR1
 Oracle Introduced an automated method to implement ILM in Oracle 12cR1
 Heat Map
• Stores system-generated data usage statistics:
time of last modification and access of the objects:
• Segment level: tables and partitions
• Row level: individual rows (aggregated to the block level)
• Skips internal access done for system tasks including stats gathering, DDLs or table
redefinitions
• Dictionary view: DBA_HEAT_MAP_SEGMENT or USER_HEAT_MAP_SEGMENT
 Automatic Data Optimization
• Allows you to create policies for data compression (Smart Compression) and data
movement, to implement storage and compression tiering
• Smart Compression : leveraging Heat Map information to associate compression policies,
and compression levels, with actual data usage
Limitation of Heat Map/ADO in Oracle 12cR1
 ADO and Heat Map are not supported in Multitenant database.
 Here is a test comparing heat map between non PDB and PDB:
• In non CDB database:
•
In CDB database:
Limitations of Heat Map/ADO in Oracle 12cR1
 Observations:
• In non-CDB, Heat Map recorded the statistics of two updates and access customer
table and customer_I2 indexes
• In CDB, Heat Map didn’t recorded any statistics
• Without the statistics tracked in Heat Map , no ADO action will be performed.
 Further studies:
• Limitation: ADO and Heat Map are not supported with a multitenant container
database (CDB) in Oracle 12cR1
• Documented in Oracle Support Doc ID 1612385.1
• Also documented in Database VLDB and Partitioning Guide
Limitation removed in Oracle 12cR2
 What Oracle 12cR2 documentation says about ADO/Heat MAP in PDB:
Oracle Database VLDB and Partitioning Guild 12c Release 2( 12.2): Changes for Very Large
Database and Partitioning in Oracle Database Release 2(12.2.0.1)
 Let’s test this feature in Oracle 12cR2 multitenant CDB:
Oracle RAC
Support
forforPluggable
Databases
Oracle
RAC Support
Pluggable Databases
 How 12c Pluggable Database works on Oracle 12c RAC
Oracle RAC
Support
forforMultitenant
Databases
Oracle
RAC Support
Pluggable Databases
 How to connect to a PDB:

Using the default service with the same name as the PDB name

Using user defined services

Using ALTER SESSION command and setting the container to the desired

container

Using the Enterprise Manager Express interface
 Using the default service created with PDB: An example
PDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = RACscan.dblabe.com)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = pdb1.dbase.lab))
Oracle RAC
Support
forforMultitenant
Databases
Oracle
RAC Support
Pluggable Databases
– Using the user defined service with PDB
• Create a dynamic database service using the SRVCTL
$srvctl add service -db cdb -service hr1 -pdb pdb1 -preferred host1 -available host2
• Start Service: srvctl status service -db cpdb -service hr1
• Add an tnsnames entry with this service
HR1_PDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = RACscan.dblab.com)
(PORT = 1521)) (CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = HR1.dblab.com))
• Connect PDB through user defined service
$sqlplus username/password@HR_PDB1
For more information, take a look at this Dell Techcenter Wiki article:
How to connect to Pluggable Databases in Oracle 12c RAC?
Contact me at [email protected] or visit my Oracle Blog at
http://kyuoracleblog.wordpress.com/
Controlling PDB Resources
Andy Colvin
• 10 years at Enkitec / Accenture
• Supporting Oracle since 1999
• Working with Exadata since 2010
• Oracle ACE
• Blog – blog.oracle-ninja.com
• Twitter – @acolvin
• Email – [email protected]
What’s New In Resource Management
PDBs in 12.1
PDBs in 12.2
All PDBs shared SGA from the CDB
More control of memory
General I/O resource management
IORM only on Exadata
Proper instance caging
Limited CPU caging
Simplified resource management
plans
PDB Memory Management
 SGA can be divided between pluggable databases
 Parameters that now set minimum sizes within a PDB:
 DB_CACHE_SIZE
 SHARED_POOL_SIZE
 SGA_MIN_SIZE (Sum of SGA_MIN_SIZE for all PDBs should be <50% of SGA)
 SGA/PGA size for a PDB can also be capped
 SGA_TARGET
 PGA_AGGREGATE_LIMIT
*settings not compatible with Automatic Memory Management (MEMORY_TARGET)
PDB Memory Management
 SGA can be divided between pluggable databases
SQL> @pdb_parms_memory.sql
PDB
---------ACPDB1
ACPDB1
ACPDB1
ACPDB2
ACPDB2
ACPDB2
PDB$SEED
PDB$SEED
PDB$SEED
Parameter
------------------db_cache_size
sga_target
shared_pool_size
db_cache_size
sga_target
shared_pool_size
db_cache_size
sga_target
shared_pool_size
VALUE
------------------209715200
1073741824
0
1073741824
4294967296
0
0
0
0
Per-PDB I/O Resource Management
 Previously only available on Exadata, now available on general platforms
 Exadata PDB IORM still works the same way
 Control IOPS and throughput for storage
 New PDB parameters: MAX_IOPS, MAX_MBPS
 Only available on non-Exadata (Exadata already has IORM)
 Does it work?
Per-PDB I/O Resource Management – Does It Work?
No
Limit
 Run SLOB
 Set MAX_IOPS in PDB

alter system set max_iops=4000;
 Check results in OEM
Caged
!
No
Limit
Caged
!
Overall Resource Utilization
 OEM now shows details for each PDB:





Size
Active sessions
Memory utilization
IOPS
I/O throughput
Physical
I/O
Logical
I/O
Per-PDB Performance Profiles
 Resource Manager in 12.1 required each PDB have a specific set of
directive
 OK for <10 PDBs, unwieldy for more
 Adding new PDBs means modifying the entire plan
 In Oracle 12.2, define “performance profiles” and set a parameter for each
PDB
 DB_PERFORMANCE_PROFILE
 Create simple bronze/silver/gold profiles and categorize your PDBs
 You can mix performance profiles and still name PDBs in your resource
plan
Per-PDB Performance Profiles
 PDB profiles require 3 attributes
 share – portion of resources allocated to the profile
 utilization_limit – hard cap for resources (percentage-based)
 parallel_server_limit – maximum percentage of parallel servers used by PDB
PDB Profile
shares
utilization_limit
parallel_server_limit
gold
6
100
100
silver
3
40
40
bronze
1
10
10
default
1
10
10
autotask
1
60
60
Per-PDB Performance Profiles
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
plan
=> 'db_plan',
profile
=> 'gold',
shares
=> 6,
utilization_limit
=> 100,
parallel_server_limit => 100);
END;
/
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
plan
=> 'db_plan',
profile
=> 'silver',
shares
=> 3,
utilization_limit
=> 40,
parallel_server_limit => 40);
END;
/
Different Character Sets Per PDBs Within CDB
 If CDB$ROOT’s character set is AL32UTF8, then any PDBs plugged into the CDB or
cloned are allowed to have a different character set than CDB$ROOT
 PDBs that are created from the seed inherit AL32UTF8 as its character set …
 … but you can migrate the PDB to a different character set
 If CDB$ROOT’s character set is not AL32UTF8, all PDBs in that CDB can only use
use CDB$ROOT’s character set
 Best practice recommendations:
 Use AL32UTF8 for CDB’s database character set
 Use AL16UTF6 for CDB’s national character set
 Consider character sets of current non-CDBs that might be consolidated into CDB


When moving a non-CDB to a CDB, it is best to migrate the non-CDB to AL32UTF8 first
Use Oracle Database Migration Assistant for Unicode (DMU) to ease migration pains
 After a CDB is created, it cannot be migrated to a different character set using DMU!
Over to you …
Feel Free To Contact Us!
Andy Colvin:
[email protected]
Jim Czuprynski:
[email protected]
Deiby Gomez:
[email protected]
Anuj Mohan:
[email protected]
Kai Yu:
[email protected]