January 8, 2008 at 3:03 am
Hello,
I have following problem on our environment. I've read theat CU3 addresses issue with sp executed several times. Because we have busy application which can do this we are at risk that we will be affected by this issue. Our current level is SP2 and according to MS recommendation if you don't have problems described in list of fixes for CU you should wait for next SP release.
So now is the problem, to avoid this issue it will be good to set up CU, but which one?
CU3 which addresses this issue, or maybe the newest one or maybe the newest one - 1 treating this as a mature enough to go.
MCP ID# 1115468 Ceritified Since 1998
MCP, MCSE, MCP+I, MCSE+I, MCSA,
MCDBA SQL7.0 SQL 2000, MCTS SQL 2005
January 8, 2008 at 5:56 am
I typically wait for full service packs before I move to production unless there really is a pressing need to apply a CU. If you have the resources you could apply the CU in a dev or acceptance environment (this is where VMWare/MS Virtual Server shines) and see how it affects you. VMWare offers VMWare Server for free if you want to try it out. Yes I know I'm a VMWare whore but I can't help it, the products are too good lol.
=============================================================
/* Backups are worthless, Restores are priceless */
Get your learn on at SQL University!
Follow me on Twitter | Connect on LinkedIn
My blog: http://sqlchicken.com
My book: Pro Server 2008 Policy-Based Management
January 8, 2008 at 6:17 am
Yes we usually do this but now we are before SQL 2005 validation. I ask to validate SP2 build and now I'm thinking maybe its not a bad ide to go with CU as well.
MCP ID# 1115468 Ceritified Since 1998
MCP, MCSE, MCP+I, MCSE+I, MCSA,
MCDBA SQL7.0 SQL 2000, MCTS SQL 2005
January 8, 2008 at 6:41 am
Ah ok I think I'm understanding you a bit now. My personal take on that situation is if CU3 addresses your problem and the current release is CU4 then I'd apply 4 (or whatever the latest is). I figure there's a reason they release another higher CUX so might as well be proactive in the matter. Still do your due diligence and read all the documentation as well as make sure you have good backups and a restore plan just in case things don't go as planned on production.
=============================================================
/* Backups are worthless, Restores are priceless */
Get your learn on at SQL University!
Follow me on Twitter | Connect on LinkedIn
My blog: http://sqlchicken.com
My book: Pro Server 2008 Policy-Based Management
January 8, 2008 at 7:39 am
Have you taken the time to verify that you actually have the problem?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2008 at 7:53 am
I have no time to verify this and server is quite strong so we have alwayes a lot of available resources. It's more general question what's your idea about such patches.
MCP ID# 1115468 Ceritified Since 1998
MCP, MCSE, MCP+I, MCSE+I, MCSA,
MCDBA SQL7.0 SQL 2000, MCTS SQL 2005
January 8, 2008 at 12:26 pm
I currently work to a minimum of 3186 ( no idea where that fits between cu4 and cu5 ) but this is because I know it should fix particular issues that I've seen.
sp2 as it stands is pretty rubbish, but you should know if you have issues or know what is fixed by an update before you apply it. I'd suggest you apply it to your test systems first.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
January 8, 2008 at 12:29 pm
I agree with Jeff too - that's a pretty poor excuse, no-one can verify that your systems wouldn't have problems with a service pack or patch - that's what DBA's do for their own system. You should also be aware that there are a number of o/s patches that affect SQL Server, you should look at them too.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
January 8, 2008 at 12:49 pm
I like to stay fairly current, but if I couldn't thoroughly test, I'd wait for SP3. I would recommend if you have an issue fixed in a cumulative pack, get the latest one and test that before applying.
January 8, 2008 at 4:39 pm
Speaking of testing... if you value your production system, now would be a good time to setup a testing twin so you can do full regression testing of the SP prior to letting it anywhere near production. Plan now for SP3...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 9, 2008 at 1:03 am
Don't you see guys that approach: I wait for problems and then apply a patch is very bad. On systems which have very strict SLAs 99,999 for example you must pay a fee because you were waiting for problems. I think that reviewing list of fixes and applying patch just to protect system potentially against problem is right way to go.
If there is a fix in CU3 for following issue:
50001529 940945 (http://support.microsoft.com/kb/940945/) FIX: Performance is very slow when the same stored procedure is executed at the same time in many connections on a multiple-processor computer that is running SQL Server 2005
And your application has sps which are executed at the same time in many connections it sounds stupid to wait for problems and not apply a patch.
We are dbas and our job should be mainly focus to act pro-actively avoiding problems and not reactively causing damage to our customers and paying big fees for downtimes.
I see that this thread is very usefull and shows how urgent this problem is.
MCP ID# 1115468 Ceritified Since 1998
MCP, MCSE, MCP+I, MCSE+I, MCSA,
MCDBA SQL7.0 SQL 2000, MCTS SQL 2005
January 9, 2008 at 2:14 am
Since you have a SLA of 99.999, I assume you have a test/ R&D environment in parallel with the production environment. I agree to the proactive approach. Any required (= something that will fix a known issue) HF or CU released by Microsoft shall be tested through the various phases (regression/uat) and subsequently shall be rolled out to production.
Btw, anyone knows what are the plans for Sp3? Or is there a possibility that Microsoft will not release a Sp3 as SQL 2008 getting released?
January 9, 2008 at 7:32 am
berto (1/9/2008)
Don't you see guys that approach: I wait for problems and then apply a patch is very bad. On systems which have very strict SLAs 99,999 for example you must pay a fee because you were waiting for problems. I think that reviewing list of fixes and applying patch just to protect system potentially against problem is right way to go.If there is a fix in CU3 for following issue:
50001529 940945 (http://support.microsoft.com/kb/940945/) FIX: Performance is very slow when the same stored procedure is executed at the same time in many connections on a multiple-processor computer that is running SQL Server 2005
And your application has sps which are executed at the same time in many connections it sounds stupid to wait for problems and not apply a patch.
We are dbas and our job should be mainly focus to act pro-actively avoiding problems and not reactively causing damage to our customers and paying big fees for downtimes.
I see that this thread is very usefull and shows how urgent this problem is.
I absolutely agree... but you must also consider the costs associated with regression testing. If such a problem as 940945 arises, then yes, it's probably worth the cost. But these are "cumulative" fixes and, despite Microsoft's best efforts, they sometimes break stuff... look at 2k sp3... they had to immediately come out with sp3a because they broke stuff... we knew not to install sp3 because we tested and found out it broke stuff.
I absolutely agree with being proactive 100%... but you have to be very careful in a large production environment... ya gotta do regression testing and that costs time and money.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 9, 2008 at 8:56 am
I would wait for SP3 after reading your story because you have not prove to yourself that you actually have this problem in the first place.
If you do have this problem, I would copy this database to a Dev box or crash box with sp2 first to see how it does and then put in the database and run the test to see if I could force the same featured problem. If problem do come up, then I would install CU3 and retry my test again for a period of time. If the same issue cease to exist, then I would put it on my prod box after a period of time.
sopheap
January 15, 2008 at 3:45 pm
I'm a strong believer in keeping current with patches and fixes, to a certain degree relevant to what's happening with my servers, however I do go through a staged deployment, usually my own machines, dev, and then through test envs to uat etc before getting to production. Always have a backout plan ready!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply