Posted by: Peter Scott | October 28, 2007

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.

About these ads

Responses

  1. Testing and having sufficient coverage to have realistic confidence is a big issue, I think. I’m not sure that I’m seen anyone “do” this particularly well. Many eventually just take a suck-it-and-see approach.

    I wonder how significant it is that a vendor software upgrade is a vendor/in-house systems/DBA-led change rather than the application owner / development manager accepting the normal risks of driving standard development changes through.

    Hmmm… thinking on the hoof, I wonder whether a data warehouse development environment is maybe more in control of the bigger picture than many “normal” OLTP databases where, in my recent experiences, it’s not uncommon that everyone’s doing their own thing, no-one is in design control, no-one cares about the big picture and the system has been left off the leash. Therefore the risk is that much bigger. I dunno, I’m babbling now.

  2. the need to maintain a fully vendor-supported application stack.

    Spot-on Peter. In that particular blog I was focussing on CPUs, but the reality is that most sites I work with also have a number of very old versions in place. Why? Because the application vendors are so slow to certify on new versions of Oracle and, frankly, I think it’s a disgrace. They’re in the software business, selling applications to big companies and yet, through a combination of their customers cutting them far too much slack and a lack of professionalism on their own part, they don’t keep up with the times. Well, when you’re going to be an ‘efficient’ modern business, you have to cut costs where you can, right?

    I’ll give you one very recent example. We’re trying to try to patch all of our 9i databases to 9.2.0.8. One of the applications is only certified on 9.2.0.3! In my opinion, the vendor should be forced to do something about that (and, believe me, I’m not shy about pointing out the risks to the business), but they just mumble about optimiser issues that they hit in 9.2.0.7. I don’t give a monkey’s – it’s for them to fix on behalf of their customers.

    Can you tell I’m getting sick of this? ;-)

    but Data Warehousers (or is that Data Warehomemakers?) can get away with upgrades as there is less of an application stack to worry about.

    I tend to agree. The likes of Peoplesoft upgrades make me shiver. I also think (he said, ducking very low) that Data Warehouses might be big and do a few very complex things, but they tend to have smaller user communities, lower business impact if they’re not available and have (and now my grin is appearing) ludicrously large teams dedicated to baby-sitting a database or two ;-)

  3. but they tend to have smaller user communities, lower business impact if they’re not available
    Yes, DWs are the most business critical non-critical application :-)
    True, if the DW was not available a company could still continue to trade, but the user community of often influential business people would feel lost without the insight [am I pretentious here?] In other words IT management get the kicking if the DW is down, but not the budget to keep it up.

    As for team size – All of the DWs that we host are supported by the general DBA pool – not DW specialist DBAs. I have the specialists in my team ;-)

  4. often influential business people

    That’s the key for me. The DW, or rather the results gleaned from it, tend to very important to very important people. Maybe that’s why they’re viewed as an unaturally significant part of the IT systems ;-)

    I just won’t let it lie, will I? ;-)

  5. I, for one, enjoy being unaturally significant :-)

    BTW, I know you really want to be a “DW DBA”; Doug; but are just not ready to stand up in a room and say: “I’m Doug and I do big databases” ;-)

  6. I know you really want to be a “DW DBA”; Doug;

    Maybe I am, but don’t need to talk about it ;-)

  7. [...] Scott responds on his random notes. In his opinion, “(the) need to maintain certified product stacks (OS, [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: