This is the first part of a series on Oracle database consolidation. In the second part, the author shows how to do database consolidation using session schema management.
If you’re like most companies, the success of more than two decades of mid-range relational database deployments has created an IT dilemma -- a lot of databases and an increasing total cost of ownership (TCO). The good news is that industry consolidation trends apply to the database too. Better yet, the Oracle database provides several strategies to enable multi-tenancy and thereby reduce the total number of databases.
Evolution of Oracle database sprawl
First, a little bit of history. Let’s ask ourselves how this got out of control. You could argue that line-of-business separation, budgeting, chargeback, security, acquisitions and performance concerns all played a part. But the biggest reason is much simpler: It’s just so darn easy to create a database. In fact, Oracle has made it so simple that you can now create a database and be up and running in minutes.
The proliferation of databases, sometimes referred to as database sprawl, is expensive and difficult to manage. It’s not uncommon to find one database per application per software development lifecycle (SDLC) environment. Think about it. If you have 10 applications each with a development, test, quality assurance, performance, training and production environment, you have 60 databases! It’s no wonder why many organizations find themselves with hundreds of databases and ever increasing costs.
This phenomenon is true whether you’re running dedicated physical hardware and software silos, virtualized database platforms or database grids. In each case database instances, sized to meet peak demands regardless if they are busy or idle, allocate and consume memory, CPU and storage resources.
Time to consider database consolidation
Today, most organizations have embraced server and storage consolidation which put more databases on fewer physical servers and storage systems. Surprisingly, few organizations are taking the next step of database consolidation and maybe missing an opportunity to further reduce cost and gain efficiency.
Database consolidation is nothing more than reducing the total number of databases by pooling and sharing database resources. The benefits of database consolidation are similar to server and storage consolidation -- lower cost, reduced complexity and greater agility. Cost savings include both capital expenses for server, storage and software licensing and operational expenses for maintenance, management, energy and space. Complexity is reduced through fewer configurations and services as well as operating system and database version standardization. Greater agility is realized through rapid provisioning and response resulting in quicker time to market.
As with most solutions, there are no absolutes. Database consolidation may not be a good fit for vendor packages which require particular patch levels and applications which require complete physical isolation. However, for the majority of databases, consolidation makes good sense. Some guidelines for consolidation include applications with similar service level agreements, complimentary mixed workloads, SDLC environments and single application cloud services.
As organizations continue to look for opportunities to reduce cost and gain efficiencies, database consolidation can offer significant savings and simplicity. Understanding that database consolidation will require a paradigm shift from database isolation to database sharing is the first step. My advice is to figure out the right consolidation level for your organization, start small and consolidate over time.
About the author:
Jeff McCormick is an architecture director at a major health service company and president of the Connecticut Oracle User Group. McCormick has worked in IT for more than 20 years as a data and infrastructure architect/administrator. He holds several Oracle, Microsoft and Sybase professional certificates.
This was first published in December 2011