RE: Massive upgrades (WAS: Physical Memory Fully Used...)
Date: Tue, 23 Jun 2009 10:54:29 -0400
Message-ID: <C0A5E31718FC064A91E9FD7BE2F081B1021A3BB9_at_exchange.gridapp.com>
Right, and while I'm generally against changing multiple things at once, in this OP's case, he's got an old-as-heck database version running on an old-as-heck OS on old-as-heck hardware. If he'd wanted to upgrade the hardware, you can't buy new PA-RISC boxes from HP anymore, so he'd have to run Itanium. This would necessitate a new hardware architecture, and a new OS version, so he's already changing two things. In addition, 8.0.6 isn't supported on newer versions of HP-UX, so he'd be migrating platforms without the benefit of Oracle support - which means he might be better off upgrading the database at least to the oldest supported revision.
So - no matter what, the OP would have had to:
- change processor architectures - change OS version - change Oracle version
If you're gonna go through all of that hassle, you might as well just make that final jump and switch to a modern OS that's a mainline supported platform for Oracle, such as Linux.
And no disrespect meant to the OP, but I would say the real failure here is not having folks on your team with a strong enough background in Linux to be able to explain the difference between HP-UX's memory management and Linux's - for example, Linux's tendency to aggressively cache filesystem buffers, leading to potentially incorrect perceptions about free/used memory.
Thanks,
Matt
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rich Jesse
Sent: Tuesday, June 23, 2009 10:29 AM
To: oracle-l_at_freelists.org
Subject: Massive upgrades (WAS: Physical Memory Fully Used...)
>> It was a very bad decision to change everything at one time as well
(not
>> my
>> decision) --definitely not a best practice to change everything
without
>> testing, testing, testing and then testing again.
>>
>> --
>> Sandy
As with most things, it depends. I was on a project a few years back
where
the hardware, OS, and Oracle versions all were intertwined to the point
where upgrading one (the hardware) necessitated the rest. We needed to
upgrade the hardware, but the minimum OS version was well beyond where
we
were, and that OS version no longer was supported for our version of
Oracle.
And, of course, this resulted in requiring the complete recompilation of
all
~7000 ERP 4GL programs -- something we'd never done before. Did I
mention
that we implemented LDAP here as well?
In the three months our spartan IS team had to do this conversion there
was
a lot of testing, a lot of swearing, and a few tempers. But come
go-live,
the biggest issues we generally had were printer definitions not coming
over
to the new server and some security issues related to LDAP logins. An
informal survey of users I knew well were so happy with the speed of the
new
system that they didn't mind a half day with minor interruptions.
I wouldn't recommend changing everything at once (glibc dependencies can
be
a challenge to unravel!), but if it's required it certainly can be
accomplished.
My $.02,
Rich
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 23 2009 - 09:54:29 CDT