Over the years, the typical enterprise data center will grow steadily due to the addition of servers required to satisfy the needs of the business. This growth typically results in excess servers that occupy rack space, consume a lot of power for cooling, and require system maintenance such as security and patching.

Depending on the procurement cycle or the specific hardware vendor agreement in effect, enterprises may acquire different types of server hardware and operating systems, inadvertently creating a confusing array of systems that administrators need to manage, administer, patch and upgrade. This in turn increases labor and ongoing maintenance and support costs against IT budgets. Enterprises look at consolidation as a way to migrate their disparate systems onto standardized operating systems and hardware, with the ultimate goal of reducing costs.

Enterprises also are increasingly investigating virtualization technologies such as Oracle Virtual Machine by moving from physical to virtual servers. This makes it possible to use the shared hardware infrastructure while getting the benefits of isolation that virtualization provides.

The goal of consolidation is to identify such under-utilized servers and find a way to consolidate them, enabling the enterprise to free up as many servers as possible while continuing to maintain service levels. Since servers have different levels of CPU capacity, Host Consolidation Planner uses computer benchmark data to normalize the CPU usage for a given hardware in the consolidation process. Specifically, Host Consolidation Planner uses the following CPU benchmarks for different classes of hardware:

• SPECint®_base_rate2006 for database hosts, application hosts, or mixed-workload hosts

• SPECjbb®2005 for middleware platforms

Host Consolidation Planner enables you to match managed target sources you want to consolidate with new or existing target destinations. Consolidate source servers to generic physical machines, Oracle engineered systems (Exadata Database Machines or Exalogic Elastic Cloud systems), or Oracle Virtual Machine (VM) servers.

You can also consolidate source servers to physical machines configured in the Oracle Cloud. In a consolidation of this type, an Oracle Cloud Compute configuration mimics a host, except that only memory and CPU capacity are of consequence as resources to be considered.

By leveraging metric and configuration data collected from managed target servers by Enterprise Manager Cloud Control, Host Consolidation Planner helps you determine the optimum consolidation scenarios that also reflect business and technical constraints in the consolidation process.

You create a host consolidation project for each consolidation effort, then add individual consolidation scenarios within it. You can then compare consolidation scenarios to determine which consolidation strategy makes the most sense.

After the project is defined, a Cloud Control job is submitted to collect available data for the specified targets from the Management Repository. Once the job finishes, the project becomes an active project. As long as the project is in an active state, data collection will continue.

Creating a project involves the following steps:

• Selecting the Host Consolidation Project Type

• Specifying Host Source Candidates

• Specifying Host Destination Candidates

• Setting Data Collection Parameters

• Choosing a Pre-configured Scenario

• Reviewing and Saving the Host Consolidation Project

You can create custom host consolidation scenarios instead of or in addition to using the pre-configured scenarios. Multiple scenarios can be created within a project, enabling you to compare different scenarios before deciding on a solution. New consolidation scenarios are created within an existing consolidation project. You can create host consolidation scenarios for planning purposes only.

Creating a scenario involves the following steps:

• Setting Up the Scenario

• Defining Constraints for Host Consolidation

• Planning the Destination for a Physical Server to Virtual Server Project

• Planning the Destination for a Physical Server to Physical Server Project

• Mapping Host Sources to Destinations

• Reviewing and Saving the Host Consolidation Scenario

1. On the Host Consolidation Planner home page, select Create Scenario from Template from the Actions menu.
2. Browse to a saved template XML file in the local file system. Click Open.
3. Indicate the extent to which you want to replicate the saved template; that is, in terms of the resources, constraints, and destinations planning represented by the template. Click Update if you make any changes.
4. Click OK to import the saved template.

   The imported scenario opens in the wizard where you can edit and save it in Host Consolidation Planner.

1. From the Enterprise menu, select Consolidation, then select Host Consolidation Planner.
2. First, examine the project containing the scenario you want to view.

   • The Status column indicates the status of data collection, based on the minimum and maximum collection days specified for the project.

   • The General tab summarizes the project in terms of type, collection details, number of sources, and so forth.

   • Click the Source Candidates tab to view various usage data collected for the sources defined in the project. Data can include utilization rates for CPU, memory, storage, and disk and network I/O, depending on the project type.

   • Click the Source Workload tab to view source resource usage data collected. The default display is a heat map, a grid of 24 hours by 30 days, showing the workload for a given hour as a color indicating the load relative to 100% of capacity, and a number showing the actual percentage. Alternatively, you can view the same data as a line graph. You can filter either view by source, resource type, and month.

   • Click the Destination Candidates tab to view a breakdown of hardware details and projected resource utilization by destination candidate, based on the sources to be consolidated.

   • Click the Report button above the table when the project is selected to view summarized information and more details.

3. Next, view the data for a specific scenario. The General tab summarizes the scenario in terms of resource type and allocation, constraints, destination types, and so forth. For a completed analysis, click any metric in the row to view details on the respective tab, as follows:

   • Sources: The list of sources to consolidate, including their projected CPU and memory capacities and requirements.

   • Destinations: The list of destinations to which the sources will be consolidated. Resource configuration and calculated utilization are shown for each destination.

     For consolidations to the cloud, resources of consequence are CPU capacity and memory.

   • Ratio: The ratio of sources to destinations. By default, Host Consolidation Planner will try to “fit" sources into as few destinations as possible.

   • Mapping: The destinations to which specific sources will be mapped. The analysis includes estimated CPU and memory requirements and utilization, enhanced by suggested CPU and memory allocation figures to consider. These suggestions represent a reasonable compromise between requirements and destination server capacity.

   • Confidence: The percentage of the data collected for sources that meet the source usage requirements defined in the scenario. This value is aggregated for all sources defined with the project.

   • Violations: The number of violations of technical or business constraints defined in the scenario. This metric is applicable only if the scenario uses auto-mapping of sources to destinations.

   • Exclusions: The number of sources that do not have a qualified mapping to a destination. These are sources that exceed the capacity of available destinations.

Database Migration Planner offers flexibility for various customer scenarios:

• Consolidate 10.2 and higher database versions.

• Consolidate to Oracle private or public cloud or to Exadata.

• Use high availability options to minimize downtime, subject to source and destination database platform and version.

Database Migration Planner takes the guess work out of consolidation by basing analysis on historical workload (database and host metrics). It eliminates human error by automating all phases of consolidation from planning to deployment.

Consolidation optimization advice enables you to estimate resource allocation under various consolidation scenarios, from ultra conservative, representing a peak maximum load, to aggressive, measured as the average daily usage per hour. Use optimization advice to identify conflicts based on workload characteristics and Exadata suitability. Assess the impact of compression on I/O and storage, including I/O offloading and Flash Cache technology.

As servers have become more and more powerful, with much greater workload capacity, enterprises with many small databases running on different servers find that their servers are greatly underutilized. Their aim is to consolidate these small databases onto fewer servers, thereby reducing their hardware purchasing cost and ongoing maintenance expenditures.

At the same time, database customers, in assessing their performance needs, want to evaluate resource utilization over a total specified time period to ensure meeting peak demand.

When weighing source I/O requirements to determine needed destination capacity, the key is I/O capacity of external storage units of Oracle Engineered Systems such as Exadata and Exalogic typically shared by databases.

Database Migration Planner collects detailed storage information regarding total space allocated and total space used for each source database by segment type (Table, Index, LOB, Other). It then estimates how much space can be saved by compressing the data. Depending on the segment type and database version, estimates are given for several types and levels of compression.

• At the project level, Database Migration Planner displays data storage requirements by database and segment type, with compressed and uncompressed values.

• At the scenario level, Database Migration Planner recommends a specific type and quantity of Exadata external storage system, based on the requirement and customer input with regard to compression and other storage options.

Database Migration Planner collects the following I/O requirements:

• I/O requests per second (IOPS)

• I/O bandwidth (MB/Second)

Database Migration Planner fits the requirements to external storage unit I/O capacity, using the ratio of I/O bandwidth to IOPS to characterize each source database workload as either OLTP or DSS. These findings determine whether Database Migration Planner considers IOPS, I/O bandwidth, or both when consolidating to external storage. Note, however, that users can override these recommendations.

Thus, when consolidating databases, Database Migration Planner attempts to fit CPU and memory capacity to the destination, but not database storage and I/O capacity.

You create a database consolidation project for each consolidation effort, then add individual consolidation scenarios within it. You can then compare consolidation scenarios to determine which consolidation strategy makes the most sense.

After the project is defined, a Cloud Control job is submitted to collect available data for the specified targets from the Management Repository. Once the job finishes, the project becomes an active project. As long as the project is in an active state, data collection will continue.

