Blog

When you need to reduce the number of database servers, the worst thing to do is just pile ‘em all onto one and hope it goes well.  A successful virtualization or consolidation project involves a simple set of steps.

Inventory the existing SQL Servers and databases.  In a perfect world, we’d already have an up-to-date inventory of every database on every server including its OS version, SQL version, security needs, HA/DR plans, performance requirements, and more.  However, even good inventories are often missing a few key pieces required for a consolidation project – for example, compatibility lists for any third party vendor software installed on the server.  If we’re hosting a database for an ISV application, we need to know what versions of SQL Server the vendor supports.  I frequently see ISV apps that are no longer under maintenance or have been abandoned by the original manufacturer, and in those cases, we may not be able to move them onto a newer version of SQL.  In the video at the end of this post, I cover some of the attributes you’ll need to inventory.

Categorize them into groups by attributes.  After building our inventory, we can take a few steps back and look at similarities.  If we’ve got a lot of ISV apps that still require SQL Server 2005, don’t need high availability, and aren’t performance-sensitive, we can group them together.  If we find a lot of homegrown apps that are mission-critical and can’t wait to get onto the newest version of SQL Server, there’s another category.  These groups of databases often pop right out of the list once we see the big picture.

Ask the right questions to the right people. Talk to the application owners (business users) of each database to find out more about their long term plans.  When we need to merge multiple databases onto less servers, and we make our plans known to the business, we often discover hidden business requirements or budgets.  You’d be surprised how often people make money available to keep their own hardware, or decide they’d like to abandon a database altogether rather than deal with upgrade requirements.

Choose a consolidation method to meet business needs.  Some of our options include active/active clustering (also known as multi-instance clustering), virtualization, and cloud computing.  Each one has its own pros and cons, and I discuss these in the video below.

Build the new environment and load test it.  Before we run a single live production database on our newly created consolidation/virtualization hosts, we need to make sure they’ll be able to sustain as much throughput as possible.  CPU, memory, storage, and network should all be tested using both off-the-shelf hardware synthetic testing tools like CrystalDiskMark and database testing tools like restoring your own databases and running known processes against them.

Plan the right migration method for each databases.  We’ve got lots of options including copying the MDF/LDF files, doing a backup/restore, or performing log shipping or database mirroring to the new server.  Log shipping and mirroring give us the ability to migrate databases with a matter of a few seconds downtime, but require more work and planning up front.  Copying the MDF/LDF files or doing a backup/restore involves more downtime, but take less planning.  It all comes down to business needs.

Test the plan, work the plan, and monitor metrics to ensure success.  No matter what consolidation or virtualization method you pick, be very comfortable with your migration plan ahead of time.  You’ve got a new set of servers for the transition – why not test your plan several times first to make sure it’ll work on go-live day?  After the end users start logging in, know which performance metrics you’ll monitor to know if the app is working well or choking.  Ideally, you’ll even have a plan to mitigate performance issues as they come up.

In this video from our Tech Tuesday Triage webcast series, I explain two of these steps – building an inventory and choosing a consolidation method:

Download the zipped spreadsheet and the PDF version of the PowerPoint slides mentioned in the webcast.

If you want help virtualizing or consolidating your SQL Servers, contact us.  I’ve managed hundreds of SQL Server migration projects, and I’m completely comfortable helping businesses get out of end-of-lease hardware or out-of-support SQL Server versions.

↑ Back to top
  1. Great one Brent,appreciate your efforts.

    Please correct the download powerpoint link.Its downloading a pdf/excel file and pdf doesnt work.Seems a different file.

  2. Pingback: Something for the Weekend – SQL Server Links 30/09/11

  3. I think you HAVE to add somthing to the plan sheet , there is a big issues with consolidating DB’s with diffrent colletion becuse you end up sorting stuff on tempDB with diffrent collation and you get the nice errors about collation issues due to that .

    should have column with collation info next to the compatebility .

  4. Hi Brent I’m about to help my company migrate and virtualised servers into a Farm, but they use so far 3 different collation, what do I need to protect myself with for this please

  5. Good video Brent,

    What are your thoughts on consolidating using virtualisation and multiple instances? I have a client who wants to downsize their current SQL estate (hundreds of SQL VMs grown organically).

    Any recommendations for configuring min and max memory amongst multiple instances?

    Thanks

    • With virtualization, I recommend one SQL Server per Windows instance as I explain in the video. Then the min/max memory is managed just like you normally would for one instance.

      I would not recommend multiple instances of SQL Server inside the same guest (for the reasons I explain in the video.)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>