Consolidation Planning for the Cloud – Part X

We detailed the concept and workings of Consolidation Planning for the Cloud, using Oracle Enterprise Manager Cloud Control 13c, in the previous partsof this article series. This is Part X, the final part in the series.

To recap, in the previous part of the series, we used the Database consolidation Workbench to create a Database to Server (D2S) project, which meant consolidation of databases to a server target such as a “Phantom” Exadata Server. We also performed what-if scenarios for different Exadata models and rack sizes (such as attempting to consolidate onto a smaller sized X5-2 Quarter rack so as not to overshoot the budget). The importance of a SQL Performance Analyzer (SPA) trial for the databases was noted. Without the SPA trial completed for the databases in advance, the impact of the highly specialized Exadata “storage cells” on the I/O requirement of the databases could not be estimated.

Of course, it is not just Exadata – the database consolidation Workbench also allows a generic server to be used as the consolidation target. Another possibility was a Database to Database (D2D) project to consolidate onto an Oracle 12c Container database (CDB), which is a good target for multiple databases due to its multi-tenant architecture. You can use either CDB or non-CDB, a clustered database or single instance, and also specify the number of RAC instances.

When estimating storage requirements for the databases, compression estimates are required which need to be gathered in advance. This can be done by submitting the "Deploy Database Consolidation Workbench Packages" job with SYSDBA credentials on the targets and then collecting compression estimates. Finally, there is also an option to consider consolidating onto the Oracle Public Cloud; but not to other clouds, such as Amazon AWS or Microsoft Azure.

Implementation Phase

We can now move to the Implementation Phase. Since the scenario we created previously was successful, we decide to implement the consolidation.

Figure 1-52. Confidence Level Heat Map for the D2D Scenario.

Click on the “Implement Scenario” button as seen in Figure 1-52. The Implement Scenario screen appears as seen in Figure 1-53.

Figure 1-53. Implement Scenario

Select one of the possible migration methods displayed, “Full Transportable Export and Import”, and click on “Generate Migration Command”. A migration XML is generated along with the Enterprise Manager command line interface (emcli) migration command and instructions, as displayed in Figure 1-54. You can save the generated command and XML, and also download the XML.

Figure 1-54. Generated Migration command/XML for Full Transportable Method

You need to edit the migration XML to provide supplementary information and validate it. When you are ready to migrate the source databases, run the migration command, passing the XML file as its input. When run, the command will submit one or more Enterprise Manager deployment procedures to perform the actual migration. Submitted procedures can be tracked using the Deployment Procedure Manager page (Enterprise | Provisioning and Patching | Procedure Activity).

If you selected the migration method as Data Pump, the following message is displayed after the generation of the migration command, as seen in Figure 1-55.

Figure 1-55. Data Pump Migration Method

The message displayed is Informational and says, “This migration method cannot create pluggable databases (PDB) in multi-tenant (container) database (CDB) destinations. Please create an empty PDB for each source database to be plugged into CDB destinations and update the destination target names in the migration XML.”

As we can see, various modes of migration of the source databases onto the target databases are supported, based on the source and target environments and also on business needs.

For multi-tenant databases being moved to multi-tenant, the option is provided to simply unplug and plug the specific databases being consolidated. For databases on different platforms (endianness), the option is provided to migrate using Data Pump. For database environments requiring zero or minimal downtime, online migration is supported using Oracle Data Guard. This will provision the standby environment on the consolidation environment and then switch over to the standby as the primary, thus minimizing downtime.

Summary

In this article series we have seen the Host Consolidation Planner and Database Consolidation Workbench in action, twin tools available in the latest Enterprise Manager Cloud Control 13c version.  These tools are very useful for planning host and database consolidation onto cloud infrastructure.

The Host Consolidation Planner allows you to select existing source servers and collect actual resource usage data from these servers over a certain number of days, and then use this information to map the source servers to either existing or planned (phantom), physical or virtual destination servers. The Database Consolidation Workbench on the other hand, works with database metric data and AWR data to perform Database to Server or Database to Database consolidation. The twin tools therefore allow you to create server and database consolidation scenarios that are useful for planning purposes.

These two tools can help you to identify under-utilized or over-utilized servers based on the resource usage data collected by Enterprise Manager. You can decide on appropriate candidates for host or database consolidation, satisfy business and technical constraints at the same time, maximize consolidation on the destination targets, and make sure performance on these does not get degraded below a certain level – controlled by the maximum resource usage limits you specified.

In this article series you have also seen the brand-new consolidation “implementation” capabilities of the Database Consolidation process. Building on the consolidation scenarios and analysis performed on the Database Consolidation Workbench, the implementation capability enables the DBA to implement the consolidation plan generated by the Database Consolidation process.

The implementation aspect therefore saves DBAs the manual, error-prone effort of consolidation, since the entire database consolidation implementation process is automated. The different methods of consolidation that are supported enable administrators to select a consolidation method that is specific to their business needs, so that the business does not suffer planned downtime – or possible unplanned downtime due to wrong choices made using the manual consolidation process. Besides, the ability to execute the consolidation process in parallel and in an automated fashion means that the business can realize consolidation savings faster and remove legacy hardware or software versions, enabling a quicker reduction of operating costs.

Note, too, that the Real Application Testing (RAT) option offers the “Database Replay” capability, which allows you to capture a production database’s concurrent workload and replay it on a test database system.  You can then find out if the SQL has improved in performance or has regressed. This option has been enhanced (since May 2012) to support “Consolidated Database Replay". This allows two or more captured production database workloads from the same or different systems to be replayed concurrently on a single test database. This Consolidated Database Replay functionality can be used to further validate the consolidation strategy recommended by the twin consolidation tools in Enterprise Manager Cloud Control 13c.

In short, the Host Consolidation Planner and Database Consolidation Workbench are a welcome and useful addition to the Enterprise Manager arsenal.

This article series on consolidation planning using Enterprise Manager Cloud Control 13c, is now completed. 

(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.)