January 31, 2012 at 9:50 am
I've run into a group of DBAs who apparently have a different approach to managing their sql server instances. What I've heard is they install the OS with latest SP and patches, do the same with sql server, then lock down the firewall etc so the only thing that can touch it is sql connections.
After that the OS is not patched again. I think sql may get patches.
This means no extra products like sql tools that connect via ports and require local agents or services. I suppose if you've locked it down that way then all the Microsoft Patch Tuesday releases could be viewed as unnecessary.
January 31, 2012 at 10:28 am
A locked down server doesn't make the service packs unnecessary. It'll help against security threats, but what about bugs that the service packs fix?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 31, 2012 at 10:40 am
Yes, seemed bizarre to me. Depends on what management wants I suppose. If up-time is more important than anything else, then..... Patches can be tested however, before deployment.
January 31, 2012 at 10:48 am
With database mirroring (or even clustering) you can do near complete uptime even with patching.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 31, 2012 at 11:41 am
*Shudders*
I've had to deal with this before. Every time I wanted to apply a SQL Sever SP or hotfix I had to download it to my machine, get our security guy to poke a temporary hole in our firewall so I could copy the file over to the server, then run the update, then close the holes back up. The network group had a much harder time applying OS updates, from what I was told anyways. It was the only solution I found to get around that mess. Removable media like cds and flash drives were a no go as well. In that instance, unless we decided to never patch the server, I'm not really sure what else we could have done.
January 31, 2012 at 12:10 pm
this type of environment is actually quite common. the thought process being the application is static, therefore the DB environment should be too.
I usually didn't let it bother me to much. When something breaks, and the cause is the DB, it is usually a documented issue that has a hot fix or patch to correct. However, issues almost never occur in those types of environments.
someone that makes those decisions probably has experience with a SQL SP breaking something.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply