Re: Policy on Oracle Versions and Patches
Date: Tue, 14 Oct 2008 09:09:21 -0700 (PDT)
On Oct 13, 4:47 pm, "Bob Jones" <em..._at_me.not> wrote:
> <ca111..._at_gmail.com> wrote in message
> > OK, I think we need to make a step back and look at Application
> > Lifecycle.
> > Basically I can see two types of applications:
> > 1. Strategic applications - somethink like ERP (Oracle Applications,
> > SAP), Billing System for a Telco, GL for a bank,
> > trading system for online broker.
> > Such applications tend to be very complex, heavily customized, take
> > long time to implement, and
> > don't get replaced very often. The vendor provides detailed
> > recommendations regarding Oracle version,
> > Patch Set, individual patches, init.ora parameters.
> > 2. Non-strategic application. This is something non-core to the main
> > business function, for example,
> > a Credit Check system. They tend to be much simple, often developed
> > for many RDBMS
> > (Oracle, DB2, Sybase, SQL Server), vendor does not provide detailed
> > recommendations regarding
> > version of Oracle, patch set, etc. Such applications get installed
> > and then run for 10 - 15 years
> > without major upgrade (they may get CPU, memory, or disk added). I
> > still have
> > a few systems running on AIX 4.3, Tru64 4.0D with Oracle 7.3.4.
> > They run fine, no-one wants to upgrade them as the whole application
> > will
> > be replaced or functionality migrated to another system.
> > For Strategic applications we follow vendor's recommendations - we
> > don't have a choice.
> > For Non-strategic applications we need to look at criticality:
> > - If a system is critical/needs to be up 24x7 then use 18.104.22.168
> > - If non-critical then either 10.2.0.4 or 22.214.171.124
> Even "Strategic applications" have multiple releases and each one can often
> work with more than one releases of Oracle. There are still choices.
It really depends. Even Oracle pissed people off by requiring an OS change with a point upgrade (7.3 on VMS, IIRC - I remember the shouting more vividly than the details). I just went through a major app/oracle/server OS/client OS upgrade where the app vendor required XP clients minimum, even though the upgrade docs said a lower version of windows would work. They hadn't finished the backport yet. And another part of the system turned out not to work on Itanium, some HP emulator that is supposed to let risc software work is overly limited. And the stuff to replace that part only works with the new version of the app software after some customization. And the new app software requires 10.x. And the effing virtualization software for XP has sudden death issues, that lock up app data because transactions are actually multiple transactions and have their own locking routines (a common thing in vulgar enterprise software).
Once you get past a certain level of complexity in the technology stack, choice becomes an expensive proposition requiring difficult trade-offs. And nearly every company now exceeds that level.
Welcome to the new world of non-determinism.
As to the original question of many databases and many apps, that leads directly to the answer: It depends on the requirements of each, and with that wide of a variety, you need to have a flexible and dynamic approach that can handle all of them. Trying to say something like "You vill be on the latest rrrrrelease, schwein!" just leads to internecine warfare and the view that the techies are unhelpful, at best.
-- @home.com is bogus. "DBMS_SPACE, in other words, is a crock of crapola and you don't want to touch it with an extended bargepole. You don't end up with locally managed tablespace using it: you end up with a weird hybrid sort of tablespace, that's locally managed on the surface, but inherits a bucketload of dictionary-managed nonsense too." - hjrReceived on Tue Oct 14 2008 - 11:09:21 CDT