June 13, 2019 at 3:59 pm
I have been working on collecting the list of SQL Servers and found 50 plus servers and noticed that most of them are on SP1(SQL2014 and SQL 2016) so planning to apply SP2 accordingly to all SQL Servers. However, installing the service pack without the real need is a good practice? Do i come into any issues? Please advise?
June 13, 2019 at 4:12 pm
It's good practice to keep the instances up to date with service packs. If you patch those to SP2 you will still be behind on service packs for the 2014 instances - apply SP3.
Sue
June 13, 2019 at 4:17 pm
So you think there won't be any issues applying service packs,so no much testing is required like we do for the upgrade right? So i can skip the service pack as well, i mean if i am on SP1 i can skip SP2 and go for SP3 directly you mean?
June 13, 2019 at 4:29 pm
Do you think all the vendor application or application would support the new service packs? I guess the application would not break with service packs right?
June 13, 2019 at 4:34 pm
I've always run them for a bit in lower environments before rolling them out to production. Nothing intensive for testing, usually just applying and making sure everything runs the same, no issues arise. If you need one of the fixes in a service pack then that's usually tested though.
Service Packs are cumulative so you can skip and just apply the latest.
Vendors often don't care about service packs but I've always just double checked with the vendor - and usually by email so I have whatever their stance is documented. You don't want to apply one if it's not supported by the vendor.
Sue
June 13, 2019 at 5:27 pm
Do you think all the vendor application or application would support the new service packs? I guess the application would not break with service packs right?
That is a question that you need to ask each vendor - for all vendor supported systems.
In most cases - there should be no negative impact on the application, but it is possible that a service pack introduces an issue for the application.
The vendor should be able to tell you whether they have tested against that release - or not. If they haven't tested and certified their application against that release - then you need to follow up further with that vendor. In some cases, the vendor will not allow you to upgrade until they have certified - in other cases, they will tell you they may require you to downgrade if there are issues.
I have had vendors state that upgrading to a non-supported/certified SP or CU would break the support agreement. You need to make sure each vendor signs off on upgrading SQL Server.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 13, 2019 at 5:31 pm
Thanks Sue! I really appreciate it for the response.
Another question which is not related to above, I did put this in the forum and did not get any response so checking if you can suggest or advise?
There are not currently any DACPAC deployment options, and I was hoping to find out what the "right" way to start managing a new SQL database we have is going to be, I am wondering about managing the database using a dacpac project, I want our devs and QA to be able to use a dacpac that is in sync with the server, and then use the project to allow devs and QAs to use scripted data in that project to set up data in a DB on their own machine, and run tests against that, before deploying and testing on any of the servers. That would greatly speed up our ability to get projects done and test certain troublesome data scenarios. So it would be something new. I think there's an additional role that the deploy process needs, in order to be able to do the compare, so the object changes can be scripted. Please advise?
June 13, 2019 at 7:10 pm
Thanks Sue and Jeffery! Do you have any input on the above question or you need any additional information?
June 13, 2019 at 7:13 pm
DACPACs will work fine and the tools needed to do all of it are there but it requires a skill set. I don't think it's something where you can just tell the developers "start using DACPACs for all the deployments". It takes time for everyone to get up to speed with using them, what the options are and how to use the production database as the target and not doing comparisons with previous DACPACs. And make sure everyone knows all the options...including things like DacDeployOptions.ScriptDatabaseOptions = false
If you want to go that direction, create some type of sandbox environment for practicing the deployments and different types of changes so that everyone gets familiar with the process. Otherwise, what I've seen is it seems to just be disasters. It's not a slam on developers. They should be given the time and an environment to play with it and understand the details of how it works. I don't think they are given that opportunity often enough.
Sue
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply