Re: Policy on Oracle Versions and Patches

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