GridApp dbConnections: October 2009

I was amazed that in a roughly twelve month period, the largest open systems database players, namely Oracle and Microsoft, have once again introduced major changes to their patching methodologies. So much for anyone that has attempted to automate this process on their own as most of that work will now need to be thrown away. It seems the days of leaving critical systems unpatched, the most common behavior of database administrators, are long gone; unless your business doesn't care about protecting its most valuable asset. How does an IT organization cope?  More>

The new patch on the block is causing problems. The release of the first Patch Set Update (PSU) has brought a whole new level of complexity to managing Oracle database patches. The most significant change comes from the fact that each PSU contains a large number of bug fixes and therefore an increased chance for patch conflicts with existing installed patches. Managing divergent sets of patches on many systems is getting more difficult. The likelihood that a patch you are installing will conflict with a patch already applied is increasing. To prevent the maintenance nightmare that is becoming more painful by the day, it's critical that a standard set of patches be deployed except in the case of special requirements, hopefully limited to a small set of environments which can get special attention.  More>

When a new database version is released, a great deal of press and marketing ink is spent on discussing the latest features of that database. These usually include functionality around data, such as analytics, performance, and scalability enhancements. Functionality around less "sexy" administrative features, such as patching, rarely gets the same level of attention. With SQL Server 2008, however, the patching enhancements Microsoft has made are themselves very interesting.  More>