SQL on Call Show Available Now
The latest SQL on Call show is live now and you can watch it on the site – in today’s show Chris closes out the series of top 10 SQL Server thoughts about 2007.
Also available:
[Watch] SelectViews, the SQL Server Show – Keeping up with technology, Microsoft interviews and more.
Applying Updates? Not So Fast…
Several bits of additional feedback on whether you apply updates as they are available or are forced to wait (or ignore) those updates:
Pamela: "I completely disagree with your comments on applying service packs. We are a SQL Server 2000/2005 operation (not Oracle) and our major systems are supplied by Infor and Manhattan Assoc. Their applications are certified on a specific version/service pack. We cannot apply a different service pack without upgrading the applications. So, we only change versions and service packs when we do upgrades. This is true of SQL Server, operating system and other applications like Crystal Reports.
I’m sure we’re not alone!"
Bill: "I wrote and taught the applicable sections of the NERC Cyber Security Workshops. (NERC is the organization that sets the grid reliability standards for the electric power industry. Under FERC (Federal Energy Regulatory Commission) those standards have regulatory enforcement status.
Under those standards the patches that must be EVALUATED for application are only security patches. Patches released for any other reason than security are in the discretion of the system owner. Security patches themselves do not have to implemented, but the evaluation of those patches must state why they are not and what mitigation steps are being taken to otherwise address the issue the patch was supposed to address.
In my experience evaluating whether companies have the procedures in place to meet these requirements, SQL Server systems are MUCH more likely to be patched than Oracle. Most shops have, at a minimum, WSUS in operation. Patching Windows systems and Microsoft software is virtually automatic.
Oracle, however, is different. The automatic mechanism is not there and the Oracle application is more likely to have come from a vendor that is particular about their warranty. Oracle DBA’s will not apply a patch that could allow the vendor to claim the system is not supported under paid maintenance.
The landscape is changing on that however. The fines in this industry have not started kicking in yet for the cyber security standards. When they do, I expect pressure to be placed on these application vendors and the requirements of the standard to be included in future RFP’s and contracts."
Chris: "Another thing that gets in the way of installing service packs and hotfixes is uptime. With several other types of servers (DNS, print and file, Web servers, etc.) you can pull some of the servers out of the active pool or cluster, upgrade them, and bring the upgraded ones in while you let connections gracefully terminate on the others. Then, once the non-upgraded servers have been drained of connections, you can upgrade them and bring them back in. No downtime, no executive staff angst.
With database servers (to some extent even shared-disk parallel server technologies like Oracles) things just don’t work this well. In our case, we have made a significant investment in infrastructure, so that we have failover clusters that use database mirroring to push a redundant copy to a standby failover cluster. So that’s 4 computers comprising a single "instance." Yet, the best way to do a service pack or hotfix is to upgrade the mirrored cluster and then initiate a failover to it, and then upgrade the original cluster. During this process, the following things are true:
(a) There is a period of downtime, and the corresponding executive staff angst. This is often enough to stop the whole thing. We recently upgraded a major system to SQL 2005 SP2, but the one it replaced was running SQL 2000 build 818, which I think was not supported anymore. Why? Because it wasn’t broken, and executive (c-level) staff have to approve downtime in our organization, and they would not have it.
(b) After the failover, we need to reinitialize mirroring back to the original cluster. Until this happens, we still have data protection (because of backups) but we would need a long time to recover if something were to happen to the now-active cluster, maybe a whole day. This is more angst for everybody (not just the execs), and gives us good reason to hesitate.
I could go on, but you get the picture. With all the enterprise features of SQL Server, this is something they really need to fix. Upgrading a database cluster needs to become as safe and seamless as upgrading a Web farm. Until it is, our executives continue to (rightly) clamor for better solutions, sometimes considering moving us off of SQL Server altogether."
Featured White Paper(s)
Requirements for a Secure Database
This paper outlines the key business requirements most often identified as being essential for the deployment of databases co… (read more)
Whole Server Protection from a Single Solution
The complexity of traditional recovery solutions compounds an already difficult situation, and heightens the opportunity for … (read more)