Re: Policy on Oracle Versions and Patches
- From: joel garry <joel-garry@xxxxxxxx>
- Date: Tue, 14 Oct 2008 09:09:21 -0700 (PDT)
On Oct 13, 4:47 pm, "Bob Jones" <em...@xxxxxx> wrote:
<ca111...@xxxxxxxxx> wrote in message
news:2adbd803-ac17-427e-ac84-2d5d35908c14@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
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.
jg
--
@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." - hjr
.
- References:
- Policy on Oracle Versions and Patches
- From: ca111026
- Re: Policy on Oracle Versions and Patches
- From: sybrandb
- Re: Policy on Oracle Versions and Patches
- From: ca111026
- Re: Policy on Oracle Versions and Patches
- From: Vladimir M. Zakharychev
- Re: Policy on Oracle Versions and Patches
- From: Bob Jones
- Re: Policy on Oracle Versions and Patches
- From: Vladimir M. Zakharychev
- Re: Policy on Oracle Versions and Patches
- From: Bob Jones
- Re: Policy on Oracle Versions and Patches
- From: Vladimir M. Zakharychev
- Re: Policy on Oracle Versions and Patches
- From: Bob Jones
- Re: Policy on Oracle Versions and Patches
- From: ca111026
- Re: Policy on Oracle Versions and Patches
- From: Bob Jones
- Policy on Oracle Versions and Patches
- Prev by Date: Re: Ref cursor in stored proc
- Next by Date: Re: how do i split a string
- Previous by thread: Re: Policy on Oracle Versions and Patches
- Next by thread: Re: Policy on Oracle Versions and Patches
- Index(es):
Relevant Pages
|