OUGN winning performnace challenges in oracle Multitenant

Editor's Notes

• #3: 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.
• #4: 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.
• #5: 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.
• #7: 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.
• #8: 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.
• #9: 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.
• #10: 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.
• #12: 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.
• #13: 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
• #17: 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.
• #21: 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
• #22: 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
• #23: 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
• #24: 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
• #25: 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
• #26: 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
• #27: 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
• #28: 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
• #29: 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
• #30: 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
• #31: We’ve covered CPU level resource management – now let’s see how we can manage to address memory resource management challenges
• #32: 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.
• #33: 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.
• #34: 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.
• #40: Now we create a new Administrator-managed service named “svc_pdbtest” that has instance O121RAC2 as preferred and O121RAC1 as available
• #42: 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.
• #43: 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.
• #44: 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
• #45: 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.
• #46: 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.
• #47: 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.