Oracle Database Multitenant is a great solution for simplifying Database Consolidation, but it also introduced new quality of service challenges. In this article we will review the following items: Introduction to Oracle Multitenant Quality of Service Challenges in Oracle Database How to overcome Quality of Service challenges in Oracle Multitenant Summary Introduction to Oracle Multitenant Database Consolidation is a big challenge that many organizations are faced with. Before Oracle 12c there were several approaches for implementing Database consolidation such as server consolidation - i.e. taking different databases from different servers and consolidating them into one single box (either virtual of physical). The problem with this approach is that it still leaves the DBAs with several different databases to manage (back up, upgrade, monitor, etc). Another approach is to consolidate several databases into one single database where each application has its own schema or set of schemas - now, we need to manage only one Oracle Database. The problem with this approach is that there are several challenges when doing database consolidation that is based on different schemas for different applications, let’s review some of them. Name Collisions - Public synonyms and schema names must be unique in a Database, so having identical schema names or public synonyms across different databases will make the consolidation more complicated. Security - When consolidating different Database into one Database, a user with strong permissions ("SELECT ANY TABLE" system privilege, "DBA" role, etc.) can view data of all the schemas in the Database, and perhaps you don't want to DBA of one specific application will be able to access data of all the other applications. Upgrades - You cannot perform schema-level upgrade. You can only upgrade the entire Database, but perhaps other applications (other schemas) are not ready for the upgrade. Point In-Time Recovery - Imagine that a user truncated a table in a specific schema - in this case, it is not possible to use the FLASHBACK TABLE feature or FLASHBACK DROP so we may consider performing point in-time recovery, but the problem here is that we cannot use RMAN or user-managed backup to perform a point in-time recovery to a specific schema, we can only perform point in-time recovery to the entire Database. As you can see, in the past there were several challenges when consolidating multiple applications into a single Database. Now let's see what Oracle Multitenant is and how it can solve these challenges. In the past, DBAs could configure either a single instance or RAC, but in both cases there was only one database, so there was 1:1 relationship (one instance, one database) between database to instance in case of a single instance, and 1:N relationship (many instances, one database) between database to instances in case of RAC. In Oracle 12c with the Multitenant option you can have many different pluggable databases ("PDBs") in a single instance environment or a RAC environment. Each PDB 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 resides only in the root container. All the PDBs can be plugged into the root container. All the PDBs together with the root container are grouped together to a single logical entity named Container Database ("CDB"). The big advantage of Oracle Multitenant architecture is that now DBAs can manage all of the Pluggable Databases as one - for example, it is possible to backup the entire CDB (with all its PDBs) in a single operation, or creating a Data Guard environment for the entire CDB with all its PDBs at once, which makes DBAs life much easier . In addition, since PDBs are separate entities, this architecture offers database security and isolation so instead of implementing multitenancy at the application-level, Oracle will provide a multitenancy at the Database-level. Quality of Service Challenges in Oracle Database A common quality of service challenge in Oracle Database is to ensure performance stability among competing sessions in the Database. For example, a single user may consume too many resources. In some environments, specific users may have a low priority compared to other users. The solution that DBAs use in order to prioritize sessions is Oracle Database Resource Manager ("DBRM"). DBRM is a tool that comes as part of Oracle Database Enterprise Edition and it allows to limit resources (such as CPU, Degree of Palarllelism, and more) among competing sessions. Oracle Database Resource Manager works by creating a Resource Plan which specifies how resources are allocated to the different consumer groups by using plan directives.Consumer Group is a collection of sessions grouped together by a common attribute, such as DB user name, OS user name, client program, database service, and more. Figure 1 shows a resource plan named "WEEKEND" which runs during the weekend (as its name implies). This resource plan has 3 resource plan directives: The first plan directive allocates 70% of CPU to the WAREHOUSE consumer group (sessions which belong to the "WAREHOUSE" username). The second plan directive allocates 20% of CPU to the "OLTP" consumer group (sessions which belong to the "OLTP" username). The third plan directive allocated 10% of CPU to all the other sessions. Figure 1 : Example of a basic DBRM Resource Plan How to Overcome Quality of Service Challenges in Oracle Multitenant Oracle 12c introduced new QoS challenges when it comes to Multitenant architecture. For example, One or more PDBs that have a relatively low priority in the CDB consume too many resources. Another QoS challenge is that a specific PDB has an inconsistent performance because the other PDBs are competing for system resources at various times - for example, during daytime the "DWH" . Oracle Database Resource Manager has been enhanced in Oracle 12c to support Oracle Multitenant by allowing create a CDB-Level resource plan which consists of the following CDB Resource Plan Directives: CPU Shares - Represents the amount of CPU resources that are guaranteed to the PDB. Higher value for a specific PDB means that it has more CPU resources guaranteed than other PDBs which have lower values. CPU Utilization Limit - Percent of maximum utilization limit that a PDB can use out of the entire CDB CPU resources. Parallel Servers Limit - Percent of maximum parallel servers limit that a PDB can use out of the entire CDB parallel servers. Figure 2 shows a CDB-level resource plan named "Daytime_CDB_PLAN" which runs during daytime (as its name implies). This CDB Resource plan has 2 resource plan directives: The first plan directive allocates 3 CPU shares to the OLTP PDB and a maximum CPU utilization of 100% out of the entire CDB CPU resources. The second plan directive allocated 1 CPU share to the DWH PDB and a maximum CPU utilization of 60% out of the entire CDB CPU resources. Since the OLTP PDB has 3 CPU shares and DWH PDB has 1 CPU share that are 4 CPU shares total in the CDB; therefore, OLTP PDB has 3/4 (75%) CPU resources guaranteed and DWH PDB has 1/4 (25%) CPU resources guaranteed. Figure 2 : Example of CDB Resource Plan Please note that by default all PDBs have 1 CPU share and no CPU utilization limit (i.e. utilization_limit=100) so without creating a CDB-level resource plan, PDBs will not be prioritized and therefore, a low-priority PDB might consume more resources then it should. Here is a code example that shows how to implement the above CDB resource plan: DECLARE l_plan VARCHAR2(30) := 'DAYTIME_CDB_PLAN'; BEGIN DBMS_RESOURCE_MANAGER.clear_pending_area; DBMS_RESOURCE_MANAGER.create_pending_area; DBMS_RESOURCE_MANAGER.create_cdb_plan( plan => daytime_plan, comment => 'A daytime CDB resource plan'); DBMS_RESOURCE_MANAGER.create_cdb_plan_directive( plan => daytime_plan, pluggable_database => 'OLTP', shares => 3, utilization_limit => 100, parallel_server_limit => 100); DBMS_RESOURCE_MANAGER.create_cdb_plan_directive( plan => daytime_plan, pluggable_database => 'DWH', shares => 1, utilization_limit => 60, parallel_server_limit => 100); DBMS_RESOURCE_MANAGER.validate_pending_area; DBMS_RESOURCE_MANAGER.submit_pending_area; END; / Here is an explanation of the above PL/SQL block: In the first step we've created a pending area which is a temporary work area for DBRM configuration. All the changes in the pending area will only be visible after the pending is area will be submitted. The next step is to create the 2 CDB plan directives (first one for the OLTP PDB and the second one for the DWH PDB) The last step would be to validate the pending changes and then committing the changes (if valid). Once the CDB Resource Plan is created, you can enable it by setting the RESOURCE_MANAGER_PLAN as follows: ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME_CDB_PLAN'; It is also possible to disable the CDB Resource Plan by setting the RESOURCE_MANAGER_PLAN to be NULL as follows: ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = ''; In order to enable the resource manager plan automatically in specific time schedules, you can leverage the Oracle Scheduler Windows feature. Here is a code example thatshows how to create a scheduler windows that enables the "Daytime_CDB_PLAN" every day starting from 08:00 until 18:00: BEGIN DBMS_SCHEDULER.create_window ( window_name => 'SATURDAY_WINDOW', resource_plan => 'DAYTIME_CDB_PLAN', start_date => '16-OCT-20 8.00.00AM US/Pacific', repeat_interval => 'FREQ=DAILY', duration => INTERVAL '10' HOUR, comments => 'Daytime window for CDB Resource Plan'); END; / Summary Oracle 12c Multitenant introduces a new paradigm and a significant architectural change of the Database compared to previous releases. It is a great solution for implementing Database Consolidation. Having said that, it is important to keep in mind which quality of service challenges DBAs might be faced with and how to address those challenges using Oracle Database Resource Manager.
↧
