Sunday Sep 23, 2012
Sunday Sep 09, 2012
By B R Clouse-Oracle on Sep 09, 2012
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
- 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.
The Database Cloud Architecture Team at Oracle develops and documents best practices for designing and delivering database consolidation and database-as-a-service projects.
- New white paper: Fast Application Notification (FAN)
- New data sheet for Rapid Home Provisioning
- Upcoming Conferences
- Cross-Site Load Balancing - Prerequisites and Steps to Be Performed
- New whitepaper: Cross-Site Load Balancing: Data agility with Oracle Multitenant: A Proof of Concept
- RHP Use Cases Series: Create a Gold Image from the Patched Working Copy
- RHP Use Cases Series: Switch an active database to a Patched Working Copy
- RHP Use Cases Series: Provision a New Oracle Home plus DB Creation
- Compare and Contrast (and mix-n-match) Oracle's SPARC V12N choices
- RHP Use Cases Series: Provision a New Oracle Home