RE: Massive upgrades (WAS: Physical Memory Fully Used...)
Date: Tue, 23 Jun 2009 10:54:29 -0400
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.
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rich Jesse Sent: Tuesday, June 23, 2009 10:29 AM
Subject: Massive upgrades (WAS: Physical Memory Fully Used...)
>> It was a very bad decision to change everything at one time as well
>> decision) --definitely not a best practice to change everything
>> testing, testing, testing and then testing again.
As with most things, it depends. I was on a project a few years back
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
~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
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
a challenge to unravel!), but if it's required it certainly can be accomplished.