Creating a project involves the following steps:

• Selecting the Database Migration Project Type

• Specifying Database Source Candidates

• Specifying Database Destination Candidates

• Setting Data Collection Parameters

• Choosing a Pre-configured Scenario

• Reviewing and Saving the Database Consolidation Project

You can create custom database consolidation scenarios instead of or in addition to using the pre-configured scenarios. Multiple scenarios can be created within a project, enabling you to compare different scenarios before deciding on a solution. New consolidation scenarios are created within an existing consolidation project.

You can create consolidation scenarios for planning purposes. You also can implement the scenario, which enables you to perform the database migration on-demand.

Creating a scenario involves the following steps:

• Setting Up the Scenario

• Defining Constraints for Database Consolidation

• Planning the Destination for a Database to Database Project

• Planning the Destination for a Database to Server Project

• Mapping Database Sources to Destinations

• Reviewing and Saving the Database Consolidation Scenario

1. On the Database Migration Planner home page, select Create Scenario from Template from the Actions menu.
2. Browse to a saved template XML file in the local file system. Click Open.
3. Indicate the extent to which you want to replicate the saved template; that is, in terms of the resources, constraints, and destinations planning represented by the template. Click Update if you make any changes.
4. Click OK to import the saved template.

   The imported scenario opens in the wizard where you can edit and save it in Database Migration Planner.

1. From the Enterprise menu, select Consolidation, then select Database Migration Planner. This selection is also available from the Administration menu on the Databases target home page.
2. First, examine the project containing the scenario you want to view.

   • The Status column indicates the status of data collection, based on the minimum and maximum collection days specified for the project.

   • The General tab summarizes the project in terms of type, collection details, number of sources, and so forth.

   • Click the Source Candidates tab to view various usage data collected for the sources defined in the project. Data can include utilization rates for CPU, memory, storage, and disk and network I/O, depending on the project type.

     Data might include the estimated compression ratio. As noted on the page, if listed as not available, you can gather compression estimates prior to creating scenarios. Click the Deploy Database Migration Planner Packages link in the on-screen text above the details to submit a compression advice job.

   • Click the Source Workload tab to view source resource usage data collected. The default display is a line graph. Alternatively, you can view the same data as a heat map, a grid of 24 hours by 30 days, showing the workload for a given hour as a color indicating the load relative to 100% of capacity, and a number showing the actual percentage. You can filter either view by source, resource type, and month.

   • Click the Destination Candidates tab to view a breakdown of hardware details and projected resource utilization by destination candidate, based on the sources to be consolidated.

   • Click the Advisor Findings tab to view the results of checks run on database performance data. Findings reveal potential performance bottlenecks and recommend ways of reducing or eliminating them.

     Severity may be informational, a warning, or critical in nature. Mouse over the rule for a description of what the rule checks for and suggestions for a resolution. The finding may be truncated. Mouse over it to see the complete description.

   • Click the Report button above the table when the project is selected to view summarized information and more details.

3. Next, view the data for a specific scenario. The General tab summarizes the scenario in terms of resource type and allocation, constraints, destination types, and so forth. For a completed analysis, click any metric in the row to view details on the respective tab, as follows:

   • Sources: The list of sources to consolidate, including their projected CPU and memory capacities and requirements.

   • Destinations: The list of destinations to which the sources will be consolidated. Resource configuration and calculated utilization are shown for each destination.

     For consolidations to the cloud, resources of consequence are CPU capacity and memory.

   • Ratio: The ratio of sources to destinations. By default, Database Migration Planner will try to “fit" sources into as few destinations as possible.

   • Mapping: The destinations to which specific sources will be mapped. The analysis includes estimated CPU and memory requirements and utilization, enhanced by suggested CPU and memory allocation figures to consider. These suggestions represent a reasonable compromise between requirements and destination server capacity. See Figure 47-1 for a screen capture of a representative consolidation mapping.

   • Storage: Summary of storage requirements and compression estimates for each source database. In calculating storage estimates, Database Migration Planner ignores local storage on Exadata compute nodes (local disks that contain system software), and focuses on data storage contained in Exadata storage units. The system recommends the number of such units needed, based on the source storage requirements and the compression specifications in the scenario.

     Drill down for detailed information. For example, numbers in the Space (GB) (Estimated) column are links. Click the link for a source database to open a compression estimates pop-up. The highlighted row represents the table compression type selected when creating the scenario.

     Similarly, click the links in the IOPS and IO Bandwidth columns to see a breakdown of IOPS and IO bandwidth into read and write components, and in some cases, into small and large I/O subcomponents. You can also see the impact of Exadata Simulation on a source database, in the event of a SQL Performance Analyzer simulation.

     When the destination is an existing server or database that uses Automatic Storage Management (ASM), the system checks and reports the storage space capacity, projected utilization (%), projected space usage (GB), and additional storage capacity (GB) required, if any, on each ASM destination.

   • Confidence: The percentage of the data collected for sources that meet the source usage requirements defined in the scenario. This value is aggregated for all sources defined with the project.

   • Violations: The number of violations of technical or business constraints defined in the scenario. This metric is applicable only if the scenario uses auto-mapping of sources to destinations.

   • Exclusions: The number of sources that do not have a qualified mapping to a destination. These are sources that exceed the capacity of available destinations. An exclusion can occur simply because there is not enough of a resource to accommodate a source.

     A different set of constraints may result in a different optimal scenario. Modify the constraints to come up with different scenario results.

   • Schema Conflicts: Lists schemas that exist in more than one source database or that also exist in the destination database. This is specific to D2D scenarios where you chose a non-CDB (single instance) database architecture in the Destinations Planning step of scenario creation. Schema conflicts do not involve Oracle-supplied system schemas.

   • Advisor Findings: Potential performance bottlenecks and recommended ways of reducing or eliminating them. Also indicates possible problems that can arise based on the consolidation specification.

     Severity may be informational, a warning, or critical in nature. Mouse over the rule for a description of what the rule checks for and suggestions for a resolution. The finding may be truncated. Mouse over it to see the complete description.

Figure 47-1shows the mapping for a simple database-to-database consolidation using the default phantom destination (clustered CDB/PDB). The figure illustrates the key points of mapping as explained in Table 47-1.

Figure 47-1 Database Consolidation Mapping

Table 47-1 explains the key points of mapping as annotated in Figure 47-1.

Table 47-1 Legend for Figure 47-1

Reference Point	Explanation
1	Name of rack, compute node, and consolidated database instance
2	Number of databases consolidated to this instance
3	CPU capacity of compute node
4	Total CPU utilization (%) for this compute node, including CPU utilization for existing destinations when applicable
5	Total CPU usage for this compute node
6	Memory capacity of the compute node
7	Total memory utilization (%) for this compute node, including utilization for existing destinations when applicable
8	Total memory usage for this compute node
9	Name of the pluggable database
10	Name of source database consolidated to this PDB
11	Percentage of compute node's CPU consumed by this source database
12	CPU usage for this source database on the compute node
13	Percentage of compute node's memory consumed by this source database
14	Memory usage for this source database on the compute node

The Advisor gathers database performance data from the Automatic Workload Repository (AWR) and uses the data as input to rules. The rules are evaluated to determine if performance bottlenecks exist in the source or destination databases, and provide advice on how to relieve the problem. At the scenario level, the rules also look at source databases in combination as well as at destination specifications to determine if the consolidation might experience performance problems.

Advisor findings are viewable for both projects and scenarios, as a column on the Database Migration Planner home page, and as a tab in the respective project and scenario details region.

The Compression Advisor estimates how much space compression savings each source database can potentially benefit from for different types of supported compression types, and calculates how much space the uncompressed data would require. The results appear on the Storage tab of a database consolidation scenario. You can also specify how to compress data in the destination, so that reductions can be applied when determining how much storage will be needed. To enable the estimation of compression, you have to deploy a job to each source database and run compression advice to make the results available to Database Migration Planner.

1. From the Enterprise menu, select Job, then select Activity.
2. On the Jobs page, click the Create Job button.
3. Locate Deploy Database Migration Planner Packages in the Job Type list and click Select.

   This takes you to the job creation page, where you also land when you click the Deploy Database Migration Planner Packages link on the Source Candidates tab within a database consolidation project that has already been created.

4. Enter a name for the compression advice job.
5. Add database targets that are source candidates to a consolidation. You can multiselect, but the target type (single instance or cluster), must be the same. Select in the table the target instances you want to include in the job.
6. On the Parameters tab, set Run Compression Advice to Yes.
7. Complete the rest of the job creation process and submit the job. Note that the job needs to run with SYSDBA credentials on the target databases.

