42 Enterprise Manager Consolidation

Enterprise Manager Consolidation offers two consolidation solutions:

Host Consolidation Planner, for consolidating physical or virtual source servers to physical or virtual destination servers.
Database Consolidation Workbench, for consolidating or migrating databases to new or existing servers. Database Consolidation Workbench is part of the Real Application Testing option. For further details, please refer to Oracle Database Licensing Information User Manual.

This chapter contains the following sections:

42.1 Overview of Consolidation

Key Concepts

The central theme of consolidation is to combine existing server or database sources to existing or yet-to-be-purchased destination servers or databases.

Consolidation starts with a project, which defines the scope of a potential effort, including:

The type of consolidation. The following types of consolidation schemes are supported:
- P2V: From physical source servers to Oracle Virtual Machine (VM) destination servers
- P2P: From physical source servers to physical destination servers
- D2D: From database sources to new database on new server destinations or to existing database destinations
- D2S: From database sources to new or existing servers
The preliminary set of candidate source servers to consider consolidating from
The preliminary set of candidate destination servers to consider consolidating to
The duration over which data used to generate consolidation scenarios will be collected for the source servers
The benchmark used to measure CPU capacities when determining how many source servers can be consolidated to a destination server

Each consolidation project contains one or more consolidation scenarios that are generated based on the inputs provided, which include:

The source server resource requirements that a destination server must meet, including one or more of the following: CPU, memory, disk I/O, network I/O, and disk storage
Any business, compliance or technical constraints that must be considered
The destinations to consider in the scenario

A set of pre-configured consolidation scenarios are provided, representing aggressive, medium, and conservative consolidation schemes. Each scenario is generated based on inputs you provide. Alternatively, you can create your own custom scenarios that best suit your situation. Once created, you can compare the various scenarios to determine which consolidation strategy best meets your requirements.

Each scenario also includes initial mappings between each source and the destination it may be consolidated to. You can choose to create mappings manually, or allow Enterprise Manager Consolidation to create them automatically. Once all inputs are specified, you can run the scenario and evaluate the results. Subsequently, you can rerun the scenario to re-evaluate the scenario based on the previously specified conditions with the latest available data. The results of the previous analysis will be over-written. You can also create a new scenario based on an existing scenario, where you tweak certain values to customize the new scenario.

The Process

Create a consolidation project.
Define one or more consolidation scenarios within the project. You have two options:
- Use a pre-configured consolidation scenario.
- Create a custom consolidation scenario.
Evaluate your consolidation scenarios in the Consolidation console.
Modify the settings of your scenarios to generate different results. Continue this process until you have the most optimal scenario(s) for your situation.

When consolidating multiple sources to more than one destination, the resource requirements of sources are checked against the resource capacity of the destinations. To consolidate all identified sources to the least number of destinations, Enterprise Manager Consolidation tries to identify a set of sources that have known resource requirements that will fit into a destination's corresponding available resources as tightly as possible.

Host consolidation uses per-hour requirements, allowing it to maximize use of destination resources by matching peak usage periods of one source to low-usage periods of another. Database consolidation does the same except when using the ultra conservative resource allocation method (the default), in which case, it uses the highest usage observed across a specified date range in seeking the best destination fit.

42.2 Host Consolidation Planner

Host Consolidation Planner enables you to match managed sources you want to consolidate with new or existing destinations. Host Consolidation Planner supports the following combinations:

Consolidate source servers to generic physical machines, Oracle engineered systems (Exadata Database Machines or Exalogic Elastic Cloud systems), or Oracle Virtual Machine (VM) servers.
Consolidate source servers to physical machines configured in the Oracle Cloud. In a consolidation of this type, an Oracle Compute Cloud configuration mimics a host, except that only memory and CPU capacity are of consequence as resources to be considered.

Host Consolidation Planner leverages data collected from managed targets by Cloud Control and factors in business and technical requirements to help you determine the optimum scenarios.

The following sections describe Host Consolidation Planner:

42.2.1 Overview of Host Consolidation Planner

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.

42.2.2 Creating a Host Consolidation Planner Project

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:

42.2.2.1 Selecting the Host Consolidation Project Type

Complete Step 1 of the host consolidation project creation process as follows:

From the Enterprise menu, select Consolidation, then select Host Consolidation Planner.
Click the Create Project button.
Enter the consolidation project name and, optionally, a description.
Select the host consolidation type:
- From physical source servers to Oracle VM servers (P2V)
- from physical source servers to physical servers (P2P)
Click Next to specify source candidates.

42.2.2.2 Specifying Host Source Candidates

Complete Step 2 of the host consolidation project creation process as follows:

Select an appropriate benchmark from the drop-down menu.
- Specify SPECint®_base_rate2006 for database hosts, application hosts, or mixed-workload hosts
- Specify SPECjbb®2005 for middleware platforms
Click Add Source Servers to select the source servers to be consolidated from a list of managed server candidates. Use the filtering criteria to refine your target search. Choose from the filtered results, then click Select.

The sources you select appear in the table. Note that you can subsequently cull the list by removing selected source servers.
Optionally set server I/O capacities for disk I/O request and network I/O volume capacities. Click Specify Server I/O Capacity to estimate these I/O capacities for all source involved in the consolidation project. Note that you can subsequently fine-tune these estimates by clicking a row and editing the values for the various capacities.
Click Next to specify destination candidates.

42.2.2.3 Specifying Host Destination Candidates

Complete Step 3 of the host consolidation project creation process as follows:

Optionally select one or more existing servers to consolidate the source servers to.
- If you are consolidating from physical servers to Oracle Virtual Servers (P2V), click Add Existing Virtual Servers as Destinations to view a list of existing VM-based Exalogic Elastic Cloud systems and Oracle Virtual Machine destination servers to consolidate the source servers to. Use the target type filter to differentiate the two. Select the servers you want to add, then click Select.
  
  The destinations you select appear in the table. Note that you can subsequently cull the list by removing selected destination servers.
- If you are consolidating from physical servers to physical servers (P2P), click Add Existing Oracle Engineered System as Destinations to search for the Exadata Database Machine servers or Exalogic Elastic Cloud servers to consolidate the source servers to. Use the target type filter to differentiate the two. Select the servers you want to add, then click Select.
  
  The destinations you select appear in the table. Note that you can subsequently cull the list by removing selected destination servers.
Note:

If you do not select existing destinations, the consolidation will be to new (phantom) destinations. For P2P projects, if you do not select existing destinations, the source servers you select are also considered destination servers. This enables you to select a subset of source servers to consolidate to.
Optionally edit estimated CPU capacity, I/O request, and network I/O volume by clicking in a row and changing the value. You can also edit the I/O value by clicking Specify Server I/O Capacity to estimate these I/O capacities for all destination servers involved in the consolidation project.
Click Next to set up data collection.

42.2.2.4 Setting Data Collection Parameters

Specify the duration over which data used to generate host consolidation scenarios will be collected for the source servers specified in the project. This data will be used to determine the resource requirements that a destination server must meet.

Specify the minimum number of days to collect data. The default minimum value is 21 days. To use existing historical data to run and view consolidation scenarios immediately, set the minimum number of days to 0.
Specify the maximum number of days to collect data. The default maximum value is 90 days.
Specify when to begin the data collection process.

Note that once data collection begins, you can elect to suspend and resume collecting at any time from the Actions menu in the Consolidation console.
Optionally select Continue Data Collection Over the Maximum Days to purge the oldest day's data when data for a new day is added.
Click Next to choose a pre-configured scenario.

42.2.2.5 Choosing a Pre-configured Scenario

When creating a host consolidation project, you can optionally choose to generate pre-configured consolidation scenarios to add to the project.

These scenarios are generated using data collected for the sources defined in the consolidation project at the time the project is created. If insufficient data is available when the project is created, the pre-configured scenarios will be automatically generated once the minimum amount of data has been collected.

Host Consolidation Planner ships with three out-of-the-box scenarios that represent aggressive, medium, and conservative consolidation schemes.

Choose whether to use a pre-configured scenario by clicking the appropriate radio button. Choosing the option displays a list of the out-of-the-box consolidation scenarios available. By default, the scenarios are designated by the method used to aggregate source target resource usage:
- Aggressive: Aggregate data based on average daily usage per hour.
  
  This typically results in a high consolidation (source:destination) ratio, because more sources will “fit" into each destination. But because more sources are involved, the odds that one or more will not meet the resource requirements are higher.
- Medium: Aggregate data based on the 80 percentile usage.
  
  This typically results in a source:destination ratio somewhere between Aggressive and Conservative aggregations.
- Conservative: Aggregate data based on maximum daily usage per hour.
  
  This typically results in a lower source:destination ratio, because fewer sources will “fit" into each destination.
Usage statistics are calculated based on the following criteria:
- Resource Requirements: Source requirements, such as CPU, memory (GB) and disk capacity, that must be met by destinations.
- Applicable Dates: The days of the week on which resource usage metrics are collected.
- Target Server Utilization Limit: The maximum resource utilization (percentage) that can be used on destinations. The scenario method in effect determines utilization percentage.
Select the pre-configured scenario you want to use. You can select any or all scenarios.
Select whether to factor new (phantom) or existing destinations in the scenario.
Proceed as follows, based on project type and selections:
- For P2V projects using new servers, specify resource requirements for CPU capacity, memory, and disk storage. Optionally, you can enter quantities of resources to hold in reserve for virtualization software. These reserves are deducted from system capacity before calculating utilization percentages.
- For P2V projects using existing servers, there is nothing to specify. The scenario method determines resource requirements. Note that this option is available only if existing virtual servers were added as destination candidates in step three of the wizard.
- For P2P projects using new servers and engineered systems, there is nothing to specify. The system selects an appropriate Exadata configuration based on requirements.
- For P2P projects using new servers and generic servers, specify resource requirements for CPU capacity, memory, and disk storage. You do not, however, have the option to enter resources to hold in reserve.
- For P2P projects using existing servers, there is nothing to specify. The scenario method determines resource requirements. Note that this option is available only if existing virtual servers were added as destination candidates in step three of the wizard.
Click Next to review the consolidation project.

The pre-configured scenarios will be generated when the project is created using data collected for the source servers defined in the consolidation project.

You can also opt to create your own custom scenario once the consolidation project has been completed.

42.2.2.6 Reviewing and Saving the Host Consolidation Project

Review the specifics of the host consolidation project. Use the Back button to return to a given step to make changes. If satisfied, click Submit. A message confirms that the project has been created and the job has been submitted.

Once the project is created, it will show up in the Consolidation console. Consolidation scenarios can then be defined for this project.

42.2.3 Creating a Host Consolidation Planner Scenario

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:

42.2.3.1 Setting Up the Scenario

Complete Step 1 of the host consolidation scenario creation process as follows:

From the Enterprise menu, select Consolidation, then select Host Consolidation Planner.
Click the consolidation project for which the scenario is intended.
Click the Create Scenario button.
Specify the scenario details, such as scenario name.
Specify the source resources to consider. Host Consolidation Planner will aggregate the specified resources to determine the total requirements.
- Resource Type: The server requirements, such as CPU, memory (GB), and I/O capacity that must be considered.
- Scale Factor: Provide room for growth on the destination for each source. The resource requirement estimate uses the scale factor to pad the estimate for consolidation. So, for example, if the estimated requirement for a given source, based on usage data, is 2 GB of memory, which equates to a scale factor of 1, and you specify a scale factor of 1.1, 2.2 GB will be required to consolidate that source.
- Applicable Days: The days of the week on which resource usage metrics are collected.
- Resource Allocation: The method used to aggregate daily server source resource usage. Values are:
  - Aggressive: Aggregate data based on average daily usage per hour.
    
    This typically results in a high consolidation (source:destination) ratio, because more sources will “fit" into each destination. But because more sources are involved, the odds that one or more will not meet the resource requirements are higher.
  - Medium: Aggregate data based on the 80 percentile usage. This typically results in a source:destination ratio somewhere between Aggressive and Conservative aggregations.
  - Conservative: Aggregate data based on maximum daily usage per hour.
    
    This typically results in a lower source:destination ratio, because fewer sources will “fit" into each destination.
- The date ranges should define a period of time that is typical of standard resource requirements.
Click Estimated Requirements to view the estimated total resource requirements.

For server consolidations, resource requirements are shown based on the averaged hourly requirement. The displayed requirements reflect the scale factor (if any) specified for the resource. The 24-hour requirement pattern will be used as the minimum requirements that must be met by consolidation destinations.
Optionally exclude or include sources, as appropriate.
Click Next to define consolidation constraints.

42.2.3.2 Defining Constraints for Host Consolidation

Specify business, corporate, or technical constraints that must be enforced. Constraints can guide the allocation process during automatic source-to-destination mapping. For manual mappings between sources and destinations, constraints can calculate violations.

Complete Step 2 of a host consolidation scenario as follows:

Select compatible server criteria.

Servers are considered compatible if they have the same specified target properties and configurations. If you are consolidating multiple source servers to a single destination server, only compatible servers can be consolidated together on the same destination server.
Specify mutually exclusive server criteria.

Certain types of source servers are mutually exclusive and should not be consolidated together on the same destination server due to various reasons. For example, nodes of an Oracle cluster should not be placed in the same failure group.
Click Preview Effect of Constraints to view a list of source servers that are not compatible based on the defined constraints.
Click Next to specify destination server candidates.

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

For a P2V project:

Choose destination server candidates using either of the following options:
- Click Use New (Phantom) Servers if you plan to use destination servers that have yet to be provisioned or purchased, then select either of the following options:
  - Use Oracle Engineered System and click the search icon to select an appropriate configuration type for an Exalogic Elastic Cloud system.
  - Use Generic Servers and provide the estimated CPU capacity if available; otherwise, click the search icon next to the CPU capacity input field, then select a server configuration that most closely matches your needs.
    
    Adjust the memory and storage estimates as necessary.
    
    In a virtual environment, you can also specify a quantity of the resource to be set aside (reserved) for use by supervisory software in the database machine. This quantity is subtracted from the total capacity of the destination before consolidating source servers into the remaining resource. For example, if your estimated memory requirement is 12 GB and you specify a reserve of 2 GB, only 10 GB is available for consolidation.
    
    Host Consolidation Planner will determine how many destination servers are required as part of the consolidation results.
- Click Use Existing Servers to specify a set of existing managed servers to use as destinations.
  
  These are the servers you specified when defining the scope for the consolidation project. Host Consolidation Planner will determine the available hardware resources based on collected usage data.
  
  By default, the consolidation process will try to use as few destination servers as possible. If you prefer, choose to balance the source load across all destinations.
Accept the defaults or edit the percentages for Maximum Allowed Resource Utilization on Destination Servers. Contrast these allowances, which provide headroom on destination servers, with the scale factor, which provides headroom for individual source servers.
Click Next to map the source servers to the destination servers.

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

For a P2P project:

Choose destination server candidates using either of the following options:
- Click Use New (Phantom) Servers if you plan to use destination servers that have yet to be provisioned or purchased, then select one of the following options:
  - Use Oracle Engineered System and select either Exadata Database Machine or Exalogic Elastic Cloud. Click the search icon and select a configuration type appropriate to either choice.
  - Use Generic Servers and provide the estimated CPU capacity if available; otherwise, click the search icon next to the CPU capacity input field, then select a server configuration that most closely matches your needs.
  - Use Oracle Compute Cloud and select the cloud computing configuration, or shape, to use as the destination. See About Oracle Compute Cloud Shapes, for information on shapes.
- Click Use Existing Servers to specify a set of existing managed servers to use as destinations for the project.
  
  These are the servers you specified when defining the scope for the consolidation project. Host Consolidation Planner will determine the available hardware resources based on collected usage data. If you did not explicitly specify destination candidates, all source servers are potential destinations for consolidation.
  
  By default, the consolidation process will try to use as few destination servers as possible. If you prefer, choose to balance the source load across all destinations.
Accept the defaults or edit the percentages for Maximum Allowed Resource Utilization on Destination Servers. Contrast these allowances, which provide headroom on destination servers, with the scale factor, which provides headroom for individual source servers.
Click Next to map the source servers to the destination servers.

42.2.3.5 Mapping Host Sources to Destinations

Next, map the host sources to the destinations they will be consolidated to. The objective is to fit source requirements with each destination's available resources as tightly as possible.

Oracle recommends that you allow Host Consolidation Planner to perform this mapping automatically. This will allow the tool to maximize resource utilization of destinations based on resource capabilities and the various consolidation constraints specified. If you use manual mapping, the source will be mapped to the destination even if the destination lacks sufficient capacity. In addition, manual mapping may violate previously declared constraints.

When you have chosen existing destinations, you can optionally map each source and destination manually:

Click a source in the list.
Click the flashlight icon to select the destination to map to the source. Note that you can map a single source to a destination or multiple sources to a destination, but there can be only one destination

The resulting consolidation report will show any resource and/or constraint violations due to such manual mapping.
Click Next to review the consolidation scenario.

42.2.3.6 Reviewing and Saving the Host Consolidation Scenario

Finally, review the various parameters set in the new host scenario. Use the Back button if you need to make changes; otherwise, proceed as follows:

Optionally, you can save the scenario as a template, which can then be shared with other users. If you want to do this, click Save Scenario as a Template. In the dialog that opens, browse to a location in the local file system and save the template as an XML file.
Click Submit. A message appears confirming that a job has been submitted for further analysis of the scenario. Results appear at the bottom of the Consolidation home page when done.

42.2.4 Other Host Consolidation Scenario Creation Options

You can create a host consolidation scenario based on an existing scenario. Select an applicable scenario under a consolidation project and then select Create Like Scenario from the Actions menu. Modify the scenario as desired, provide a meaningful name, and submit for analysis as usual.

If you saved a scenario as a template, you can subsequently import the scenario into another environment.

On the Host Consolidation Planner home page, select Create Scenario from Template from the Actions menu.
Browse to a saved template XML file in the local file system. Click Open.
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.
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.

42.2.5 Evaluating Host Consolidation Scenarios

You can view details for your consolidation scenarios using the Consolidation console. After evaluating the consolidation scenario results, you can define different plans as well as rerun existing scenarios to re-evaluate them based on the previously specified conditions with the latest available data. The results of the previous analysis will be over-written. You can also create a new scenario based on an existing scenario, where you tweak certain values to customize the new scenario. This iterative process helps you obtain the optimized consolidation scenario which is generated by compromising various factors and weighing different trade-offs.

Compare the consolidation scenarios you create to determine which consolidation strategy best meets your requirements.

Your objective is to:

Match source resource requirements with destinations best able to meet those requirements.
Fit source requirements with each destination's available resources as tightly as possible, so you can get maximum usage of destination capacity.
Provide room for growth on destinations by allowing for headroom as a factor of resource requirements.
Optionally balance the source workload across all available destinations.

From the Enterprise menu, select Consolidation, then select Host Consolidation Planner.
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.
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.

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

42.3 Database Consolidation Workbench

Database Consolidation Workbench provides a comprehensive end-to-end solution for managing database consolidation. It enables you to match managed sources you want to consolidate with new or existing destinations. Database Consolidation Workbench supports the following combinations:

Consolidate source databases (single instance or RAC) to fewer destination databases, using the database to database (D2D) consolidation type. Destinations can be existing databases (both non-CDB and CDB) or new databases on new servers, which can be Oracle Exadata Database Machines, Oracle Compute Cloud shapes, or generic servers.
Consolidate source databases (single instance or RAC) to fewer servers where the number of databases stays the same, using the database to server (D2S) consolidation type. Destinations can be existing servers or new servers, which can be Oracle Exadata Database Machines, Oracle Compute Cloud shapes, or generic servers.

Database Consolidation Workbench uses database metrics in assessing resource requirements for database consolidation. You must have Oracle Enterprise Manager 13c Release 1 Database Plug-in or later to collect the database metrics Database Consolidation Workbench uses.

The following sections describe Database Consolidation Workbench:

42.3.1 Overview of Database Consolidation Workbench

Database Consolidation Workbench 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 Consolidation Workbench 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 Consolidation Workbench 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 Consolidation Workbench displays data storage requirements by database and segment type, with compressed and uncompressed values.
At the scenario level, Database Consolidation Workbench 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 Consolidation Workbench collects the following I/O requirements:

I/O requests per second (IOPS)
I/O bandwidth (MB/Second)

Database Consolidation Workbench 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 Consolidation Workbench 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 Consolidation Workbench attempts to fit CPU and memory capacity to the destination, but not database storage and I/O capacity.

42.3.2 Creating a Database Consolidation Workbench Project

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.

Creating a project involves the following steps:

42.3.2.1 Selecting the Database Consolidation Project Type

Complete Step 1 of the database consolidation project creation process as follows:

From the Enterprise menu, select Consolidation, then select Database Consolidation Workbench. This selection is also available from the Administration menu on the Databases target home page.
Click the Create Project button.
Enter the consolidation project name and, optionally, a description.
Select the appropriate consolidation type.
- From databases to server containers (D2S)
- From databases to database containers (D2D).
Click Next to specify source candidates.

42.3.2.2 Specifying Database Source Candidates

Complete Step 2 of the database consolidation project creation process as follows:

SPECint®_base_rate2006, as the appropriate benchmark for database consolidations, is preselected. Click Select Source Databases to select the source databases to be consolidated from a list of Oracle Enterprise Manager-managed database candidates. Use the filtering criteria to refine your target search. Choose from the filtered results, then click Select.

The sources you select appear in the table. Note that you can subsequently cull the list by removing selected source databases.
Optionally edit estimated CPU capacity rates by clicking in a row and changing the value.
Click Next to specify destination candidates.

42.3.2.3 Specifying Database Destination Candidates

Complete Step 3 of the database consolidation project creation process as follows:

Optionally select one or more existing destinations to consolidate the sources to.
- If you are consolidating from databases to server containers (D2S), click Add Existing Servers as Destinations to view a list of existing destination servers to consolidate the source databases to. Use the filtering criteria to refine the search. Select the servers you want to add, then click Select.
  
  The destinations you select appear in the table. Note that you can subsequently cull the list by removing selected destination server containers.
- If you are consolidating from databases to database containers (D2D), click Select Destinations to search for the database containers to consolidate the source databases to. Use the filtering criteria to refine the search. Select the database containers you want to add, then click Select.
  
  The destinations you select appear in the table. Note that you can subsequently cull the list by removing selected destination database containers.
Note:

If you do not select existing destinations, the consolidation will be to new (phantom) destinations.
Click Next to set up data collection.

42.3.2.4 Setting Data Collection Parameters

Specify the duration over which data used to generate database consolidation scenarios will be collected for the source databases specified in the project. This data will be used to determine the resource requirements that a destination server or database must meet.

Specify the minimum number of days to collect data. The default minimum value is 21 days. To use existing historical data to run and view consolidation scenarios immediately, set the minimum number of days to 0.
Specify the maximum number of days to collect data. The default maximum value is 90 days.
Specify when to begin the data collection process.

Note that once data collection begins, you can elect to suspend and resume collecting at any time from the Actions menu in the Consolidation console.
Optionally select Continue Data Collection Over the Maximum Days to purge the oldest day's data when data for a new day is added.
Click Next to choose a pre-configured scenario.

42.3.2.5 Choosing a Pre-configured Scenario

When creating a database consolidation project, you can optionally choose to generate pre-configured consolidation scenarios to add to the project.

Enterprise Manager Consolidation ships with three out-of-the-box scenarios that represent aggressive, medium, and conservative consolidation schemes.

Choose whether to use a pre-configured scenario by clicking the appropriate radio button. Choosing the option displays a list of the out-of-the-box consolidation scenarios available. By default, the scenarios are designated by the method used to aggregate source target resource usage:
- Aggressive: Aggregate data based on average daily usage per hour.
  
  This typically results in a high consolidation (source:destination) ratio, because more sources will “fit" into each destination. But because more sources are involved, the odds that one or more will not meet the resource requirements are higher.
- Medium: Aggregate data based on the 80 percentile usage.
  
  This typically results in a source:destination ratio somewhere between Aggressive and Conservative aggregations.
- Conservative: Aggregate data based on maximum daily usage per hour.
  
  This typically results in a lower source:destination ratio, because fewer sources will “fit" into each destination.
Usage statistics are calculated based on the following criteria:
- Resource Requirements: Source requirements, such as CPU, memory (GB) and disk capacity, that must be met by destinations.
- Applicable Dates: The days of the week on which resource usage metrics are collected.
- Target Server Utilization Limit: The maximum resource utilization (percentage) that can be used on destinations. The scenario method in effect determines utilization percentage.
Select the pre-configured scenario you want to use.
Select whether to factor new or existing destinations in the scenario. For a D2S project, the choice is either a new (phantom) or existing Exadata Database Machine. For a D2D project, you have to select the appropriate database architecture in addition to choosing a new or existing database on a new or existing Exadata Database Machine.
Click Next to review the consolidation project.

The pre-configured scenarios will be generated when the project is created using data collected for the databases defined in the consolidation project.

You can also opt to create your own custom scenario once the consolidation project has been completed.

42.3.2.6 Reviewing and Saving the Database Consolidation Project

Review the specifics of the database consolidation project. Use the Back button to return to a given step to make changes. If satisfied, click Submit. A message confirms that the project has been created and the job has been submitted.

Once the project is created, it will show up in the Consolidation console. Consolidation scenarios can then be defined for this project.

42.3.3 Creating a Database Consolidation Workbench Scenario

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:

42.3.3.1 Setting Up the Scenario

Complete Step 1 of the database consolidation scenario creation process as follows:

From the Enterprise menu, select Consolidation, then select Database Consolidation Workbench. This selection is also available from the Administration menu on the Databases target home page.
Click the consolidation project for which the scenario is intended.
Click the Create Scenario button.
Specify the scenario details, such as scenario name.
Specify the source resources to consider. Database Consolidation Workbench will aggregate the specified resources to determine the total requirements.
- Resource Type: The server requirements such as CPU and memory (GB) that must be considered.
- Scale Factor: Provide room for growth on the destination for each source. The resource requirement estimate uses the scale factor to pad the estimate for consolidation. So, for example, if the estimated requirement for a given source, based on usage data, is 2 GB of memory, which equates to a scale factor of 1, and you specify a scale factor of 1.1, 2.2 GB will be required to consolidate that source.
- Applicable Days: The days of the week on which resource usage metrics are collected.
- Resource Allocation: The method used to aggregate overall database source resource usage. Values are:
  - Aggressive: Aggregate data based on average daily usage per hour.
    
    This typically results in a high consolidation (source:destination) ratio, because more sources will “fit" into each destination. But because more sources are involved, the odds that one or more will not meet the resource requirements are higher.
  - Medium: Aggregate data based on the 80 percentile usage. This typically results in a source:destination ratio somewhere between Aggressive and Conservative aggregations.
  - Conservative: Aggregate data based on maximum daily usage per hour.
    
    This typically results in a lower source:destination ratio, because fewer sources will “fit" into each destination.
  - Ultra Conservative: Do not aggregate data by hourly usage; rather, use the highest usage observed across the specified date range. This is the default for database consolidations.
- The date ranges should define a period of time that is typical of standard resource requirements.
Click Estimated Requirements to view the estimated total resource requirements. For database consolidations, it is the single value that characterizes requirements over the date range.
Optionally exclude or include sources, as appropriate.
Click Next to define consolidation constraints.

42.3.3.2 Defining Constraints for Database Consolidation

Specify business, corporate or technical constraints that must be enforced. Constraints can guide the allocation process during automatic source-to-destination mapping. For manual mappings between sources and destinations, constraints can calculate violations.

Complete Step 2 of a database consolidation scenario as follows:

Select compatible database criteria.

Databases are considered compatible if they have the same specified target properties and configurations. Use target properties and configurations to consolidate databases based on functional area or database release and version.
Specify mutually exclusive source database criteria.

Use conditions to restrict consolidation of Data Guard/standby databases.
Click Preview Effect of Constraints to view a list of source databases that are not compatible based on the defined constraints.
Click Next to specify destination server candidates.

42.3.3.3 Planning the Destination for a Database to Database Project

For a D2D project:

Choose destination database candidates using either of the following options:
- Click Use New (Phantom) Database on New Phantom Servers if you plan to use a destination database that does not yet exist. Specify destination database requirements:
  - Is the destination to be a container database (CDB) or a single instance database?
  - Is the database to be clustered?
  - If clustered, what is the minimum number of RAC instances (at least 2)?
  - Is the server to be Exadata, Cloud, or generic?
  Adjust the memory and storage estimates as necessary.
- Click Use Existing Databases to view a set of existing qualified destination database candidates for the project.
Proceed according to your selection in Step 1:
- For new:
  - If you selected Oracle Exadata for server in Step 1, click the search icon to select an Exadata Database Machine configuration type.
  - If you selected Oracle Compute Cloud for server in Step 1, click the search icon to select the cloud computing configuration, or shape, to use as the destination. See About Oracle Compute Cloud Shapes, for information on shapes.
  - If you selected Generic Server for server in Step 1, provide the estimated CPU capacity if available; otherwise, click the search icon next to the CPU capacity input field, then select a server configuration that most closely matches your needs. Enter a memory capacity in gigabytes.
- For existing, there is no action to take; you can only view the candidates.
Configure shared storage.
- Shared Storage Unit–Selection can be a generic storage unit (default for generic server) or one of many Exadata storage units.
  - Destination databases running on generic servers share a single storage system for usable storage space, IOPS, and I/O bandwidth. Accept the defaults or specify capacity values for the respective metrics.
  - Destination databases running on Exadata Database Machines share a single storage system at a particular rack level; that is, usable storage space, IOPS, and I/O bandwidth are shared across one rack of the database machine. Capacity values for these metrics are not editable.
- ASM Redundancy–Specify the level of redundancy to use. You may, for example, want to set the level to high for mission critical systems, whereas, normal would be adequate for test and development systems.
Specify the compression to use for various segment types. Use compression type to adjust the storage space requirement.
- Table Compression Type–Choices include BASIC, OLTP, QUERY HIGH or LOW, ARCHIVE HIGH or LOW. For database versions earlier than 11.2, only OLTP is supported.
- Index Compression Type–Choices include HIGH or LOW.
- LOB Compression Type–Choices include HIGH, MEDIUM, or LOW.
Accept the defaults or edit the percentages for Maximum Allowed Resource Utilization on Destination Servers. Contrast these allowances, which provide headroom on destination servers, with the scale factor, which provides headroom for individual source servers.
Click Next to map the source databases to the destination database.

42.3.3.4 Planning the Destination for a Database to Server Project

For a D2S project:

Choose destination server candidates using either of the following options:
- Click Use New (Phantom) Servers if you plan to use destination servers that have yet to be provisioned or purchased, then select one of the following options:
  - Oracle Exadata and click the search icon to select a configuration type appropriate Exadata Database Machine.
  - Generic Server and provide the estimated CPU capacity if available; otherwise, click the search icon next to the CPU capacity input field, then select a server configuration that most closely matches your needs.
    
    Adjust the memory estimate as necessary.
  - Oracle Compute Cloud and click the search icon to select the cloud computing configuration, or shape, to use as the destination. See About Oracle Compute Cloud Shapes, for information on shapes.
- Click Use Existing Servers to specify a set of existing managed servers to use as destinations for the project.
  
  These are the servers you specified when defining the scope for the consolidation project. Database Consolidation Workbench will determine the available hardware resources based on collected usage data.
  
  By default, the consolidation process will try to use as few destination servers as possible. If you prefer, choose to balance the source load across all destinations.
Configure shared storage.
- Shared Storage Unit–Selection can be a generic storage unit (default for generic server) or one of many Exadata storage units.
  - Destination databases running on generic servers share a single storage system for usable storage space, IOPS, and I/O bandwidth. Accept the defaults or specify capacity values for the respective metrics.
  - Destination databases running on Exadata Database Machines share a single storage system at a particular rack level; that is, usable storage space, IOPS, and I/O bandwidth are shared across one rack of the database machine. Capacity values for these metrics are not editable.
- ASM Redundancy–Specify the level of redundancy to use. You may, for example, want to set the level to high for mission critical systems, whereas, normal would be adequate for test and development systems.
Specify the compression to use for various segment types. Use compression type to adjust the storage space requirement.
- Table Compression Type–Choices include BASIC, OLTP, QUERY HIGH or LOW, ARCHIVE HIGH or LOW. For database versions earlier than 11.2, only OLTP is supported.
- Index Compression Type–Choices include HIGH or LOW.
- LOB Compression Type–Choices include HIGH, MEDIUM, or LOW.
Accept the defaults or edit the percentages for Maximum Allowed Resource Utilization on Destination Servers. Contrast these allowances, which provide headroom on destination servers, with the scale factor, which provides headroom for individual source servers.
Click Next to map the source databases to the destination servers.

42.3.3.5 Mapping Database Sources to Destinations

Next, map the database sources to the destinations they will be consolidated to. The objective is to fit source requirements with each destination's available resources as tightly as possible.

Oracle recommends that you allow Database Consolidation Workbench to perform this mapping automatically. This will allow the tool to maximize resource utilization of destinations based on resource capabilities and the various consolidation constraints specified. If you use manual mapping, the source will be mapped to the destination even if the destination lacks sufficient capacity. In addition, manual mapping may violate previously declared constraints.

When you have chosen existing destinations, you can optionally map each source and destination manually:

Click a source in the list.
Click the flashlight icon to select the destination to map to the source. Note that you can map a single source to a destination or multiple sources to a destination, but there can be only one destination

The resulting consolidation report will show any resource and/or constraint violations due to such manual mapping.
Click Next to review the consolidation scenario.

42.3.3.6 Reviewing and Saving the Database Consolidation Scenario

Finally, review the various parameters set in the new database scenario. Use the Back button if you need to make changes; otherwise, proceed as follows:

Optionally, you can save the scenario as a template, which can then be shared with other users. If you want to do this, click Save Scenario as a Template. In the dialog that opens, browse to a location in the local file system and save the template as an XML file.
Click Submit. A message appears confirming that a job has been submitted for further analysis of the scenario. Results appear at the bottom of the Consolidation home page when done.

42.3.4 Other Database Consolidation Scenario Creation Options

You can create a database consolidation scenario based on an existing scenario. Select an applicable scenario under a consolidation project and then select Create Like Scenario from the Actions menu. Modify the scenario as desired, provide a meaningful name, and submit for analysis as usual.

If you saved a scenario as a template, you can subsequently import the scenario into another environment.

On the Database Consolidation Workbench home page, select Create Scenario from Template from the Actions menu.
Browse to a saved template XML file in the local file system. Click Open.
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.
Click OK to import the saved template.

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

42.3.5 Evaluating Database Consolidation Scenarios

You can view details for your consolidation scenarios using the Consolidation console. After evaluating the consolidation scenario results, you can define different scenarios as well as rerun existing scenarios to re-evaluate them based on the previously specified conditions with the latest available data. The results of the previous analysis will be over-written. You can also create a new scenario based on an existing scenario, where you tweak certain values to customize the new scenario. This iterative process helps you obtain the optimized consolidation scenario which is generated by compromising various factors and weighing different trade-offs.

Compare the consolidation scenarios you create to determine which consolidation strategy best meets your requirements.

Your objective is to:

Match source resource requirements with destinations best able to meet those requirements.
Ensure that the destination's available capacity can accommodate the combined calculated workloads of all source databases.
Provide room for growth on destinations by allowing for headroom as a factor of resource requirements.
Optionally balance the source workload across all available destinations.

From the Enterprise menu, select Consolidation, then select Database Consolidation Workbench. This selection is also available from the Administration menu on the Databases target home page.
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 Consolidation Workbench 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.
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 Consolidation Workbench 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 42-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 Consolidation Workbench 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 42-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 42-1.

Figure 42-1 Database Consolidation Mapping

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

Table 42-1 Legend for Figure 42-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

42.3.6 About the Advisor Feature of Database Consolidation Workbench

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 Consolidation Workbench home page, and as a tab in the respective project and scenario details region.

42.3.7 About Compression Advisor

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 Consolidation Workbench.

42.3.8 Estimating Compressed Storage Requirements

If you want to factor in compression ratios on source databases as part of a database consolidation, you have to submit a Deploy Database Consolidation Workbench Packages job to gather compression advice on each source. You can do this beforehand or following project creation.

From the Enterprise menu, select Job, then select Activity.
On the Jobs page, click the Create Job button.
Locate Deploy Database Consolidation Workbench 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 Consolidation Workbench Packages link on the Source Candidates tab within a database consolidation project that has already been created.
Enter a name for the compression advice job.
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.
On the Parameters tab, set Run Compression Advice to Yes.
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.

The result of these actions makes estimated compression ratios available to Database Consolidation Workbench. Note that it may take up to 24 hours after compression advice is run for the metrics to collect the data into Enterprise Manager for scenario analysis.

42.3.9 About Implementing a Database Consolidation Scenario

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 Consolidation Workbench 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.

42.3.10 Implementing a Database Consolidation Scenario

Implement a scenario by deploying a procedure to perform a database migration.

From the Enterprise menu, select Consolidation, then select Database Consolidation Workbench.
Select a completed database consolidation scenario on the Database Consolidation Workbench home page and click Implement Scenario.
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.
Click Generate Migration Command to create an EMCLI migration command and associated migration XML file.
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.
Click Validate to ensure XML conformance.
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 Consolidation Workbench home page. The file will be available the next time you want to implement the scenario.
Click Download Migration XML to save the file to the local file system.

When you are ready to migrate the source databases, run the EMCLI command (emcli migrate_db -file=<migration_xml_file_path>), passing the XML file saved locally as input. When run, the command submits deployment procedures to perform the migration. You can track the migration on the Procedure Activity page; select Provisioning and Patching, then Procedure Activity from the Enterprise menu.

When the migration method is Data Guard Physical Standby, you can invoke parameters within the migrate_db command that control downtime. You can also ignore prerequisite XML validation.

Use the get_sample_migration_xml EMCLI command to generate a sample XML migration file that demonstrates source and destination mappings, based on the chosen migration method.

See the Enterprise Manager Command Line Interface guide for details on the migration commands.

42.3.11 Database Migration and Encrypted Tablespace

If a source database uses encrypted tablespace, you will not be able to access data in these tables on the destination following the migration until you copy the wallet from the source location to a location on the destination. You can find the wallet location in the sqlnet.ora file. The default location of the file is based on the TNS Admin or ORACLE_HOME/network/admin location.

After you copy the wallet to the destination, update the sqlnet.ora file on the destination with the location where you copied the wallet. For example:

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

After updating the file, you have to open the wallet before you can access data in the encrypted tablespace.

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

You can now access data in the encrypted tablespace.

For detailed information on encryption, wallets, and other security-related issues, see the Oracle Database Advanced Security Guide.

42.3.12 Assessing the Performance Impact of Database Migration on SQL Workload

System changes such as migrating a database may cause changes to execution plans of SQL statements, resulting in a significant impact on SQL performance. You can analyze performance impact of database migration on SQL workload using SQL Performance Analyzer to identify the SQL statements that have improved, remained unchanged, or regressed after the system change.

The typical flow to assess the performance impact on SQL workload using SQL Performance Analyzer is as follows:

Capture the SQL workload that you intend to analyze and store it in a SQL tuning set.
Pre-system change, create a SQL Performance Analyzer task.
Build the pre-change SQL trial by test executing or generating execution plans for the SQL statements stored in the SQL tuning set.
Perform the system change.
Build the post-change SQL trial by re-executing the SQL statements in the SQL tuning set on the post-change system.
Generate a report to identify the impact of change on the SQL statements.
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.

As noted, this is the typical flow to use SQL Performance Analyzer. In the case of a database migration, you only need to perform the first and last steps listed above—create the SQL tuning set and view the report. The migration job does the rest:

Creates the SQL Performance Analyzer task.
Builds the pre-change SQL trial.
Performs the database migration.
Builds the post-change SQL trial.
Generates the report.

For detailed information on using the feature, see "Part I SQL Performance Analyzer" in the Oracle Database Testing Guide.

42.4 Topics Common to Host and Database Consolidations

The following sections cover topics that are common to host and database consolidations:

42.4.1 How Enterprise Manager Consolidation Analyzes a Consolidation Scenario

To analyze a consolidation scenario, Enterprise Manager Consolidation follows a defined process.

For host consolidations, Enterprise Manager Consolidation estimates the hourly and overall resource requirements for each of the consolidation sources. Using metric data collected by Enterprise Manager, it calculates the requirement for each hour and for all hours (in the specified collection days), selecting the average, 80th percentile, or maximum value, depending on the selected resource allocation style (Aggressive, Medium, or Conservative).

For database consolidations, Enterprise Manager Consolidation uses the Ultra Conservative resource allocation style, which selects the maximum value of the resource over the entire time period.

Enterprise Manager Consolidation adjusts the value if a scale factor is specified. It further adjusts memory requirements in D2D scenarios by reducing the portion of memory used for the SGA by 50%, 40% or 30%, again depending on the resource allocation style. The resource requirement displayed for the source is the overall requirement determined by the resource allocation style and adjustments.

If the consolidation scenario includes existing destinations, Enterprise Manager Consolidation performs a similar calculation to determine the hourly and overall usage values for each destination. It does not scale or otherwise adjust these values, but calculates them using average, 80th percentile, or maximum values depending on the resource allocation style.

For host consolidations into new or existing destinations, Enterprise Manager Consolidation matches the hourly requirements for each source against the available hourly capacity of a destination. (Existing destinations start this process populated with their existing hourly workloads; new destinations start in an empty state.) If the destination can accommodate all hourly requirements for all resources, a successful consolidation occurs.

For database consolidations, Enterprise Manager Consolidation adds together the single workload values for each source database to determine which databases map to each destination.

If any requirement cannot be consolidated, Enterprise Manager Consolidation tries the next destination until one is found with sufficient capacity. If the consolidation is to existing destinations and none have sufficient remaining capacity, the source is excluded from the consolidation. For consolidation to new destinations, another destination is created to accommodate the source.

For D2D scenarios with RAC database destinations, where the workload is shared across multiple instances, the process differs. Each source database's workload is consolidated onto all instances in the RAC database, and the total workload is balanced across all instances. This is also true for D2S scenarios with Exadata or cluster destinations.
For D2D scenarios with Container database (CDB) destinations, each source database is consolidated to a separate pluggable database (PDB) within the CDB. Source databases that are in conflict due to user-specified constraints are consolidated to separate CDBs.
By default, Enterprise Manager Consolidation consolidates sources to the fewest possible destinations. However, for scenarios with multiple existing destinations, you can choose to spread the workload across all destinations instead.

The scenario Mapping page displays the results of the consolidation. The contents of this page vary depending on the project type and the resources selected for consolidation, but in general displays the following:

Projected destinations, and the sources consolidated to each destination.
For each resource, the capacity of the destination, together with the percentage and amount of that resource that will be consumed by the sources consolidated to it and existing workload, if any. Enterprise Manager Consolidation estimates this amount by finding the largest hourly usage for the resource on the destination. The source line shows the percentage of the destination's resources that will be used by that source.

42.4.2 Viewing Consolidation Reports

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:

42.4.2.1 Viewing Consolidation Project Reports

To view a project report, select the host or database project on the respective Consolidation home page and click the Report button above the table. The report page repurposes project details as stacked, scrollable tables representing the tabbed information that appears in the project's details on the home page.

Click Publish Report to capture report contents. This action integrates with BI Publisher, where you can:

Save reports in a variety of formats (Excel, PowerPoint, HTML, PDF).
Distribute generated reports to e-mail lists (users who do not have access to Enterprise Manager, for example) on a defined schedule.

Click OK to return to the Consolidation home page.

42.4.2.2 Viewing Consolidation Scenario Reports

To view a project scenario report, select the host or database scenario within the project on the Consolidation home page and click the Report button above the table. The report page repurposes scenario details as stacked, scrollable tables representing the tabbed information that appears in the scenario's details on the home page.

Click Publish Report to capture report contents. This action integrates with BI Publisher, where you can:

Save reports in a variety of formats (Excel, PowerPoint, HTML, PDF).
Distribute generated reports to e-mail lists (users who do not have access to Enterprise Manager, for example) on a defined schedule.

Click OK to return to the Consolidation home page.

42.4.3 Managing Data Collections

Manage data collections by viewing the status of your host or database projects.

On the respective Consolidation home page select View Data Collection from the Actions menu.
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.

42.4.4 About Oracle Compute Cloud Shapes

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.

Name	OCPUs	vCPUs	Memory (GB)
OC3	1	2	7.5
OC4	2	4	15
OC5	4	8	30
OC6	8	16	60
OC7	16	32	120
OC1M	1	2	15
OC2M	2	4	30
OC3M	4	8	60
OC4M	8	16	120
OC5M	16	32	240

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