Database Consolidation using the Oracle Multitenant Architecture

Editor's Notes

• #5: 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
• #6: 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
• #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.
• #10: Now, let’s review the Oracle 12c Multitenant Architecture and see how it simplifies Database Consolidation.
• #11: 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.
• #14: 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.
• #20: 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
• #27: 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?
• #30: 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
• #32: 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
• #33: 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
• #36: 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
• #41: 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.
• #45: 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
• #46: 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.
• #57: 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.