Back in February, Jonathan Gennick asked me if I would be interested in writing a bit of content for an APRESS brochure to distribute at RMOUG Training Days. I thought it was a cool idea and chose the topic of database consolidation. I only needed 10 short tips but when I started to write, it was difficult to stop — clearly, expressing ideas in concise way must not be my strength.
Jonathan did heavy edits and turned my draft into 10 brief tips and, of course, quite a few details had to go as we shrank the size 3-4 times. Since I’ve already put my efforts into writing, I figured I could share it as well on my blog. Thus, welcome the first blog post from the series of database consolidation tips. Let’s get down to business…
While there are often multiple goals of a consolidation project, the main purpose of consolidation is to optimize costs which usually means minimizing the Total Cost of Ownership (TCO) of data infrastructure. Your current hardware might be past end of life, you might lack capacity for growth, your change management might be too slow, etc.
These non-core goals (for the lack of a better term for side effects of consolidation projects) can play a role of timing triggers but success of a consolidation project is defined by cost metrics. In real-life there are very few pure consolidation projects as project success criteria usually contain other conditions than cost cutting.
Tip: Keep costs at the heart of the consolidation project but don’t get blinded by cost alone! It’s a total failure if a consolidation project delivers a platform with much lower TCO but is unable to support the required availability and performance SLAs.
It’s also not very popular to run a purely cost-cutting project in a company — people are not overly motivated especially if it endangers their jobs. Luckily, most healthy businesses have quickly growing IT requirements and consolidation projects very quickly bust out of the scope of just cost savings.
Tip: Get your success criteria right and keep cost optimization as the core goal. If required, reduce the scope and split projects into stages where each stage has it’s own core goal. This way, you can classify some stages as purely consolidation. It’s so much easier to achieve success if there are only few criteria. You could also check mark success boxes constantly as you go instead of trying to get to the light at the end of the tunnel that could take years.
If you have anything to share on the scope of consolidation projects — whether past experience or current challenges — please, comment away.
During consolidation and virtualization projects it is very important to sync up HW requirements with your software stack before purchasing hardware.
Just one recent example from a client who is not exactly an Oracle shop, but they have number of Oracle instances brought in by their app vendors. The idea was simple, let’s buy few larger machines and virtualize plenty of our legacy machines on them. Neat and simple right? They purchased the hardware first,started with the machines ‘easy to virtualize’ and when it came to Oracle they needed somebody to do it for them. After reviewing their goals and glancing over their environment, it turned out they only have Oracle SE One licenses, so their brand new 8 CPU machines cannot host any of these databases because of the license limitation. Obviously there is one option – use Oracle VM and hard partition the machines, but that is not what was originally intended.
The learning point? If you are thinking about consolidation, have concise plan from the beginning for your entire stack and bring in experts from each area to glance over your intentions, otherwise TCO may go up, not down as intended.
Good point Lukas. I would generalize as “you need a better planning and if you don’t know what you are doing, hire somebody who does”. Sounds about right?
That’s right Alex. Plan, design and count before jumping on the virtualization bandwagon.