known bugs in 10.2.0.1 on aix 64bit

#11

John Hurley wrote:

Quote:

10.2.0.1? Really?

I just have on 10.2 system left but it is over on solaris and ( not
used heavily ) and stable on 10.2.0.4.

I would think you want to look at 10.2.0.5 and research bugs on that
port to aix.

No kidding. The joke's on me.

Know a way to find the known bugs for 10.2.0.5?

#12

On Sep 15, 11:17*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:

Quote:

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.

Quote:

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.

Quote:

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.

#13

On Sep 16, 2:52*am, "Gerard H. Pille" <g... (AT) skynet (DOT) be> wrote:

Quote:

Ok, ASSM is what I thought it was, Automatic Segment Space Misery.

All these features making the DBA obsolete, you think? *

Not at all. I love ASSM, best feature Oracle ever invented! Quite
frankly: buffer busy waits get pretty old, after a while!

Quote:

All the time I spent trying to improve
the performance of this database, and only because of an ORA-01555 with aparallel query that I
was investigating, Google came up with this bug, and I realized this database ran a version
that's almost 4 years old. *Losing my touch.

You'd likely get better mileage looking at why is undo so needed for a
parallel query!
Just joking, you got a nasty bug. Hope you find the fix. I know it's
fixed in 2.0.3.

I like to spend my time fixing bad SQL and bad design rather than
patching bugs. IME, I get orders of magnitude performance improvement
by fixing a really bad SQL or PL/SQL section of code than by patching
up for bugs here, there and everywhere. To give you a measure of what
I'm talking about: our DW produced 100GB od redo logs daily when I
started here. And around 1TB/day of reads. In a server that had 100%
CPU usage for nearly 22 hours/day.
Now it pumps out 500GB of redo log, around 5TB/day of reads and rarely
if ever goes over 30% CPU usage. Most of it due to improvements to
SQL and PL/SQL, rather than major patches or release upgrades. I'm
happy with that!

#14

On Wed, 15 Sep 2010 00:45:00 -0700, Noons wrote:

Quote:

Apologies: we ARE using ASSM. What we are not using is ASM. Darn
Oracle and their acronyms...

Peter Sharman once referred to ASSM as "ass managed segments". That ought
to make things easier to distinguish, just think of Jessica Simpson.

--
http://mgogala.byethost5.com

#15

On Sep 15, 10:48*pm, Noons <wizofo... (AT) gmail (DOT) com> wrote:

Quote:

On Sep 15, 11:17*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) 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.

jg
--
@home.com is bogus.
To the moon, Larry! To the moon! http://news.cnet.com/8301-19514_3-20016586-239.html

#16

On Sep 16, 6:31*pm, joel garry <joel-ga... (AT) home (DOT) com> wrote:

Quote:

On Sep 15, 10:48*pm, Noons <wizofo... (AT) gmail (DOT) com> wrote:

On Sep 15, 11:17*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) 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.

--
Jeroen

#17

Nuno:

Quote:

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.

Not interested thanks ... I only have one system left on 10.2 and it
is on 10.2.0.4 currently.

Just interested in clearing up the terminology for ( not too likely
given how dead cdos is these days ) other people.

Quote:

Any particular reason you have not gone past 10.2.0.3?

.... Yes, a few reasons:

Hey fine it was just curiousity given how ( a while back now )
relatively stable 10.2.0.4 was for us. That was back on hpux though
and hey we are out of there now.

Running stuff on aix must be a little interesting these days with
patches/etc given how Oracle is yo yo'ing between linux and solaris.

Used to be solaris and hpux maintenance came out timely and pretty
well tested ... used to be. Solaris maintenance may now be back on
the upswing ... time will tell.

#18

On Sep 16, 10:50*am, The Boss <nlt... (AT) baasbovenbaas (DOT) demon.nl> wrote:

Quote:

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.

--
Jeroen

True, but false economy is easy to budget. True economy requires both
management support and good strategic vision. http://dilbert.com/strips/comic/2010-09-16/

jg
--
@home.com is bogus.
http://www.signonsandiego.com/photos...pt-5-11/13495/

#19

Gerald:

Quote:

No kidding. *The joke's on me.

Know a way to find the known bugs for 10.2.0.5?

Well the bugs fixed in the 10.2.0.5 patchset are not hard to find.

I was talking about 10.2.0.5 for aix and any issues related to that
specific platform. The correct Oracle support analyst can help you
chase those down if you can get the correct one. Probably an aix
specific knowledge base article that you can chase down.

#20

On Sep 17, 6:45*am, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:

Quote:

Running stuff on aix must be a little interesting these days with
patches/etc given how Oracle is yo yo'ing between linux and solaris.

Used to be solaris and hpux maintenance came out timely and pretty
well tested ... used to be. *Solaris maintenance may now be back on
the upswing ... time will tell.

Precisely. It's never been easy on AIX, due to all the Ora++IBM
fighting.
But it's a good platform and the new Power6 chips are absolute
screamers.
I love that i570 we got now: with the lpar virtual partitioning and
the hypervisor on top, it's so easy to re-config on the fly it's not
even funny. We got so much stuff on it now it's mind-blowing.
Starting now to use AIX 6 on micro-lpars, which are even better.
Basically, all our Oracle servers hang off that beast, with a few app
servers thrown in and two AS400 servers in there as well!