Re: known bugs in 10.2.0.1 on aix 64bit
From: The Boss <nltaal_at_baasbovenbaas.demon.nl>
Date: Thu, 16 Sep 2010 10:50:47 -0700 (PDT)
Message-ID: <a28bf7ad-4294-4bfb-a1cf-2b7a3b63c1f5_at_q26g2000vbn.googlegroups.com>
On Sep 16, 6:31 pm, joel garry <joel-ga..._at_home.com> wrote:
> On Sep 15, 10:48 pm, Noons <wizofo..._at_gmail.com> wrote:
>
>
>
>
>
> > On Sep 15, 11:17 pm, John Hurley <hurleyjo..._at_yahoo.com> wrote:
>
> > > Just the 10.2.0.3 patchset? Or 10.2.0.3 patchset with various other
> > > one offs? ( Sorry the "patched up" terminology not clear at least to
> > > me ).
>
> > Patched up with various other one-offs. Located from known problems
> > with ASSM and a few CBO and query result-set issues. If you want, I
> > can get you the actual bug numbers, they are in our Opatch mini-
> > database.
>
> > > Any particular reason you have not gone past 10.2.0.3?
>
> > Yes, a few reasons:
>
> > I'm not paid to install patches to Oracle, I'm paid to provide
> > reliable database resources that run no matter what.
> > What we run on them is our business applications, and those have
> > priority. Not the database. The business aplications only require
> > Oracle 10g.
> > From past experience, the quickest way to throw out the reliability of
> > an Oracle installation is to install every dot patch that Oracle
> > delivers.
> > Unreliable services mean we're out of a job.
> > So far, we've been able to provide 100% - not 99.99, not "4 9s". 100%
> > = 0 (zero) unsheduled outage - in 12 instances supporting a wide
> > variety of consolidated production and dev/test environments of DW,
> > Hyperion, Peoplesoft, SOA/OSB, Apex and Forms applications over a
> > period of nearly 4 years.
> > Of course: that level of service delivery must be because we don't
> > know what we're doing.
>
> > In simple terms: if it's not broken, it is meeting the SLA *and* you
> > do not need new db functionality, do NOT touch it.
>
> > Don't blame me, blame Oracle: it's their software, I don't write it.
> > And I most certainly refuse to QA it for them, for free and at the
> > expense of my professional delivery and reputation.
>
> > > How about the CPUs and ( just more recently ) the PSUs?
>
> > How about them? Read the prior answer. As well, I add:
>
> > CPUs are primarily security patches. We don't have a security
> > problem.
> > No, I don't care what "security experts" claim:
> > we get independently security audited twice a year and so far no one
> > has been able to poke through or find fault; those are the facts our
> > performance is measured upon.
> > Not hypothetical "web site" scenarios.
>
> > (How many commercial sites do you know of that audit security that
> > frequently?
> > Thought so...)
>
> > PSU's are too recent for me to form an opinion on them and anyway most
> > do not apply to 10.2.0.3. And quite frankly: Oracle's "patch releases"
> > mean nothing to me given their past history of instability.
>
> > Like I said: I'm paid to provide a reliable db service. Not Oracle
> > installs.
> > This is not a software house or IT services company. We run a business
> > that has nothing to do with software making: it just uses it. And my
> > job is to make sure we use it to the most.
>
> > I also back my claims with independent external audits which have
> > never found a flaw in any of our processes, in the nearly 4 years I've
> > been here.
> > Not being condescending or anything, just stating the facts.
>
> It's not condescending, it's just pointing up that most places aren't
> as well run as yours, especially when "the business" makes technical
> decisions, with cost considerations overriding implicit requirements
> for stability and uptime. My hat's off to your management, it's
> expensive to do it right, it's tough to find a Noons to entrust with
> the power.
>
> It shows how difficult it is to advise strategy in general. Oracle
> must both follow and lead the "market," Dilbertesque as it may be.
> Individual companies must make their own decisions within a broad
> range of possibilities, some self-contradictory.
>
Date: Thu, 16 Sep 2010 10:50:47 -0700 (PDT)
Message-ID: <a28bf7ad-4294-4bfb-a1cf-2b7a3b63c1f5_at_q26g2000vbn.googlegroups.com>
On Sep 16, 6:31 pm, joel garry <joel-ga..._at_home.com> wrote:
> On Sep 15, 10:48 pm, Noons <wizofo..._at_gmail.com> wrote:
>
>
>
>
>
> > On Sep 15, 11:17 pm, John Hurley <hurleyjo..._at_yahoo.com> wrote:
>
> > > Just the 10.2.0.3 patchset? Or 10.2.0.3 patchset with various other
> > > one offs? ( Sorry the "patched up" terminology not clear at least to
> > > me ).
>
> > Patched up with various other one-offs. Located from known problems
> > with ASSM and a few CBO and query result-set issues. If you want, I
> > can get you the actual bug numbers, they are in our Opatch mini-
> > database.
>
> > > Any particular reason you have not gone past 10.2.0.3?
>
> > Yes, a few reasons:
>
> > I'm not paid to install patches to Oracle, I'm paid to provide
> > reliable database resources that run no matter what.
> > What we run on them is our business applications, and those have
> > priority. Not the database. The business aplications only require
> > Oracle 10g.
> > From past experience, the quickest way to throw out the reliability of
> > an Oracle installation is to install every dot patch that Oracle
> > delivers.
> > Unreliable services mean we're out of a job.
> > So far, we've been able to provide 100% - not 99.99, not "4 9s". 100%
> > = 0 (zero) unsheduled outage - in 12 instances supporting a wide
> > variety of consolidated production and dev/test environments of DW,
> > Hyperion, Peoplesoft, SOA/OSB, Apex and Forms applications over a
> > period of nearly 4 years.
> > Of course: that level of service delivery must be because we don't
> > know what we're doing.
>
> > In simple terms: if it's not broken, it is meeting the SLA *and* you
> > do not need new db functionality, do NOT touch it.
>
> > Don't blame me, blame Oracle: it's their software, I don't write it.
> > And I most certainly refuse to QA it for them, for free and at the
> > expense of my professional delivery and reputation.
>
> > > How about the CPUs and ( just more recently ) the PSUs?
>
> > How about them? Read the prior answer. As well, I add:
>
> > CPUs are primarily security patches. We don't have a security
> > problem.
> > No, I don't care what "security experts" claim:
> > we get independently security audited twice a year and so far no one
> > has been able to poke through or find fault; those are the facts our
> > performance is measured upon.
> > Not hypothetical "web site" scenarios.
>
> > (How many commercial sites do you know of that audit security that
> > frequently?
> > Thought so...)
>
> > PSU's are too recent for me to form an opinion on them and anyway most
> > do not apply to 10.2.0.3. And quite frankly: Oracle's "patch releases"
> > mean nothing to me given their past history of instability.
>
> > Like I said: I'm paid to provide a reliable db service. Not Oracle
> > installs.
> > This is not a software house or IT services company. We run a business
> > that has nothing to do with software making: it just uses it. And my
> > job is to make sure we use it to the most.
>
> > I also back my claims with independent external audits which have
> > never found a flaw in any of our processes, in the nearly 4 years I've
> > been here.
> > Not being condescending or anything, just stating the facts.
>
> It's not condescending, it's just pointing up that most places aren't
> as well run as yours, especially when "the business" makes technical
> decisions, with cost considerations overriding implicit requirements
> for stability and uptime. My hat's off to your management, it's
> expensive to do it right, it's tough to find a Noons to entrust with
> the power.
>
> It shows how difficult it is to advise strategy in general. Oracle
> must both follow and lead the "market," Dilbertesque as it may be.
> Individual companies must make their own decisions within a broad
> range of possibilities, some self-contradictory.
>
Agree with most of your comments, but not: "it's expensive to do it right"
It's always less expensive to do it right first time than to screw up
and make it right afterwards.
Or even worse: have to hire someone from outside to do so.
;)
-- JeroenReceived on Thu Sep 16 2010 - 12:50:47 CDT