Upgrading and patching

Doug Burns writes, amongst other things, about a straw poll at a user group meeting on the number up to date on Oracle CPU patching. One of Doug's earlier questions was about the numbers that had all of their Oracle databases on 9.2.0.8 or 10.2. It would seem that two-thirds or so did not.

So what is stopping people upgrading to latest fully supported releases? Doug hit on some good reasons around the time and effort in adequately testing and planning an upgrade (along with need for a maintenance window to do the work) and the fact that upgrades aren't sexy in the eyes of IT business management. I think there is another reason that holds people back from upgrading and that is the need to maintain a fully vendor-supported application stack. In a way I am lucky, working with data warehouses (database is king) this issue affects me less than say someone managing SAP or even Oracle E-Business Suite databases (database is an information bucket), but that said, I have (or had depending when you read this) one customer tied to 8.1.7.4 because the business critical application running on the platform was written in a programming language that no longer exists and is not portable to a more modern environment because the language runtimes are trapped in a Windows 95 / Sequent Dynix / Solaris 6 timewarp. Likewise I had a client whose database platform (Siemens Pyramid) did not make it through Oracle's OS purge rationalisation that occurred when 9i first came out.

This need to maintain certified product stacks (OS, database, application) is a significant inhibitor in keeping up to date. In addition to the time needed to adequately test and plan a complex set of interdependent upgrades (across the whole application stack - and for some this involves desktop OS for clients and server side OS for database) there is the problem of finding a window to implement the work; businesses want zero downtime in business hours, and the more risk adverse organisations restrict the number of changes that can be implemented on a day; recently I managed the upgrade of a data warehouse to Oracle 10gR2 - the business owners would only permit significant upgrades to happen in a particular point of a four-week reporting window (as contingency in case of the need to back out) and the other planned changes scheduled and a freeze on change during November, December and January (peak trading time) meant that if we missed that two day window we would have to wait to February at the earliest for the next slot.

One aspect of data warehouse appliances (such as Netezza) that really appeals to me is that the OS and database are part of the single product - install an upgrade and both are upgraded, this greatly simplifies the upgrade and test process - it either works for you or it doesn't and if it doesn't work you don't go live; none of this having to see if the old database works with the new OS, or "what if we keep the old OS, add any required patches and then upgrade the database?" complexity - it is shame that this approach is not viable for platform independent databases (and here I also include MS SQL Server, as it runs on more than one flavour of Windows)

Doug once mentioned to me that we Data Warehouse folk always run the most recent releases of the database because of the need to use the most recent VLDB performance enhancing features, this is perhaps partially true, but Data Warehousers (or is that Data Warehomemakers?) can get away with upgrades as there is less of an application stack to worry about.