Consolidation of multiple databases onto a shared infrastructure is the next step after Standardization. The potential consolidation density is a function of the extent to which the infrastructure is shared. The three models provide increasing degrees of sharing:
Server: each database is deployed in a dedicated VM. Hardware is
shared, but most of the software infrastructure is not. Standardization
is often applied incompletely since operating environments can be moved
as-is onto the shared platform. The potential for VM sprawl is an
additional downside.
Database: multiple database instances are deployed on a
shared software / hardware infrastructure. This model is very efficient
and easily implemented with the features in the Oracle Database and
supporting products. Many customers have moved to this model and
achieved significant, measurable benefits.
Schema: multiple schemas are deployed within a single
database instance. The most efficient model, it places constraints on
the environment. Usually this model will be implemented only by
customers deploying their own applications. (Note that a single
deployment can combine Database and Schema consolidations.)
Customer value: lower costs, better system utilization
In this phase of the maturity model, under-utilized hardware can be used to host more workloads, or retired and those workloads migrated to consolidation platforms. Customers benefit from higher utilization of the hardware resources, resulting in reduced data center floor space, and lower power and cooling costs. And, the OpEx savings from Standardization are multiplied, since there are fewer physical components (both hardware and software) to manage.
Customer value: higher productivity
The OpEx benefits from Standardization are compounded since not only are there fewer types of things to manage, now there are fewer entities to manage. In this phase, customers discover that their IT staff has time to move away from "day-to-day" tasks and start investing in higher value activities.
Database users benefit from consolidating onto shared infrastructures by relieving themselves of the requirement to maintain their own dedicated servers. Also, if the shared infrastructure offers capabilities such as High Availability / Disaster Recovery, which are often beyond the budget and skillset of a standalone database environment, then moving to the consolidation platform can provide access to those capabilities, resulting in less downtime.
Capabilities / Characteristics
In this phase, customers will typically deploy fixed-size clusters and consolidate on a cluster until that cluster is deemed "full," at which point a new cluster is built. Customers will define one or a few cluster architectures that are used wherever possible; occasionally there may be deployments which must be handled as exceptions. The "full" policy may be based on number of databases deployed on the cluster, or observed peak workload, etc.
IT will own the provisioning of new databases on a cluster, making the decision of when and where to place new workloads.
Resources may be managed dynamically, e.g., as a priority workload increases, it may be given more CPU and memory to handle the spike.
Users will be charged at a fixed, relatively coarse level; or in some cases, no charging will be applied.
Activities / Tasks
Oracle offers several tools to plan a successful consolidation. Real Application Testing (RAT) has a feature to help plan and validate database consolidations. Enterprise Manager 12c's Cloud Management Pack for Database includes a planning module.
Looking ahead, customers should start planning for the Services phase by defining the Service Catalog that will be made available for database services.
