Re: Policy on Oracle Versions and Patches

<ca111026_at_gmail.com> wrote in message
news:2adbd803-ac17-427e-ac84-2d5d35908c14_at_u29g2000pro.googlegroups.com...
> 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 9.2.0.8
> - If non-critical then either 10.2.0.4 or 11.1.0.7
>
>

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