June 1, 2017 at 7:03 am
Hi,
I've noticed on multiple servers now that when I've upgraded from SQL Server 2014 to 2016 (regardless of the source and target editions), new folder structures are created (with the new build number) within the Program Files\SQL Server directory:
100
110
120
130
80
90
Client SDK
MSAS12.MSSQLSERVER
MSAS13.MSSQLSERVER
MSRS12.MSSQLSERVER
MSRS13.MSSQLSERVER
MSSQL12.MSSQLSERVER
MSSQL13.MSSQLSERVER
I suppose this makes sense, though I never gave it a ton of thought. My question is, are some of these MS%12.MSSQLSERVER now unnecessary and therefore can be deleted? They're not harming anything, but I don't necessarily like the clutter.
Any insights are appreciated.
Thanks,
Mike
Mike Scalise, PMP
https://www.michaelscalise.com
June 5, 2017 at 9:15 am
Hi
First thought is that in an ideal world you don't want AS and RS on the same machine as the database engine. Treat these as separate applications/services, so try and put these on separate machine(s) if possible.
This would lead me to suggest, uninstall these and then remove the directories. Install them on another machine(s).
Secondly, I'm guessing you have done an in-place upgrade? If possible, avoid this too, especially on a production instance. Once you've pulled the trigger, there is no stopping that bullet!!!
Are the directories empty? Or have you attached the databases to the new engine, instead of restoring them? If you have attached them then they will still reference the old directories.
If they are empty, and SQL Server 2014 is gone (i.e. you haven't stacked your instances), then they can be removed.
Or if you are unsure, and you don't like the clutter, and they are empty, just hide them via the folder options! 😛
Hope that helps
June 5, 2017 at 9:21 am
Thanks for the info.
You're correct--I have done an in-place upgrade. Why would you avoid this? If I uninstall and re-install, I'll need to configure the entire instance again and risk missing something, correct?
To answer your other question, yes, the directories are empty--there's no databases tied to the old directory structure.
Thanks,
Mike
Mike Scalise, PMP
https://www.michaelscalise.com
June 5, 2017 at 9:40 am
The problem with in-place upgrades is that it can be a nightmare to rollback the upgrade, not to mention the interruption to applications should the upgrade not go smoothly.
Clearly, it can be done, however to mitigate the risk of downtime on a production instance, it is better to do a "side-by-side" upgrade. This way it can be tested, and you also get the chance to do other upgrades (e.g. o/s).
In the days of virtualisation (if you are using it), it's easy enough to start up a new vm and create a new instance on this.
I may be worthwhile scripting out all the configuration changes you make, and make yourself a little script. If T-SQL isn't your bag, then just script all your changes out using the 'Script Action to New Query Window'.
This way, when you do upgrades in future, you can mitigate the risks of missing something out like you said.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply