What Are The Drone Anti-jamming Systems Technology?
OUGN winning performnace challenges in oracle Multitenant
1. Winning Performance Challenges in
Oracle 12c Multitenant
Pini Dibask, Product Manager for Database Solutions
March 9th, 2017
2. Confidential2
• Pini Dibask, Product Manager, Database Solutions (Quest)
• Oracle DBA since 2006
• Oracle Certified Professional DBA (OCP)
• My Blog: OracleDBPro.BlogSpot.com
Pini.Dibask@Quest.com
http://Linkedin.com/in/pinidibask
@pini_dibask
About Me
3. Confidential3
About
• Quest is now an independent company again!
• #1 independent software company for Database Tools
• Driven by innovation
“Spend less time on what you need to do, and more time on what you want to do!”
• Committed to providing great products and superior support
4. Confidential4
Agenda
• Introduction to Oracle Multitenant
• Ensuring QoS in Multitenant Environments
• RAC and Multitenant
• Performance Monitoring for Multitenant Environments
8. Confidential8
Database Consolidation with Schema Separation - Challenges
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
10. Confidential10
Oracle 12c – Multitenant Architecture
One SGA
One set of background processes
One root container
Multiple pluggable databases
Up to 252 PDBs (12cR1)
Up to 4096 PDBs (12cR2)
11. Confidential11
Oracle 12c – Multitenant Architecture (Cont’d)
Pluggable Databases share the following files:
Undo Tablespace (optional)
Redo Logs
Control Files
(S)Pfile
Local undo
introduced in
12cR2
12. Confidential12
CDB Level vs. PDB-Level
CDB-Level
• Oracle Software
• SGA & Background Processes
• Data Guard
• Some Parameters
(IsPDB_Modifiable= 'FALSE')
• Control Files, Redo
• (S)Pfile, Password File
PDB-Level
• FLUSH SHARED_POOL
• FLUSH BUFFER_CACHE
• RMAN Backups/Restores
• Some Parameters
(IsPDB_Modifiable= 'TRUE')
• Undo Tablespace (12cR2)
• Character Set (12cR2)
• Flashback Database (12cR2)
14. Confidential14
Multitenant Advantages - Fast Cloning
Clone PDB from another PDB within the same CDB
Requires source PDB to be open read only (12cR1)
s
Hot Clone is
available in
12cR2
15. Confidential15
Multitenant Advantages - Fast Cloning (Cont’d)
Clone PDB from another PDB in remote CDB
Requires source PDB to be OPEN READ ONLY (12cR1)
Hot Clone is
available in
12cR2
s
16. Confidential16
Multitenant Advantages - Easy Replication (12c Release 2)
Refreshable PDB – Allows manually/automatically refreshing
contents of a remotely cloned PDB
s
18. Confidential18
Oracle 12c – Deployment Options
Why use Single Tenant instead of Non-CDB?
Unplug/Plug
Fast Cloning
but most importantly …
(source: Oracle 12c Release 2 Documentation)
20. Confidential20
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
21. Confidential21
Oracle Resource Manager - The Basics (Pre 12c)
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”
22. Confidential22
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
23. Confidential23
Oracle Resource Manager - 12c Multitenant
CDB Resource Plan Directive
CPU Shares
CPU Utilization Limit
Parallel Servers Limit
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%
24. Confidential24
Oracle Resource Manager - 12c Multitenant
Obtain information about default CDB resource plan
Obtain information about default PDB directive
s
s
25. Confidential25
Example of CDB-Level Resource Plan
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%
30. Confidential30
PDB Level Memory Resource Management
Not available in 12c Release 1
12c Release 2 - Memory parameters can be set at PDB level
SGA_TARGET
DB_CACHE_SIZE
DB_SHARED_POOL_SIZE
PGA_AGGREGATE_LIMIT
PGA_AGGREGATE_TARGET
SGA_MIN_SIZE
New in 12c
Release 2
31. Confidential31
PDB Level I/O Resource Management
Not available in 12c Release 1
12c Release 2 Introduced the following new parameters:
MAX_IOPS - limits number of I/O operations per second
MAX_MBPS - limits megabytes for I/O operations per second
Default : 0 (no limit)
If Oracle waits due to I/O limit “resmgr: I/O rate limit” wait event will appear
Cannot be set in a Non CDB
32. Confidential32
How Many Resources Actually Being Used by PDBs?
Option #1 - DBA_HIST_RSRC_PDB_METRIC
Displays historical resource manager metrics by PDB
Option #2 - AWR_ROOT_RSRC_PDB_METRIC (underlying AWR table)
Option #3 - AWR Reports
33. Confidential33
Maintenance Tasks in Oracle Multitenant
ENABLE_AUTOMATIC_MAINTENANCE_PDB parameter
Can be used to enable/disable running of maintenance tasks
Default: true
Can be set at either CDB or PDB levels
AUTOTASK_MAX_ACTIVE_PDBS parameter
Maximum number of PDBs that can schedule maintenance tasks concurrently
Default: 2 (two PDBs and the CDB root can run tasks at the same time)
Can be set at CDB level only
Both parameters introduced in 12c Release 2
43. Confidential43
AWR reports are available only at CDB level
AWR Management Operations only at CDB level
AWR data retention
Snapshot schedule
Taking manual snapshots
Purging snapshot data
Unplugged PDB does not contain AWR information
Multitenant & AWR – Oracle 12c Release 1 (Cont’d)
45. Confidential45
Multitenant & AWR – Oracle 12c Release 2
Snapshots can be taken either at CDB or PDB level
Snapshot data reside in SYSAUX tablespace of each PDB
It is possible to create a report at PDB-level AWR report
AWR management operations at either CDB or PDB level
New Parameter : AWR_PDB_AUTOFLUSH_ENABLED
Specifies whether to enable automatic AWR snapshots for PDBs
Default : false (automatic AWR snapshots are disabled for PDBs)
Can be set at CDB or PDB level
51. Confidential51
References
Introduction to the Multitenant: Architecture (Documentation)
http://docs.oracle.com/database/122/CNCPT/introduction-to-the-multitenant-architecture.htm#CNCPT89234
Oracle Multitenant (White Paper)
http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf
Oracle Multitenant: New Features in Oracle Database 12c Release 12 (White Paper)
http://www.oracle.com/technetwork/database/multitenant/overview/multitenant-wp-12c-2078248.pdf
Note: All diagrams and illustrations are used by permission of Oracle
Me, I’ve been an Oracle DBA since 2006, during these years I worked a DBA and DBA team leader and as mentioned currently I work as a Product Manager for Database Solutions at Quest. I’m based in Israel Tel Aviv where we have a development group for some of our Database monitoring solutions including Foglight and Spotlight that some of you are probably familiar with. I’m an Oracle Certified Professional. You can see here my blog where I write about my experience of working with Oracle Databases. You can also find below my email, LinkedIn and twitter addresses so if you’d like to contact me you’d be more than welcome.
I assume that you probably all familiar with Quest, the company which develops some of the most popular Database tools in the industry like Toad. Quest was actually acquired by Dell a few years ago but now – actually 2 weeks ago Quest became an independent software company again so we are very excited about that. The new quest is driven by innovation probably more than ever before and focused on analytics, and SaaS solutions. Our goal is basically make DBAs spend less time on what they need to do and more time on what the want to do. Quest is committed to providing great products and superior support. So that’s about all on myself and Quest – let’s move on to the agenda for today’s session.
I assume that you probably all familiar with Quest, the company which develops some of the most popular Database tools in the industry like Toad. Quest was actually acquired by Dell a few years ago but now – actually 2 weeks ago Quest became an independent software company again so we are very excited about that. The new quest is driven by innovation probably more than ever before and focused on analytics, and SaaS solutions. Our goal is basically make DBAs spend less time on what they need to do and more time on what the want to do. Quest is committed to providing great products and superior support. So that’s about all on myself and Quest – let’s move on to the agenda for today’s session.
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.
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.
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.
You can configure a CDB to use local undo in every container or to use shared undo for the entire CDB.
A CDB can run in local undo mode or shared undo mode. You can specify the undo mode of a CDB during CDB creation in the ENABLE PLUGGABLE DATABASE clause of the CREATE DATABASEstatement. You can change the undo mode of a CDB after it is created by issuing an ALTER DATABASE statement and restarting the CDB. The undo mode applies to the entire CDB. Therefore, every container either uses shared undo or local undo.
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
This new feature allows to have a cloned PDB that can be refreshed from another PDB either manually (on-demand) or automatically (scheduled refresh). The way this works is by creating a full clone at first stage (which can be taken with no downtime now with the new 12cR2 hot clone feature), and then there is no need to perform a full clone again because this feature allows applying incremental redo since the last clone or the last refresh time. This could be very useful in scenarios that the source PDB is very large and we would like to avoid creating a full clone to the entire PDB from scratch every time, because this process takes a long time when the PDB is very large. By having to apply only the incremental redo since last refresh or last clone, the process of having up to date cloned PDB for dev/test purposes becomes much faster and easier.
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
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
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 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
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
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
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
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
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
We’ve covered CPU level resource management – now let’s see how we can manage to address memory resource management challenges
A large amount of disk I/O can cause poor performance. Several factors can result in excess disk I/O, such as poorly designed SQL or index and table scans in high-volume transactions. If one PDB is generating a large amount of disk I/O, then it can degrade the performance of other PDBs in the same CDB.
DBWR I/Os, control file I/Os, password file I/Os and other critical I/Os are exempted from the rate limit set by these parameters, but their I/Os are accounted for while throttling. Because of these exemptions, the PDB's actual I/O rate may sometimes exceed the limit.
Use one or both of the following initialization parameters to limit the I/O generated by a particular PDB:
The MAX_IOPS initialization parameter limits the number of I/O operations for each second.
The MAX_MBPS initialization parameter limits the megabytes for I/O operations for each second.
Both limits are enforced if you set both initialization parameters for a single PDB.
If these initialization parameters are set with the CDB root as the current container, then the values become the default values for all of the containers in the CDB. If they are set with an application root as the current container, then the values become the default values for all of the application PDBs in the application container. When they are set with a PDB or application PDB as the current container, then the settings take precedence over the default settings in the CDB root or the application root. These parameters cannot be set in a non-CDB.
The default for both of these initialization parameters is 0 (zero). If these initialization parameters are set to 0 (zero) in a PDB, and the CDB root is set to 0, then there is no I/O limit for the PDB. If these initialization parameters are set to 0 (zero) in an application PDB, and its application root is set to 0, then there is no I/O limit for the application PDB.
Critical I/O operations, such as ones for the control file and password file are exempted from the limit and continue to run even if the limit is reached. However, all I/O operations, including critical I/O operations, are counted when the number of I/O operations and the megabytes for I/O operations are calculated.
We’ve covered to define various resource limits to pluggable databases such as memory, cpu, and disk I/O limits.
One question you may ask is how would you even know how many resources are actually being used today in order to define limits?
DBA_HIST_RSRC_PDB_METRIC displays information about historical Resource Manager metrics for the past hour by PDB.
Automated maintenance tasks are tasks that are started automatically at regular intervals to perform maintenance operations on the database. An example is a task that gathers statistics on schema objects for the query optimizer.
Automated maintenance tasks run in maintenance windows, which are predefined time intervals that are intended to occur during a period of low system load. You can customize maintenance windows based on the resource usage patterns of your database, or disable certain default windows from running. You can also create your own maintenance windows.
Oracle Database has these predefined automated maintenance tasks:
Automatic Optimizer Statistics Collection—Collects optimizer statistics for all schema objects in the database for which there are no statistics or only stale statistics. The statistics gathered by this task are used by the SQL query optimizer to improve the performance of SQL execution.
Optimizer Statistics Advisor—Analyzes how statistics are being gathered and suggests changes that can be made to fine tune statistics collection.
Automatic Segment Advisor— Identifies segments that have space available for reclamation, and makes recommendations on how to defragment those segments.
You can also run the Segment Advisor manually to obtain more up-to-the-minute recommendations or to obtain recommendations on segments that the Automatic Segment Advisor did not examine for possible space reclamation.
Automatic SQL Tuning Advisor—Examines the performance of high-load SQL statements, and makes recommendations on how to tune those statements. You can configure this advisor to automatically implement SQL profile recommendations.
Now we create a new Administrator-managed service named “svc_pdbtest” that has instance O121RAC2 as preferred and O121RAC1 as available
In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment.
+++++++
In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment.
+++++++
In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
Here you can see the implications of the way AWR works in Oracle 12cR1
AWR Management Operations only at CDB level
AWR data retention
Snapshot schedule
Taking manual snapshots
Purging snapshot data
In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment.
+++++++
In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
The default value of AWR_PDB_AUTOFLUSH_ENABLED is false. Thus, by default, automatic AWR snapshots are disabled for all the PDBs in a CDB.
When you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root, the new value takes effect in all the PDBs in the CDB.
Therefore, if you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root to true, the value of AWR_PDB_AUTOFLUSH_ENABLED is also changed to true in all of the PDBs, so that automatic AWR snapshots are enabled for all the PDBs.
You can also change the value of AWR_PDB_AUTOFLUSH_ENABLED in any of the individual PDBs in a CDB, and the value that is set for each individual PDB will be honored. This enables you to enable or disable automatic AWR snapshots for individual PDBs.
When a new PDB is created, or a PDB from a previous database release is upgraded to the current database release, automatic AWR snapshots are enabled or disabled for the PDB based on the current value of AWR_PDB_AUTOFLUSH_ENABLED in the root.
The default value of AWR_PDB_AUTOFLUSH_ENABLED is false. Thus, by default, automatic AWR snapshots are disabled for all the PDBs in a CDB.
When you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root, the new value takes effect in all the PDBs in the CDB.
Therefore, if you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root to true, the value of AWR_PDB_AUTOFLUSH_ENABLED is also changed to true in all of the PDBs, so that automatic AWR snapshots are enabled for all the PDBs.
You can also change the value of AWR_PDB_AUTOFLUSH_ENABLED in any of the individual PDBs in a CDB, and the value that is set for each individual PDB will be honored. This enables you to enable or disable automatic AWR snapshots for individual PDBs.
When a new PDB is created, or a PDB from a previous database release is upgraded to the current database release, automatic AWR snapshots are enabled or disabled for the PDB based on the current value of AWR_PDB_AUTOFLUSH_ENABLED in the root.