We started to detail the concept and workings of Consolidation Planning for the Cloud, using Oracle Enterprise Manager Cloud Control 13c, in the previous parts of this article series. This is Part IX.
To recap, in the previous part of the series, we saw the Database Consolidation workbench in action. First, we created a Database to Server (D2S) database consolidation project for consolidating existing databases to a new server, such as an Exadata engineered system.
We noted that the second possibility for such a project was Database to Database (D2D), where you would consolidate existing databases onto an Oracle database such as a 12c Multi-tenant database. And the third possibility for the database consolidation project was for consolidation of your databases onto the Oracle Public Cloud. This last is available as a “Phantom” destination option, when creating a scenario for a Database to Server or Database to Database project.
As a pre-configured scenario for the first Database to Server (D2S) database consolidation project, we used new “Phantom” Exadata database machines. We created a what-if scenario for the D2S project – where we used an X5-2 Quarter rack to see if our databases (being consolidated) could work efficiently on this smaller-sized Exadata machine, and their loads would fit: a good way to control your company budget and make sure there is no overspend on larger Exadata machines.
We progressed, entering the details of this scenario up to the Destinations Planning screen, which is the spot where you can plan your New (Phantom) server to be either Oracle Exadata, or Oracle Compute Cloud, or a Generic Server.
This means that the Oracle Public Cloud can be used in the consolidation planning process if so required. Other clouds cannot be considered as consolidation targets using this tool, since only the specifications of Oracle Public Database cloud database servers are presented as selection options in the scenario process.
In the next and final Destination Mapping screen as seen in Figure 1-44, we retain the default of Automatic Mapping.
Figure 1-44. Destination Mapping
When the what-if scenario for consolidating our list of databases on to the X5-2 Quarter rack is finally submitted, wait for it to run to completion. After that happens, the Mapping tab of the scenario can be examined as shown in Figure 1-45.
We can see that the source databases that are being consolidated have all been distributed across the two nodes of the RAC database in the Exadata Database Machine. The utilization seems to be reasonable (green in color) as seen in the Mapping tab.
Figure 1-45. Mapping Tab of the D2S Scenario
However, moving to the Storage tab, we see three Storage requirement exclusions as displayed in Figure 1-46.
Figure 1-46. Storage Tab of the D2S Scenario
Click on the Exclusions to display them in detail. They appear in Figure 1-47 below.
Figure 1-47. Storage Requirement Exclusions
Here, we can see, because no SQL Performance Analyzer (SPA) trial had been completed for two of the databases, and the compression estimates were not gathered for the same two databases, that these exclusions have appeared. The other factor is that space data for the other database was not available due to metric data not having been collected on the target.
Note that in order to estimate compressed storage requirements, you will need to submit the “Deploy Database Consolidation Workbench Packages” job with SYSDBA credentials on such targets to run compression advice and collect estimates before creating scenarios.
This shows that the database consolidation advisor uses the information gathered by the SPA trials. You can now gather this information and create a new what-if scenario for the project.
Creating a Database to Database (D2D) Project and Scenario
We now create a new Database to Database (D2D) Project, as shown in Figure 1-48.
Figure 1-48. Creating a D2D Project
As the Source Candidates, we select an 11g database and a 12c non-CDB database. As the destination, we select a 12c CDB database. Our intention is to consolidate the former databases onto the CDB. We do not select any pre-configured scenarios, but go ahead and complete the project.
Next, we create a scenario for the D2D project. This is shown in Figure 1-49.
Figure 1-49. Creating a Scenario for the D2D project.
Using the scale factor of 1 for both CPU and memory, and a Resource Allocation type of Conservative, we go ahead and click on “Estimate Requirements” to get the estimates. Then, we click on Next.
In the Destinations Planning Screen (Figure 1-50), we do not use the Phantom servers this time, but the existing Oracle 12c CDB database “ahuprod.sainath.com”.
Figure 1-50. Destination Planning for the D2D Scenario using an Existing CDB.
If we had selected “Use New (Phantom) Database on New (phantom) servers”, as seen in Figure 1-51, different options are visible.
Figure 1-51. Destination Planning for the D2D Scenario using a Phantom CDB
We could have selected a CDB or non-CDB, a clustered database or single instance, the number of RAC instances, and whether the server was on Oracle Exadata, the Oracle Compute Cloud, or a Generic server. If we select the Oracle Compute Cloud, we can select the configuration of the server. In this case we have selected an OC7 compute shape.
Coming back to the existing CDB, we select OLTP compression, and move ahead to complete the scenario. The scenario completes its analysis, and we can see the confidence level is 100% (Figure 1-52). You can view the confidence as a Heat Map, the colours also show the low level of utilization.
Figure 1-52. Confidence Level Heat Map for the D2D Scenario.
In this installation of our consolidation planning article series, we saw the Database Consolidation workbench in action, completing the what-if Scenario for consolidation of our source databases onto an X5-2 Quarter rack. We also created a Database to Database (D2D) Project and Scenario for consolidating the source databases onto an existing Oracle 12c CDB database.
We can see that Oracle Enterprise Manager Cloud Control 13c offers a truly scientific and automated method of examining what-if scenarios for database consolidation based on database workload, and the consolidation can be database-to-server for Exadata, database-to-database such as to Oracle 12c container databases (CDBs), or database to Oracle Public cloud.
We will continue this article series in Part X, where we will look at the Implement Phase. This is useful in case the scenario is successful, and you decide to implement the suggested consolidation. Oracle Enterprise Manager Cloud Control 13c and its Management Packs will be able to achieve this. Part X is here.
(This article is a modified excerpt from Chapter I of the new book by the author titled “Oracle Database Cloud Cookbook with Oracle Enterprise Manager 13c Cloud Control” published by Oracle Press in August 2016. For more information on the book, see here.)
Start the discussion at forums.toadworld.com