After creating a database consolidation scenario, you can implement the mapping by migrating source databases to their mapped destinations using any of four supported migration methods:

• Data Guard Physical Standby (minimal downtime)

• RMAN Clone

• Data Pump (full or schema) Export and Import (cross-platform)

• Full Transportable Export and Import (minimal downtime, cross-platform)

Implementing a database consolidation scenario generates an XML file that you edit directly within Database Migration Planner to provide supplementary information such as necessary credentials. You then save the file locally to be input to an EMCLI command that submits deployment procedures to perform the actual migration.

1. From the Enterprise menu, select Consolidation, then select Database Migration Planner.
2. Select a completed database consolidation scenario on the Database Migration Planner home page and click Implement Scenario.
3. Select a migration method, RMAN Clone for example, from the available options. Mouse over a method to see a description. Note, in particular, minimum version requirements.
4. Click Generate Migration Command to create an EMCLI migration command and associated migration XML file.
5. Click Edit Migration XML to address any issues listed under Messages and to add supplementary information. The generated file is heavily commented to indicate the information needed, such as database and host credentials, location of working directory, and so forth.
6. Click Validate to ensure XML conformance.
7. Click Save and Return if you want to preserve the XML file and any edits you may have made, and go back to the Database Migration Planner home page. The file will be available the next time you want to implement the scenario.
8. Click Download Migration XML to save the file to the local file system.

ENCRYPTION_WALLET_LOCATION = 
     (SOURCE = 
     (METHOD = FILE) 
     (METHOD_DATA = 
     (DIRECTORY = /scratch/jdoe/app/jdoe/admin/dben/wallet) 
     ) 
   ) 

1. From the Targets menu, select Databases, then search for the destination database.
2. On the destination database home page, select Transparent Data Encryption from the Security menu.
3. Open the wallet by providing the requisite password.

1. Capture the SQL workload that you intend to analyze and store it in a SQL tuning set.
2. Pre-system change, create a SQL Performance Analyzer task.
3. Build the pre-change SQL trial by test executing or generating execution plans for the SQL statements stored in the SQL tuning set.
4. Perform the system change.
5. Build the post-change SQL trial by re-executing the SQL statements in the SQL tuning set on the post-change system.
6. Generate a report to identify the impact of change on the SQL statements.
7. View the SQL Performance Analyzer report to compare pre- and post-change SQL performance. You can access the report from the destination database home page by selecting SQL then SQL Performance Analyzer Home from the Performance menu.

You can repurpose consolidation project and scenario details in report form that you can capture in a variety of formats and distribute to a wider audience, as described in the following sections:

• Viewing Consolidation Project Reports

• Viewing Consolidation Scenario Reports

1. On the respective Consolidation home page select View Data Collection from the Actions menu.
2. The view lists sources within a project where you can perform the following tasks:

   • View the latest collection status by project.

   • Select a source to see its collection history and troubleshoot potential problems with the collection.

   • Click the link under Data Collection Jobs to go to the job activity page where you can view and administer the latest data collection job.

   • Update the latest CPU performance metric values by following the instructions to download a CSV file with the latest rates. After downloading the file, click Browse to locate the file in the local file system and click Load to update the rates in Enterprise Manager Consolidation.

A shape defines the number of Oracle Compute Units (OCPUs) and the amount of RAM available for an instance. An OCPU provides the equivalent CPU capacity of the current 3.0 GHz 2012 Intel Xeon processor with hyper threading enabled. Each OCPU corresponds to two hardware execution threads, known as vCPUs.

A wide range of shapes is available to help you select a combination of processing power and memory for your instances that best suits your business requirement. While selecting a shape for your instance, consider the nature of applications that you will deploy on the instance, the number of users that you expect to use the application, and also how you expect the load to scale in the future. Remember to also factor in the CPU and memory resources that will be used by the OS.

To determine the shape that meets your resource requirements, you may want to experiment with a shape and test it with a representative workload.

The following table provides the list of shapes currently available in Oracle Compute Cloud Service. The shapes named OC3 through OC7 represent standard combinations of OCPUs and memory, while shapes named OC1M through OC5M represent high memory configurations, where the memory allocation is double that of the standard configurations.

Visit http://www.oracle.com/cloud/index.html for complete information on Oracle Cloud Computing.