Migrate a single database from physical to VM and from SQL 2005 to SQL 2014

  • Hello,

    I'm planning to migrate a single database from SQL 2005 to SQL 2014 from physical to VM. I checked the memory usage of the databae and how many processors in the server.

    is there a check list for specific to single database migration that i need to check before migrating to VM ?  I know how to migrate, all i'm looking is to determine if it's a candidate for VM.

    Especially for IO throughput, what should i consider moving it to a VM ?

    Thanks in advance.

  • Robin35 - Friday, January 27, 2017 9:15 AM

    Especially for IO throughput, what should i consider moving it to a VM ?

    The fact there will be a storage overhead, there's no such thing as a free lunch.
    Placement of VM hard disks will be crucial and should be decided in conjunction with your virtualisation team

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Do a search on Microsoft's and your virtualization vendor's site for best practices for hosting a SQL Server. For migrating a database itself, there is nothing special. SQL sees a Windows box regardless of whether or not it is physical or virtual.

    However like Perry stated there are specifics in the virtualization environment that are critical to ensure you do not end up worse then where you are now. Top ones that I can think of (these are based on a VMWare environment):

    - Get thick provisioned vmdks
    - Get isolated vmdks that do not get VM snapshots
    - Try to ensure the LUN the vmdks are sitting on are not getting SAN snapshots
    - Try and get on a VM host that will ensure a 1:1 physical:virtual CPU ratio. Otherwise you risk CPU ready while the host tries to allocate the number of CPUs your VM needs at once. The more vCPUs your VM has the more you might risk waiting for those CPUs to be provided
    - See if the host has enough memory to prevent memory ballooning

    Joie Andrew
    "Since 1982"

  • Joie Andrew - Friday, January 27, 2017 1:39 PM

    Do a search on Microsoft's and your virtualization vendor's site for best practices for hosting a SQL Server. For migrating a database itself, there is nothing special. SQL sees a Windows box regardless of whether or not it is physical or virtual.

    However like Perry stated there are specifics in the virtualization environment that are critical to ensure you do not end up worse then where you are now. Top ones that I can think of (these are based on a VMWare environment):

    - Get thick provisioned vmdks
    - Get isolated vmdks that do not get VM snapshots
    - Try to ensure the LUN the vmdks are sitting on are not getting SAN snapshots
    - Try and get on a VM host that will ensure a 1:1 physical:virtual CPU ratio. Otherwise you risk CPU ready while the host tries to allocate the number of CPUs your VM needs at once. The more vCPUs your VM has the more you might risk waiting for those CPUs to be provided
    - See if the host has enough memory to prevent memory ballooning

    Thanks Joie for the details. I have migrated so many SQL instances from physical to VM, i have also migrated a single database too but this particular database is very IO intensive and management has decided to move this to VM. So i'm not concerned about memory or memory ballooning issue or vCPU count .....in case of any issues we can always increase or reduce the memory of vcpu's but the problem is how can we make sure the database performs well with IO in virtual environment. With your suggestions, i will do more research and apply as required.

    Thanks for your suggestions.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply