October 18, 2017 at 12:44 pm
We have a 2012 windows server with SQL 2012 installed. . Can we install SQL 2016 on the same server in a separate partition?
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 18, 2017 at 2:15 pm
You can. That is actually how we have things running where I work. I have SQL 2008 R2, 2012 and 2016 all running on the same box.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 20, 2017 at 3:11 pm
Good news. We install the core components on the C drive and the database instances on separate partitions. The SQl 2008 instance is already in place.
When installing sql2012, do I continue to use the existing folders on the C drive for the core components?
This means the core components for SQl2008 and 2012 would share the same folders on the C drive. In our environment, the instances would be maintained on separate partitions. Does this sound right?
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 20, 2017 at 3:15 pm
You see I want to be certain I don't corrupt the sql2008 environment when I install sql2012.
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 20, 2017 at 3:51 pm
I would install things into separate folders. We generally install the shared stuff into the default folder (which is then separated by version) and the database files onto separate physical disks. Putting it on separate partitions is pointless and won't improve performance but can reduce scalability.
If this is a VM, I would do a snapshot of it first. If it is a physical machine, I'd do a full backup of things first.
Even though you can have multiple versions of SQL on a box, any new software install introduces risk to the environment.
If you are not comfortable with adding the SQL instance, I would recommend replicating your setup as best as you can in a VM and then add the new SQL instance and just see what happens. I know we have 3 different versions of SQL on 1 physical machine. Shared components installed in the default directory.
The only thing you need to remember is that you can only have 1 default SQL instance on a box. The others need to be named instances. I am fairly confident that that is correct anyways... We don't use any default instances where I work; everything is a named instance.
And you will have to reboot after you install the SQL instance. So make sure you account for that downtime. Well, you don't HAVE to, but it is recommended.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 20, 2017 at 4:04 pm
I'll do a full backup. Certain components will be upgraded to SQL2016 and there is a risk this will affect the application. It is a VM but we don't want to create a new server to test this thing. That would be my preference. I'll have to reply on the backup to save my bacon.
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 20, 2017 at 4:18 pm
Yep. I'd do a full backup and since it is a VM, I'd do a snapshot as well. It is a lot faster to restore from a snapshot than a backup. Just make sure to remove the snapshot if things go well.
I'm not sure which components would get upgraded unless you are doing an upgrade install. That'll upgrade components. But our shared components for 2008R2 are still in 2008R2. Our shared components for 2016 are in 2016.
Are you doing an upgrade? I thought you were spinning up a new named instance?
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 20, 2017 at 4:25 pm
And yes we want a new sql2016 instance on that server. If the upgraded components are maintained separately as you suggest, that is good news.
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 20, 2017 at 4:33 pm
Right... forgot about some of those things. SQL Server Browser service would be one of the things upgraded but won't harm anything with that being upgraded.
As long as you have a VM snapshot though, rolling back should take maybe a minute or 2 if things go badly. If you have a backup, it'll be a little longer, but shouldn't be horrible either.
Keep us posted as to how it goes. I know I've done a ton of these types of installs without a single hiccup. Well, minor hiccups due to me having settings wrong in my templates, but that is what the logs are for.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 24, 2017 at 2:07 pm
How'd the install go? Are you happily running SQL 2008 R2 and 2016 on the same machine?
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
October 24, 2017 at 2:49 pm
No, some mitigating factors forced us to cancel this project. We decided it was best to do the 2016 install on a small separate VM.
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply