2

I know that SQL SERVER 2016 can co-exist with previous versions on the same server. I wonder however if there are any gotchas that I should be aware of? We have a test server that already has 2008r2, 2012 and 2014 instances on it. Is there any chance that there are anything on the existing instances that will behave differently if we install 2016 also on the same server?

  • Your production server having 3 different versions and instances for SQL Server is uncommon so sometimes you might face an edge case scenario when you mix many versions. Outside of those cases there aren't any blockers from letting you do it just like you could upgrade Windows 3.11 to Windows 10 but it often isn't best practice – Ali Razeghi Nov 17 '16 at 22:15
  • @AliRazeghi Thx for your comment. Just to clarify, this is a server used for testing. But I agree that a prod server with so many different versions are uncommon. The reason we do this on the test server is that we cannot have test servers for each production environment, hence my question..in case the testing will become less reliable. – GHauan Nov 17 '16 at 22:28
  • 1
    It sounds like your business might have to make a decision on how far they are willing to deviate from prod in QA on a system/OS/app level. In a case like this it would make sense to have to do this, just noting it's not going to be like that in prod. – Ali Razeghi Nov 17 '16 at 22:30
  • It'll work fine but is there a reason why you aren't using VMs on the same host? I have anywhere between 1 to 4 versions on a machine/VM depending on what I'm working on. The engine processes are isolated so as long as you have sufficient resources on the host, they'll run fine. Memory and CPU are easy to carve out, storage takes a bit more work. Perfmon/Sysmon also gets a bit cluttered and if you're not using templates, it's easy to accidentally monitor the wrong objects (no such problem with xevent/dmv). VMs makes all of this a little easier. – SQLmojoe Nov 18 '16 at 18:33
3

Each instance is a separate service with its own set of folders, system databases, agent and binaries so they do not directly impact each other. All of the instances, however, will share the management tools, and older versions of the management tools cannot manage newer instances. You can avoid trouble by installing the oldest version instances first and install the newest version last. This way SSMS, SSCM, Profiler, etc will be the 2016 version and capable of managing all previous versions.

Another thing to consider is your Max Server Memory setting. You want to make sure that the combined total of all your max server memory settings minus the total memory in the box, will still leave enough memory for the operating system and other applications.

The last thing I would consider is your CPU. It is possible for instances of SQL to so consume resources that another instance could effectively be 'starved'. A work around for this is to set affinity mask so that each instance is assigned a set number of CPU.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.