December 15, 2017 at 10:33 am
I am trying to do a in-place upgrade of our test SQL server from 2014 to 2017.
After in-place upgrade, there are a lot of older versions of SQL server tools exists. I uninstalled SQL server 2014. But still a lot left. See attached.
for example older version of SQL server management objects , native client.
Older version of visual studio shell for 2012, 2013, 2015.
Older version of CLP types,
Also for Utility of dtcexe.
This is the drawback of doing in place upgrade. Older footprints still exists.
Some of the older version may be still used by newer version tool. So I am concerned by unintall them causing other issues of newer version of tools, and then hard to isolate for troubleshooting.
Any idea that above products, esp, visual studio shell, cisul studio tools for application (this we don't use at all) are safe to uninstall and not causing issues of newest version of tools?
Thanks
December 15, 2017 at 10:38 am
Is this a production server?
What you are finding out is why doing in-place upgrades is less than desirable.
Honestly, without a lot of trial and error, I would probably give up and start from scratch. It will be faster and certainly easier to re-install the entire server from scratch.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 15, 2017 at 10:47 am
I agree doing it from scratch to 2017 is the best and clean approach.
I am currently doing the upgrade process in a test environment, and later will do it on production.
Our production server is a very robust physical server, test environment is a VM.
We want to reuse the physical server and we don't have another good physical server available to do this at this time.
So in the case we chose in-place upgrade.
That is the reason I posted the questions.
Thanks.
December 25, 2017 at 4:41 am
sqlfriends - Friday, December 15, 2017 10:47 AMI agree doing it from scratch to 2017 is the best and clean approach.I am currently doing the upgrade process in a test environment, and later will do it on production.
Our production server is a very robust physical server, test environment is a VM.We want to reuse the physical server and we don't have another good physical server available to do this at this time.
So in the case we chose in-place upgrade.That is the reason I posted the questions.
Thanks.
+1 to doing a clean Installation but this is one upgrade that needs more than a test of the migration process. Have you considered the effects of new features such as the "improved" cardinality estimator? I point that one out in particular because it may have different effects on different databases and these effects are not always consistent across the instance landscape.
Perhaps I have spoken somewhat out of turn and you have considered this already but IMHO, a DBA that is considering an in-place migration most probably hasn't considered other implications not necessarily related to the migration process itself......
Regards,
Kev
September 5, 2018 at 10:12 am
If you have to do in place, do you have the down time to backup all the databases, script out logins (with SIDs) and jobs, all to a network share, re-install windows, install SQL Server, run the login and job scripts and then restore the databases.
September 7, 2018 at 2:42 am
For the tools, SQL Server 2017 has separated the tools install from the server install. If you need the new tools, you have to track them down separately. Here's a link.
I agree with the others, in-place upgrades can be quite problematic. Side-by-side is safer and easier.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply