SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


In-place upgrade to SQL server 2017


In-place upgrade to SQL server 2017

Author
Message
sqlfriends
sqlfriends
SSC-Forever
SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)

Group: General Forum Members
Points: 43532 Visits: 4676
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
Attachments
programs.docx (18 views, 66.00 KB)
Michael L John
Michael L John
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19446 Visits: 9741
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/
sqlfriends
sqlfriends
SSC-Forever
SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)SSC-Forever (43K reputation)

Group: General Forum Members
Points: 43532 Visits: 4676
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.
kevaburg
kevaburg
SSCoach
SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)SSCoach (15K reputation)

Group: General Forum Members
Points: 15456 Visits: 1280
sqlfriends - Friday, December 15, 2017 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.


+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
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search