So you've been successful in convincing your company that database consolidation makes sense. Now comes the creative task of establishing a consolidation strategy. I say "creative" because database consolidation is as much an art as it is a science.
There are many factors that shape consolidation. I call these factors consolidation levers. Each combination of selected levers and their specifications will define a unique consolidation model. Examples of consolidation levers include platform and operating system; database version, options, character set, service tier and performance; line of business and software development lifecycle environment; application; and workload.
Most database consolidation strategies will likely employ several different models to achieve fewer physical databases, higher density and lower operational overhead. The sum of the models will define your consolidation strategy (Figure 1).
Let's walk through an example of defining a consolidation model and identifying qualifying databases. First, select desired levers and define a specification for each (Figure 2).
Next, if you don't already have a handle on your databases, you'll need to profile them against the selected levers. Finally, use each lever to filter out databases that don't meet the lever specification (Figure 3). Qualifying databases are the intersection of the filtered levers.
Tip: Create a database table with a row for each enterprise database and columns for each consolidation lever. Defining a model and identifying qualifying databases is a simple query using the selected levers as predicates.
The next step is to determine a deployment plan. Here you will determine how many physical database servers or containers you will need to implement the model. This is accomplished by mapping qualifying databases to specific model containers. There are several factors that influence deployment:
- Service-level agreement and contract constraints
- Server constraints such as CPU and memory limitations
- Database constraints such as 252 maximum "pluggable" databases
- Database compatibility such as the use of shared resources and scheduling
- Database size
- Database management such as the duration of container-level administrative activities
- Database priority relative to other databases
Now that you have defined your models, identified qualifying databases and determined a deployment plan, the final step is to ensure quality of service (QoS) for each container's tenants, referred to as "pluggable" databases. QoS is implemented with Oracle's Database Resource Manager. Resource management ensures that logically separated but physically integrated "pluggable" databases receive fair and predictable performance.
As you can see, your database consolidation strategy will require creativity. That being said, don't over think it. My advice is to keep it simple and attempt to standardize on a manageable set of models and containers. If you need to make adjustments, simply unplug and plug your databases into a better container and/or model. Over time, as you get more comfortable with Oracle 12c's multi-tenant option, you will most likely become more aggressive and simplify your consolidation strategy, bringing greater benefits to both your IT and business organizations.
About the author
Jeff McCormick is an IT senior principal at a major health service company and former president of the Connecticut Oracle User Group. Jeff has worked in IT for more than 20 years as a data and infrastructure architect/administrator, focusing the last 5 years in enterprise business intelligence and information management.