Re: Policy on Oracle Versions and Patches

From: Bob Jones <email_at_me.not>
Date: Mon, 13 Oct 2008 18:47:39 -0500
Message-ID: <s6RIk.590$>

<> 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
> - If non-critical then either or

Even "Strategic applications" have multiple releases and each one can often work with more than one releases of Oracle. There are still choices. Received on Mon Oct 13 2008 - 18:47:39 CDT

Original text of this message