Ensuring Data Protection Using Oracle Flashback Features
Database Consolidation using Oracle Multitenant Architecture
1. Database Consolidation using the
Oracle Multitenant Architecture
Pini Dibask,
Product Manager, Database Solutions
Dell Software Group
[UGF6588] Sunday, Sep 18th 2016
2. Dell Software Group2
About Me …
Pini Dibask, Product Manager, Database Solutions (Dell Software)
Oracle Database Technologist & Architect with 10 years of experience
Oracle Certified Professional DBA (OCP)
Blogger: OracleDBPro.BlogSpot.com
Email: Pini.Dibask@Software.Dell.com
LinkedIn: http://Linkedin.com/in/pinidibask
Google+: https://Plus.Google.com/+PiniDibask87
Twitter: @pini_dibask
3. Dell Software Group3
About Dell Software Database Tools Portfolio
Monitor
Replicate
Team Collaboration for
productive data
professionals
Manage
Protect
4. Dell Software Group4
Agenda
Introduction to Database Consolidation
Oracle Multitenant Concepts
Ensuring QoS in Multitenant environment
RAC and Multitenant
Performance Monitoring for Multitenant environments
5. Dell - Restricted - Confidential
Introduction to
Database Consolidation
6. Dell Software Group6
Database Consolidation - Prior to Oracle 12c
Server Consolidation
Multiple databases reside on a single server
7. Dell Software Group7
Database Consolidation - Prior to Oracle 12c
7
Database Consolidation
Single database with multiple schemas
8. Dell Software Group8
Database Consolidation - Challenges
8
Name Collisions
Same schema name or same public synonym name
Security
DBA can access data of both applications
Upgrades
You cannot patch/upgrade only one schema
Point-In-Time Recovery
Impossible to perform schema level point-in-time recovery
11. Dell Software Group11
11
One set of background processes
One SGA
One root container
Multiple Pluggable Databases
Up to 252 PDBs
Oracle 12c - Multitenant Architecture
12. Dell Software Group12
Multitenant Architecture cont’d
Pluggable Databases share the following files:
Undo Tablespace
Redo Logs
Control Files
(S)Pfile
Temporary tablespace
Note: PDBs may create their own temporary tablespaces
13. Dell Software Group13
Multitenant Advantages - Manage Many as One
Data Guard
Data Guard operates at CDB-Level
Maintenance at CDB-Level = Reduced DBA efforts
CDB-Level granularity for Switchover/Failover operations
14. Dell Software Group14
Multitenant Advantages - Manage Many as One
Upgrades
Upgrade or apply a patch at CDB-Level
https://blogs.oracle.com/UPGRADE/entry/upgrade_pdbs_everything_at_once1
Unplug/plug PDB into another container database
https://blogs.oracle.com/UPGRADE/entry/upgrade_pdbs_one_at_a
16. Dell Software Group16
Multitenant Advantages - Fast Cloning
Clone PDB from another PDB within the same CDB
Requires source PDB to be OPEN READ ONLY
Note: “Hot Clone” will be available in 12.2
s
17. Dell Software Group17
Clone PDB from another PDB in remote CDB
Requires source PDB to be OPEN READ ONLY
Note: “Hot Clone” will be available in 12.2
Multitenant Advantages - Fast Cloning
s
18. Dell Software Group18
s
Multitenant Advantages - Manage Many as One
RMAN – Granular Backup & Restore Options
Backup entire container as one or at PDB level
Recover entire container as one or at PDB level
s
19. Dell Software Group19
CDB-Level vs. PDB-Level
CDB-Level
• Oracle Software
• SGA & Background Processes
• Character Set
• RMAN Scheduled Backups
• Data Guard
• Some Parameters
(IsPDB_Modifiable= 'FALSE')
• Control Files, Redo and Undo
• (S)Pfile, Password File
• Flashback Database
PDB-Level
• FLUSH SHARED_POOL
• FLUSH BUFFER_CACHE
• Point In-Time Recovery
• RMAN Ad hoc Backups
• Some Parameters
(IsPDB_Modifiable= 'TRUE')
20. Dell Software Group20
s
Multitenant Architecture - CDB_* Prefix
CDB_* All objects in CDB across all PDBs
DBA_* All objects in specific PDB
ALL_* Objects accessible by current user
USER_* Objects owned by current user
21. Dell Software Group21
s
Multitenant Architecture - Containers
CON_ID Description
0 Entire CDB/Non-CDB
1 Root container
2 Seed container
3-254 User PDBs
Created by default -
Used as a template
PDB for cloning
22. Dell Software Group22
Multitenant Architecture - Users
Local User
Identity known only in PDB-scope
Common User
Identity known in the root and in all PDBs
C## Prefix (COMMON_USER_PREFIX parameter)
CDB$ROOT
PDB1 PDB2
ERP CRM DW HR
C##U1 C##U2
25. Dell Software Group25
Oracle 12c - Deployment Options
DB CDB$ROOT CDB$ROOT
PDB1 PDB1 PDB2 PDB252
Non-CDB
Same as before 12c
Single Tenant
• No additional license
• One active PDB
Multitenant
• Extra Cost Option
• Requires Enterprise Edition
• Supports up to 252 active PDBs
…
26. Dell Software Group26
Oracle 12c - Deployment Options cont’d
Why use Single Tenant instead of Non-CDB?
Unplug/Plug
Fast Cloning
And most important …
28. Dell - Restricted - Confidential
Ensuring high level of QoS
with Multitenant environments
29. Dell Software Group29
QoS Challenges - Multitenant environments
PDB-Level QoS challenge
Allocation of resources among competing sessions
Example: One session consumes too many resources
CDB-Level QoS challenge
Allocation of resources among competing PDBs
Example: One PDB consumes too many resources
30. Dell Software Group30
The Solution – Oracle Resource Manager
PDB-Level Resource Plan
Specifies how resources are allocated to consumer groups
Prioritize resources between competing sessions
CDB-Level Resource Plan
Specifies how resources are allocated to PDBs
Prioritize resources between competing PDBs
31. Dell Software Group31
Oracle Resource Manager - The Basics
Resource Manager Elements
Resource Plan
Resource Plan Directive
Consumer Group Resource Plan
“WEEKEND”
Directive 1
70% of CPU
Directive 2
20% of CPU
Directive 3
10% of CPU
Consumer Group
“WAREHOUSE”
Consumer Group
“OLTP”
Consumer Group
“OTHERS_GROUPS”
32. Dell Software Group32
Oracle Resource Manager - 12c Multitenant
CDB Resource Plan Directive
CPU Shares
CPU Utilization Limit
Parallel Servers Limit
Memory Limit (Will be available in 12.2)
Example
Pluggable
Database
CPU
Shares
Guaranteed
CPU
CPU Limit Parallel Servers
Limit
OLTP 3 3/4 = 75% 100% 100%
DWH 1 1/4 = 25% 60% 100%
33. Dell Software Group33
Obtain information about default CDB resource plan
Obtain information about default PDB directive
s
s
Oracle Resource Manager - 12c Multitenant
34. Dell Software Group34
CDB-Level Resource Plan Example
Resource Plan
“Daytime_CDB_PLAN”
PDB
“OLTP”
PDB
“DWH”
Directive 2
Guaranteed CPU: 25%
Maximum CPU: 60%
Directive 1
Guaranteed CPU: 75%
Maximum CPU: 100%
Pluggable
Database
CPU
Shares
Guaranteed
CPU
CPU Limit Parallel Servers
Limit
OLTP 3 3/4 = 75% 100% 100%
DWH 1 1/4 = 25% 60% 100%
35. Dell Software Group35
Creating CDB Resource Plan
s
Pluggable
Database
CPU
Shares
Guaranteed
CPU
CPU
Limit
OLTP 3 3/4 = 75% 100%
DWH 1 1/4 = 25% 60%
45. Dell Software Group45
s
Shutting down the
preferred instance
PDB automatically starts
in the other instance
RAC & Multitenant
PDB opened only in
Preferred instance
54. Dell Software Group54
Multitenant & AWR cont’d
AWR reports are available at CDB & PDB levels
DBA_HIST_* views are visible at PDB level
Unplug PDB does not contain AWR information
s
Data available in PDB via object-link
to the CDB$ROOT container
56. Dell Software Group56
Summary
Multitenant architecture can simplify Database consolidation
Cloud deployments (DBaaS) - Great use case for Multitenant
Non-CDB deprecation -> Faster Multitenant adoption period
Monitor PDBs workload distribution over time
Overcome QoS challenges with Services & DBRM
57. Dell Software Group57
References
57
Introduction to the Multitenant Architecture (Oracle Documentation)
https://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm#CNCPT89234
Managing Resources with Resource Manager (Oracle Documentation)
https://docs.oracle.com/database/121/ADMIN/dbrm.htm#ADMIN027
DBMS_RESOURCE_MANAGER (Oracle Documentation)
https://docs.oracle.com/database/121/ARPLS/d_resmgr.htm#ARPLS050
Introduction to a Multitenant Environment (Video by Tom Kyte)
https://www.youtube.com/watch?v=2MrouEW9j88
Oracle Multitenant (White Paper)
http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf
Note: All diagrams and illustrations are used by permission of Oracle
We will start this session by reviewing common database consolidation approaches in earlier versions, and then we will see what Oracle 12c multitenant is and how it can simplify consolidation challenges. The next topics will be more advanced and they will cover how to ensure QoS in Multitenant environments using Resource Manager, and specific things to take into account with RAC, Data Guard and Multitenant. We will end the session with some few tips on how to monitor your 12c Multitenant environments. We will also have a Q&A session at the end
Database consolidation is a big challenge that many organizations are faced with. There are various popular approaches for database consolidation in the pre 12c era
A common approach in the past was to take different databases from different machines, and consolidate them into one machine. In this example we can see separate 3 machines with a single database on each. We could have consolidate them into a single machine. This approach allows us to consolidate servers which is good from IT resources management, but we didn’t consolidate databases. We would still have to manage different databases. 3 different databases to backup, 3 different databases to upgrade, 3 databases to monitor, etc.
A better approach would be to consolidate many different databases into a single database, where each database has its own schema for example. Now, we need to manage only one Oracle Database.
The problem with this approach is that there are several challenges when doing database consolidation, let’s review some of them.
Now, let’s review the Oracle 12c Multitenant Architecture and see how it simplifies Database Consolidation.
In the past, you could configure either a single instance or RAC, but in both cases there was only one database, so there was 1:1 relationship between database to instance in case of a single instance, but 1:N relationship between database to instance in case of RAC. In Oracle 12c with the multitenant option you can have many different pluggable databases in a single instance environment or a RAC environment
In a multitenant architecture, these is one instance with many pluggable databases. Each Pluggable Database is a self-contained, independent Database with its own schemas, data, etc. Pluggable Database is a “regular” Database from the application standpoint. In addition, there is one root container which stores Oracle-metadata that is shared across all the PDBs like PL/SQL packages, for example, the DBMS_SYSTEM package. All the PDBs can be plugged into the root container.
Redo logs are shared in a container database, you don’t need to create a separate Data Guard environment for each PDB
One Standby DB where all the PDBs are replicated to
One Data Guard Configuration means simplified maintenance which reduces the administrative efforts
The side effect of this architecture is that the granularity of the switchover and failover operations is at CDB level, meaning that all the PDBs in a CDB will have the same role of their CDB: all primary or all stand-by. From a consolidation perspective is important to choose which PDBs need to be consolidated on which CDBs so that you can preserve some flexibility for the most critical PDBs.
Some parameter are modifiable at CDB level and some at PDB level.
CDB-Level example:
SGA_TARGET
UNDO_RETENTION and UNDO_TABLESPACE
PDB-LEVEL example:
STATISTICS_LEVEL
The first reason is that it allows you the to upgrade (for example from 12.1.0.1 - to 12.1.0.2) via unplug/plug, which could be faster than a "full upgrade“ in some cases
++++++
You can clone from a PDB in a single tenant configuration CDB into a different CDB
++++++
As you can see, the Non-CDB architecture is deprecated starting from 12.1.0.2 and in the future it may be desupported, so eventually there will only be one architecture and if you don't pay for the Multitenant option you'll have to run in single tenant configuration in the future, so why not getting used to it now?
Oracle 12c introduced new QoS challenges when it comes to the new Multitenant architecture.
For example, One or more PDBs consume too many resources. Another example is that a single PDB has an inconsistent performance because the other PDBs are competing for system resources at various times
The Resource Plan Specifies how resources are allocated to the different consumer groups by using plan directives.
Consumer group is a collection of user sessions grouped together by a common attribute, such as username, program, service, and so on.
In this example we can see that:
The 1st plan directive allocates 70% of CPU to the WAREHOUSE consumer group
The 2nd plan directive allocates 20% of CPU to the OLTP consumer group
The last plan directive allocates 10% of CPU to all the other sessions
CPU Shares – The proportion of the CPU resources guaranteed to the PDB
CPU Utilization Limit – % of the CDB available CPU that is available for the PDB
Parallel Servers Limit – % of the CDB available parallel servers that are available for the PDB
The first step in creating the Resource plan is to create a Pending Area, which is a temporary work area for Resource Management configuration.
changes in the pending area are not visible until the pending area is submitted.
Click
Now we create the 1st CDB Plan directive which allocates 3 CPU shares, and allows maximum 100% CPU resources to the OLTP pluggable database
Click
The next step is to create the 2nd CDB Plan directive which allocates 1 CPU share, and allows maximum 60% CPU resources to the DWH pluggable database
Click
In the last step we will validate the pending area and submit it
consolidating many pluggable databases on standalone instances has some limitations. First of all, the scalability of the server. once the Oracle CDB Instance fills up the entire host resources, customers need to continue the consolidation on newly created CDBs, on different servers. That CDB cannot be used to consolidate additional pluggable databases.
In addition, it is challenging to ensure availability because every instance downtime means that all the Pluggable Database in that CDB will also not be available. Imagine that you need to change a static parameter, or patch the database, or every other downtime scenario that could be either planned or unplanned, will effectively cause downtime for all PDBs.
+++++
That’s why a true consolidation solution should include both RAC and Multitenant, because with RAC, you can scale out and add additional nodes if you want to consolidate more PDBs into the Container, and in terms of availability, if instance goes does then it will not impact the Pluggable Database availability since it can still be running on the other nodes.
In this example we clone a new pdb named “PDBTEST” from an existing PDB name “PROD”.
++++
As you can see, the pluggable database is MOUNTED across all RAC nodes
++++
Now we create a new Administrator-managed service named “svc_pdbtest” that has instance O121RAC2 as preferred and O121RAC1 as available
If we will start the service, it will automatically open the PDB in the preferred instance
++++
Shutting down the preferred instance will cause the PDB to be started on the available instance.
Whether you plan to use private cloud or public cloud, Oracle can now implement multitenancy in the database, not the application. This handles many critical requirements from your cloud Database when using consolidation such as Data Isolation and Data Security.
![Database Consolidation using the
Oracle Multitenant Architecture
Pini Dibask,
Product Manager, Database Solutions
Dell Software Group
[UGF6588] Sunday, Sep 18th 2016](https://image.slidesharecdn.com/4edf1f9a-9f6d-4929-b3ce-c03dc63d755e-160925144113/85/Database-Consolidation-using-the-Oracle-Multitenant-Architecture-1-320.jpg)
