RE: Massive upgrades (WAS: Physical Memory Fully Used...)
- From: "Matthew Zito" <mzito@xxxxxxxxxxx>
- To: <rjoralist@xxxxxxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- 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.
Thanks,
Matt
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Rich Jesse
Sent: Tuesday, June 23, 2009 10:29 AM
To: oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
