here's a good one from dizwell on the recent product launch
hpuxrac
http://www.dizwell.com/prod/node/881
I was laughing not without reason at several of the comments.
Something like "there's little I in the IOUG". Also some good
commentary from Noons. Wielding a sharp edged repartee he appears to
be asking why should a vendor actually fix old bugs when they can stay
busy putting out new releases.
Oracle is doing rather well at marketing people. Not complaining it
keeps the paychecks coming in for now. We don't need cheerleaders out
here in cdos IMHO.
Mark Townsend
> Here's the url with some good comments at the bottom ...
>
> http://www.dizwell.com/prod/node/881
>
Well, if good means predictable, I agree with you. Howard and Noons like
to complain, especially about new releases. Howard originally called 10g
'Oracle9i Release 3' - sound familiar at all ? It's a new release. Try
it out, test it and see if you like it. Nobody is claiming that it cures
cancer, however it does have a lot of new features designed, developed
and documented by a bunch of very dedicated people. They deserve a few
moments of glory. Why deny them that ?
DA Morgan
> Here's the url with some good comments at the bottom ...
>
> http://www.dizwell.com/prod/node/881
>
> I was laughing not without reason at several of the comments.
> Something like "there's little I in the IOUG".
They were forced to change their name from International to Independent.
They were definitely not international. Whether they are independent is
for others to decide.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
DA Morgan
Perhaps someone should write a book attempting to define when a software
vendor is, and is not, allowed to increment an integer.
Likely will sell at least a dozen copies. <g>
Perhaps if you called it Oracle Database 1.11.1.0.6 everyone would be
happy.
After all Sun has managed to keep version 2 going for a very long time.
Noons
Don't speak for Howard, no matter how much that
might suit the opinion of some morons inside Oracle. But
Noons doesn't like to complain unless there is very good
reason for doing so:
it is COMPLETELY unacceptable that Oracle continues to
deliver new releases without fixing first what are absolutely
egregious bugs.
Would you like me to publicly go into the details
once more? With pleasure.
As for cancer cure, listening to the marketing
nonsense in the last month or so it would appear
it is the second coming. Does it also update the
correct tables now or is that bug not fixed yet,
after 6 years of it?
Can it finally handle high I/O in LOBs stored
in ASSM tablespaces or is that still causing 600
errors all over the place, like in the last 5 years?
Is it possible to setup a database using FBIs
that doesn't require a bucketful of
undocumented optimiser parameters in
order to perform acceptably?
You see:
"dedication" is not measured by number of
new releases or features. The WHOLE POINT of
using a database is first and primarily to have a
RELIABLE and CONSISTENT mechanism to store
and acess data.
When that fails consistently for nearly 7 years
and the "dedicated" folks do preciously NOTHING
to fix problems that have seen three major releases
without a permanent fix, it's high time for "dedication"
to become "fix the damn basics, you blithering idiots!"...
Of course, you can take the usual marketing
blowhard attitude of discrediting everyone in sight
who disagrees with the current state of affairs.
Be my guest: it's nothing new and I've only had,
oh, let me see: 20 years of it already?
Recall however that when the "dedicated" people
were still trying to spell "database", others
were already using the product and pushing it
because it was reliable. Those folks haven't
changed their opinions depending on who
pays the most, or the fashion statement
of the week.
Unlike marketing blowhards.
Don't act too surprised when the "market"
decides to drop the features and go with
solid products.
Noons
> Here's the url with some good comments at the bottom ...
>
> http://www.dizwell.com/prod/node/881
>
> I was laughing not without reason at several of the comments.
> Something like "there's little I in the IOUG". Also some good
> commentary from Noons. Wielding a sharp edged repartee he appears to
> be asking why should a vendor actually fix old bugs when they can stay
> busy putting out new releases.
"appears" to be asking? LOL!
dude, I couldn't have said it more clearly!
> Oracle is doing rather well at marketing people. Not complaining it
> keeps the paychecks coming in for now. We don't need cheerleaders out
> here in cdos IMHO.
Hang on: cheerleaders have always been a part and parcel
of this place, hpux! Provided everyone is clear on the subject,
I see no problem with it. Trouble starts when they try to
pass themselves as something else...
DA Morgan
> it is COMPLETELY unacceptable that Oracle continues to
> deliver new releases without fixing first what are absolutely
> egregious bugs.
>
> Would you like me to publicly go into the details
> once more? With pleasure.
I've got what I hope is a better idea ... send the list to me
describing how to test each and every one of them and I promise to
open an SR on any that are not fixed in 11g within one week.
Mark Townsend
>
> Can it finally handle high I/O in LOBs stored
> in ASSM tablespaces or is that still causing 600
> errors all over the place, like in the last 5 years?
>
> Is it possible to setup a database using FBIs
> that doesn't require a bucketful of
> undocumented optimiser parameters in
> order to perform acceptably?
>
If you would like to post or send me the SRs or Bug details, I will
follow up and let you know.
joel garry
Well, I've been watching Noons for a very long time, and I've said it
before - if Noons is complaining about something, you'd be well
advised to listen.
Databases are moving... no, have long ago moved, why do you think so
many things only use 7.3 features?... into being commodities, glory
isn't to be expected. Solidity, correctness, utility-like
dependability is.
(Says the guy people blow off for complaining too much... and said 7.3
should have been 8... :-)
jg
--
@home.com is bogus. "When I ran the Klan in California, I kicked
anyone out of the group that I found was wasting good paint. I have
said many times that sneaking around a person's yard that you don't
like is quite dishonorable while knocking on the door and punching
your opponent in the nose without wearing a mask is the more
gentlemanly thing to do." - Tom Metzger, schooling us on the
principled integrity of the KKK.
DA Morgan
> ... why do you think so many things only use 7.3 features?
Because many people are terminally lazy and many companies would
rather make money selling consulting services (tuning) rather
than making a decent product.
Noons
>
> I've got what I hope is a better idea ... send the list to me
> describing how to test each and every one of them and I promise to
> open an SR on any that are not fixed in 11g within one week.
Here is another good idea:
before you start spouting how "incompetent" dbas are, that
don't blindly install the latest buggy rubbish over their working
production systems, why don't you go to Metalink and
do some searches there for the problems I mentioned?
While you're there, search also for problems
with ANY of the new features that have been promoted
ad-nauseum here by the marketeers, for 9i and 10g.
Oh yes: check out also all bugs for 10.2.0.3, the latest
available version. And check the release notes for the
latest application software from Peoplesoft and Peopletools.
Same for JDE and all the others. Check how many db
patches are required to get the darn things going.
You know: occasional searches in the bug database
might enlighten the marketeers about what is
happening.
And it might also alert them to the constant buggy
rubbish that the "expensive and incompetent"
dbas have to put up with, for years on end!
Don't expect me to do Oracle's work, I won't.
Go to Metalink and do something useful: pass the bugs
you find to Oracle's management.
And start asking: why is it that in 10.2.0.2 there are
still bugs being fixed for features first announced in 8ir3!
You want folks to push their management to move
to the latest releases? How about you LISTEN
and start making them more stable?
Noons
> > it is COMPLETELY unacceptable that Oracle continues to
> > deliver new releases without fixing first what are absolutely
> > egregious bugs.
>
> > Would you like me to publicly go into the details
> > once more? With pleasure.
>
> I've got what I hope is a better idea ... send the list to me
> describing how to test each and every one of them and I promise to
> open an SR on any that are not fixed in 11g within one week.
Let's see if google doesn't drop my reply now...
Here is an even better idea:
next time you feel like classing as incompetent
any dba who refuses to install buggy rubbish over their
running systems, why don't you do this:
1- go to Metalick and search for all bugs and patches
for 10.2.0.2.
2- count them.
3- check out how many are for problems with
features first announced in 8ir3.
4- count them.
5- rinse and repeat for 10.2.0.3, 10.1.0.3,
9ir2 - various releases, 9ir1 - various releases.
6- count the years all those releases span.
then stop and think: why is it that folks are SO
reluctant to install new releases?
Could it be it's just TOO MANY YEARS of
constant buggy releases on the same problems?
Narh!.....
Because they are all a bunch of "incompetent" dbas?
Sure...
Ah yes, don't expect me to do Oracle's work
for you: I don't work for them and haven't
for over 20 years. And they certainly haven't
done me any favours that I need to repay.
Quite the opposite, in fact.
To sum up: stop calling everyone in sight
"incompetent dba". There are VERY good reasons
why folks refuse to blindly install the latest from
Oracle in their current running systems and they
have nothing to do with competency.
Try to read the release notes for Peoplesoft/Peopletools,
JDE, Siebel, etcetc. And count the patches
that need to be applied just to get things moving,
let alone running efficiently.
It might enlighten you on how well appreciated
and irrelevant your tirades on people's "competence"
really are.
And how irrelevant they are to folks who have to fight
buggy releases for years on end, while being
constantly told it's all "their fault" because they
haven't installed the latest (buggy) release!
But of course "11g has no bugs and fixes
all previous ones". You know: the number of times
I heard that joke for 9ir1, 9ir2, 10gr1, 10gr2....
Noons
> Noons wrote:
> > it is COMPLETELY unacceptable that Oracle continues to
> > deliver new releases without fixing first what are absolutely
> > egregious bugs.
>
> > Would you like me to publicly go into the details
> > once more? With pleasure.
>
> I've got what I hope is a better idea ... send the list to me
> describing how to test each and every one of them and I promise to
> open an SR on any that are not fixed in 11g within one week.
Let's see if google drops my reply now...
DA Morgan
> On Jul 16, 11:54 pm, DA Morgan <damor...@psoug.org> wrote:
>
>> I've got what I hope is a better idea ... send the list to me
>> describing how to test each and every one of them and I promise to
>> open an SR on any that are not fixed in 11g within one week.
>
>
>
> Here is another good idea:
>
> before you start spouting how "incompetent" dbas are, that
> don't blindly install the latest buggy rubbish over their working
> production systems, why don't you go to Metalink and
> do some searches there for the problems I mentioned?
I've yet to see you mention a single problem though I've invited
you to do so.
Rather than spitting into the wind pick the three bugs that bug
you the most and send me code that will demo the problem.
If you aren't willing to do so then I guess the bugs aren't as
important to you as the angst.
What I find interesting about the complaints about how terrible
it all is ... is that somehow, in spite of all the problems, every
major bank in North America is still in business. Amazon.com is
still in business. Boeing is still making airplanes. Insurance
companies are still selling and servicing policies. And every
hospital in this region is still opening its doors to patients.
Makes me think that, just perhaps, you've lost a tiny bit of
perspective.
DA Morgan
> On Jul 16, 11:54 pm, DA Morgan <damor...@psoug.org> wrote:
>> Noons wrote:
>>> it is COMPLETELY unacceptable that Oracle continues to
>>> deliver new releases without fixing first what are absolutely
>>> egregious bugs.
>>> Would you like me to publicly go into the details
>>> once more? With pleasure.
>> I've got what I hope is a better idea ... send the list to me
>> describing how to test each and every one of them and I promise to
>> open an SR on any that are not fixed in 11g within one week.
>
> Let's see if google drops my reply now...
We now have at least 4 copies of this exact same posting.
Perhaps rather than jumping up and down about Oracle you should focus
on your inability to master google.
Sorry ... couldn't resist.
NetComrade
>Let's see if google drops my reply now...
Don't promote the use of their evil tools. Google was the worse thing
that had ever happenned to newsgroups (with their pushy non-tree
displays of threads, and the whole concent of 'start your own group')
Use some 'advanced' tool like FreeAgent instead ;)
.......
We run Oracle 9iR2,10gR1/2 on RH4/RH3 and Solaris 10 (Sparc)
remove NSPAM to email
sybr...@hccnet.nl
wrote:
>> ... why do you think so many things only use 7.3 features?
>
>Because many people are terminally lazy and many companies would
>rather make money selling consulting services (tuning) rather
>than making a decent product.
Actually, no: Because many companies don't NEED the new features.
We have one customer running a HRM package on 8i and Win2k.
They don't upgrade the HRM package, because they don't need a new
version (probably they aren't even aware there is a new one).
Consequently they don't upgrade Microsux and they don't upgrade
Oracle.
Their server is 5 years old. It works!
Many customers just *CAN'T* (I repeat bloody CAN'T) upgrade, because
their vendors don't upgrade to newer versions of Oracle.
--
Sybrand Bakker
Senior Oracle DBA
Jonathan Lewis
"DA Morgan" <damo...@psoug.org> wrote in message
news:11846404...@bubbleator.drizzle.com...
>
> I've yet to see you mention a single problem though I've invited
> you to do so.
>
> Rather than spitting into the wind pick the three bugs that bug
> you the most and send me code that will demo the problem.
>
In reply to a comment on a recent blog entry
http://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
Nuno gave me bug 5092688.8
The detail on Metalink is as follows:
This bug is marked as an important issue.
Versions confirmed as being affected 10.1.0.5, 10.2.0.2
Description: Wrong results are possible if a function based index exists on
a table used in a query.
Workaround: Set "_disable_function_based_index"=TRUE
Fixed in: 10.2.0.3 (Server Patch Set)
Note the description - this means that if you are on 10.2.0.2
you MUST upgrade to 10.2.0.3 or you MUST disable
all function based indexes. (There is currently no separate
patch reported for the problem).
If Oracle has managed to patch the problem (in a full release),
why can't they describe the problem properly so that we can
decide whether to patch it or ignore it as irrelevant. And why
should I believe that a full patch release isn't going to introduce
other problems on my system - I just want to fix the problem
I know I have.
Given the nature of many large organisations today - how often
do you think people would notice if they got results which were
a 'little bit' wrong ? How many people run reports and create
screens which have guaranteed consistency checks built in so
that a wrong answer has to appear twice in exactly the same
way before it can get past audit ?
--
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Alexander Skwar
> We now have at least 4 copies of this exact same posting.
Who is "we"? We only have 1 copy of the posting.
> Perhaps rather than jumping up and down about Oracle you should focus
> on your inability to master google.
Why's that?
> Sorry ... couldn't resist.
Yep.
Alexander Skwar
--
If *I* had a hammer, there'd be no more folk singers.
Noons
>
> Many customers just *CAN'T* (I repeat bloody CAN'T) upgrade, because
> their vendors don't upgrade to newer versions of Oracle.
but of course: that is the fault of the
"lazy, incompetent dbas" !!!!
Niall Litchfield
> I've yet to see you mention a single problem though I've invited
> you to do so.
Should be a simple enough search on metalink.
Look up for example bug 5014578 - reported a year and a half ago -
customer gets wrong results - slated to be fixed in 11 - admittedly
the customer is running solaris 64bit so the wait to get correct data
out of their database may only be a couple of years or so.
> Rather than spitting into the wind pick the three bugs that bug
> you the most and send me code that will demo the problem.
>
> If you aren't willing to do so then I guess the bugs aren't as
> important to you as the angst.
I don't think it unreasonable to imagine that noons has test cases
with support - any normal dba would. They'd be unlikely to send test
cases and potentially company data to someone posting on usenet.
> What I find interesting about the complaints about how terrible
> it all is ... is that somehow, in spite of all the problems, every
> major bank in North America is still in business. Amazon.com is
> still in business. Boeing is still making airplanes. Insurance
> companies are still selling and servicing policies. And every
> hospital in this region is still opening its doors to patients.
> Makes me think that, just perhaps, you've lost a tiny bit of
> perspective.
There has also unfortunately been a pattern of security researchers
notifying Oracle of security bugs and not getting them fixed for
several years. It's one of the reasons (along with the standard of
security awareness among developers and dbas generally) that I wrote
the bit in http://www.orawin.info/services/node/29 about high profile
databases being compromised. Microsoft learnt the lesson the hard way
with the slammer worm - it wouldn't surprise me if Oracle doesn't
experience a similar PR disaster.
Niall
Niall Litchfield
wrote:
> >Let's see if google drops my reply now...
>
> Don't promote the use of their evil tools. Google was the worse thing
> that had ever happenned to newsgroups (with their pushy non-tree
> displays of threads, and the whole concent of 'start your own group')
> Use some 'advanced' tool like FreeAgent instead ;)
:) Though I can't help but note that there is a tree view on my screen
right now from Google.
Niall
gazzag
> Actually, no: Because many companies don't NEED the new features.
> We have one customer running a HRM package on 8i and Win2k.
> They don't upgrade the HRM package, because they don't need a new
> version (probably they aren't even aware there is a new one).
> Consequently they don't upgrade Microsux and they don't upgrade
> Oracle.
> Their server is 5 years old. It works!
>
> Many customers just *CAN'T* (I repeat bloody CAN'T) upgrade, because
> their vendors don't upgrade to newer versions of Oracle.
>
> --
> Sybrand Bakker
> Senior Oracle DBA
About five years ago I went to a job interview. Without being too
specific, it was for an Oracle DBA role at a very large nuclear power
facility. During the interview I was surprised to learn that they
were still running on Oracle 6 (to put this in perspective, 9i had
been out for around six months and, as an aspiring DBA, I'd really cut
my teeth on 7.3.x). Anyway, during the course of the interview I
raised a question regarding their upgrade plans. "We have no plans to
upgrade" was the reply. "Why?" I asked. The DBA grinned: "Do you
want to 'upgrade' a nuclear power station?" I figured that I
didn't...
It was a closed system that didn't interact with anything outside of
its network. The point being: it worked as it was. There's nothing
inherently wrong with legacy systems, despite what the marketing guys
would have you believe.
DA Morgan
> On Mon, 16 Jul 2007 18:21:09 -0700, DA Morgan <damo...@psoug.org>
> wrote:
>
>>> ... why do you think so many things only use 7.3 features?
>> Because many people are terminally lazy and many companies would
>> rather make money selling consulting services (tuning) rather
>> than making a decent product.
>
> Actually, no: Because many companies don't NEED the new features.
> We have one customer running a HRM package on 8i and Win2k.
> They don't upgrade the HRM package, because they don't need a new
> version (probably they aren't even aware there is a new one).
> Consequently they don't upgrade Microsux and they don't upgrade
> Oracle.
> Their server is 5 years old. It works!
Apparently the companies you refer to are not subject to government
regulations like Sarbanes-Oxley, PIPEDA, BASEL II, etc. Much of what
has pushed the movement to 10g here is compliance and auditing.
One public company I've consulted for was perfectly happy with 7.3.4
until their auditor refused to sign their financial statement. Six
weeks later they discovered the wonderful world of 9.2.0.6 and a
version of the database without svrmgr and with FGA.
> Many customers just *CAN'T* (I repeat bloody CAN'T) upgrade, because
> their vendors don't upgrade to newer versions of Oracle.
This is the real issue and one I wish Oracle would address. I
understand why they don't want to but I really wish they would.
DA Morgan
That statement was made with respect to RMAN. Please don't spin it out
of context to try to make your point.
DA Morgan
> On Jul 17, 3:47 am, DA Morgan <damor...@psoug.org> wrote:
>> I've yet to see you mention a single problem though I've invited
>> you to do so.
>
> Should be a simple enough search on metalink.
>
> Look up for example bug 5014578 - reported a year and a half ago -
> customer gets wrong results - slated to be fixed in 11 - admittedly
> the customer is running solaris 64bit so the wait to get correct data
> out of their database may only be a couple of years or so.
I don't have a machine capable of running 64bit Solaris in the lab: 32
but not 64. There is, however a 64 bit Solaris Beta available.
If anyone in the Seattle area has a machine I could borrow for one day
I'd be happy to run the test.
DA Morgan
One of my customers, for the same reason, is still running Oracle 4 on
two Apollo workstations. But the vast majority of their systems are on
9.2 or 10.2 and the 9.2 should be gone by early next year.
joel garry
wrote:
> · DA Morgan <damor...@psoug.org>:
>
> > We now have at least 4 copies of this exact same posting.
>
> Who is "we"? We only have 1 copy of the posting.
Through google, I see 2 plus a different one that is similar.
Recently I had problems like this with google, it says it didn't post
but it does. On one, I saw from the timestamp that it took something
like 10 hours to actually get posted. I had some problems yesterday,
turned out to be OEM was sucking up so much of the PC's resources it
was slowing down IE.
>
> > Perhaps rather than jumping up and down about Oracle you should focus
> > on your inability to master google.
Jeeze Dan, maybe google has an inability to master transactions. Try
checking out Noon's blog.
>
> Why's that?
>
> > Sorry ... couldn't resist.
>
> Yep.
>
> Alexander Skwar
> --
> If *I* had a hammer, there'd be no more folk singers.
Good one! http://www.mysloppyseconds.com/show_album.php?album_id=376
jg
--
@home.com is bogus.
"Phyllis Diller won't be appearing because she had a problem with her
rack, back." - Female entertainment reporter on morning zoo radio
show, no one said anything.
DA Morgan
I hope Noons has none me long enough to understand that it was said to
be humorous and not intended as criticism. I disagree with him on his
negativity on some issues. But his technical abilities are not subject
to question.
Paul Linehan
NetComrade wrote:
> Use some 'advanced' tool like FreeAgent instead ;)
Sad to say that FreeAgent is MIA, and according to
Forteinc, won't be coming back - sniff.
Paul...
Noons
wrote:
> > I've yet to see you mention a single problem though I've invited
> > you to do so.
Like I said, Daniel: I won't do your homework.
> > Rather than spitting into the wind pick the three bugs that bug
> > you the most and send me code that will demo the problem.
No. You pick your browser and go to Metalink,
search for problems where I mentioned them, and
inspect the test cases there.
> In reply to a comment on a recent blog entryhttp://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
>
> Nuno gave me bug 5092688.8
Ah, you got it! Sorry, I wasn't sure you had
seen the reply. Thanks, Jonathan.
> This bug is marked as an important issue.
> Versions confirmed as being affected 10.1.0.5, 10.2.0.2
> Description: Wrong results are possible if a function based index exists on
> a table used in a query.
Actually there is a similar bug in 9i, different number.
I hit it a couple of years ago. Not nice that it isn't fixed
yet in 10g, let alone 9i!
Not nice at all!
What I meant when I said it is completely unacceptable
that egregious bugs like this, on features released
YEARS ago, are STILL not fixed!
> Workaround: Set "_disable_function_based_index"=TRUE
> Fixed in: 10.2.0.3 (Server Patch Set)
> Note the description - this means that if you are on 10.2.0.2
> you MUST upgrade to 10.2.0.3 or you MUST disable
> all function based indexes. (There is currently no separate
> patch reported for the problem).
In other words: if you are using Peopletools 8.48,
which for the FIRST time tries to make use of FBIs
- I wonder why, given they have been available
since 8i, could it be Oracle knew of the problems
and told no one? - you'll be up the proverbial creek
without a paddle!
Meanwhile, if you are a sucker like me and have tried
to design a full-on application making extensive use of
said indexes in anything before 10.2.0.3, you
might as well have been shooting yourself in the
foot when it comes to providing stability and reliability.
Given that those two requirements might be somewhat
essential to one's reputation as a designer and dba,
don't make me explain further how *pissed off* I am
at this and other little pearls of new functionality that
just plain do NOT work or are flaky as heck...
> If Oracle has managed to patch the problem (in a full release),
> why can't they describe the problem properly so that we can
> decide whether to patch it or ignore it as irrelevant. And why
> should I believe that a full patch release isn't going to introduce
> other problems on my system - I just want to fix the problem
> I know I have.
I don't want to flog this one much further, but indeed there is
a patch to this problem. For 10.2.0.2. Now, given that
other patches I have installed to solve similar problems
with FBI have ALL failed to deliver, what guarantees to
me that I won't be having incorrect rersults in my queries?
It's *only* the payroll system of a 65 billion dollar company,
what the heck: they can afford this sort of risk?
> Given the nature of many large organisations today - how often
> do you think people would notice if they got results which were
> a 'little bit' wrong ? How many people run reports and create
> screens which have guaranteed consistency checks built in so
> that a wrong answer has to appear twice in exactly the same
> way before it can get past audit ?
Well, try to explain to a payroll manager that her results
might not be correct and you don't know exactly when
or why or how?
And it's this sort of rubbish nonsense that I have had
to cope with for YEARS!
Any wonder I'm royally PISSED OFF with Oracle
and their "glory moments" for 11g developers?
DA Morgan
> On Jul 17, 3:35 pm, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
> wrote:
>
>>> I've yet to see you mention a single problem though I've invited
>>> you to do so.
>
> Like I said, Daniel: I won't do your homework.
Not my homework.
Not my issue.
Your issue.
I offered to help you by championing your issue. It is you, not me,
that brought it up. So which is it?
1. Mark was right about the whining?
2. In all sincerity you really don't care that much about the bugs
because they are minor and only nuisance value?
3. As a fellow Aussie you like giving Mark a bad time?
The questions are rhetorical, I'm just giving you a hard time, so
don't feel obliged to respond. Going to New Zealand in November and
if time permits stopping up your way so perhaps I can apologize for
this harangue in person. <g>
Noons
wrote:
<sigh>, google groups is reeeeeealy starting to get on my nerves...
> > I've yet to see you mention a single problem though I've invited
> > you to do so.
Like I said, Daniel: I won't do your homework.
> > Rather than spitting into the wind pick the three bugs that bug
> > you the most and send me code that will demo the problem.
No. You pick your browser and go to Metalink,
search for problems where I mentioned them, and
inspect the test cases there.
> In reply to a comment on a recent blog entryhttp://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
>
> Nuno gave me bug 5092688.8
Ah, you got it! Sorry, I wasn't sure you had
seen the reply. Thanks, Jonathan.
> This bug is marked as an important issue.
> Versions confirmed as being affected 10.1.0.5, 10.2.0.2
> Description: Wrong results are possible if a function based index exists on
> a table used in a query.
Actually there is a similar bug in 9i, different number.
I hit it a couple of years ago. Not nice that it isn't fixed
yet in 10g, let alone 9i!
Not nice at all!
What I meant when I said it is completely unacceptable
that egregious bugs like this, on features released
YEARS ago, are STILL not fixed!
> Workaround: Set "_disable_function_based_index"=TRUE
> Fixed in: 10.2.0.3 (Server Patch Set)
> Note the description - this means that if you are on 10.2.0.2
> you MUST upgrade to 10.2.0.3 or you MUST disable
> all function based indexes. (There is currently no separate
> patch reported for the problem).
In other words: if you are using Peopletools 8.48,
which for the FIRST time tries to make use of FBIs
- I wonder why, given they been available
since 8i, could it be Oracle knew of the problems
and told no one? - you'll be up the proverbial creek
without a paddle!
Meanwhile, if you are a sucker like me and have tried
to design a full-on application making extensive use of
said indexes - and other new functionality - in anything
before 10.2.0.3, you might as well have been shooting
yourself in the foot when it comes to providing stability
and reliability.
Given that those two requirements might be somewhat
essential to one's reputation as a designer and dba,
don't make me explain further how *pissed off* I am
at this and other little pearls of new functionality that
just plain do NOT work or are flaky as heck...
> If Oracle has managed to patch the problem (in a full release),
> why can't they describe the problem properly so that we can
> decide whether to patch it or ignore it as irrelevant. And why
> should I believe that a full patch release isn't going to introduce
> other problems on my system - I just want to fix the problem
> I know I have.
I don't want to flog this one much further, but indeed there is
a patch to this problem. For 10.2.0.2. Now, given that
other patches I have installed to solve similar problems
with FBI have ALL failed to deliver, what guarantees to
me that I won't be having incorrect results in my queries?
It's *only* the payroll system of a 65 billion dollar company,
what the heck, we can afford this sort of risk?
> Given the nature of many large organisations today - how often
> do you think people would notice if they got results which were
> a 'little bit' wrong ? How many people run reports and create
> screens which have guaranteed consistency checks built in so
> that a wrong answer has to appear twice in exactly the same
> way before it can get past audit ?
Well, try to explain to a payroll manager that her results
might not be correct and you don't know exactly when
or why or how?
And it's this sort of rubbish nonsense that I have had
to cope with for YEARS!
Any wonder I'm royally upset with Oracle
DA Morgan
> On Jul 17, 3:35 pm, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
> wrote:
>
> <sigh>, google groups is reeeeeealy starting to get on my nerves...
>
>>> I've yet to see you mention a single problem though I've invited
>>> you to do so.
>
> Like I said, Daniel: I won't do your homework.
And like I said ... it is not my issue. It is your issue: You brought
it up. Why is my spending my lab time helping you with something "my
homework?" Anyway looks like the issue was a straw man.
Frank van Bortel
Hash: SHA1
DA Morgan wrote:
> joel garry wrote:
>
>> ... why do you think so many things only use 7.3 features?
>
> Because many people are terminally lazy and many companies would
> rather make money selling consulting services (tuning) rather
> than making a decent product.
Why wouldn't that include oracle?
So far, I think Noons has a point. And I haven't
seen anything yet to prove Oracle will pick this
up and behave as a multi-million dollar company.
Heck - if it weren't for the IT industry we're
talking about, the company would have ceased
to exist - it would have been sued to death.
- --
Regards,
Frank van Bortel
Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFGnmNFLw8L4IAs830RAnMIAJ4/tRlzMiawvaGaYY/2gdg+QwdYRACbBKhZ
09S/HSUnKdOiY6rOek98/mk=
=Spme
-----END PGP SIGNATURE-----
Noons
> That statement was made with respect to RMAN. Please don't spin it out
> of context to try to make your point.
that statement has been used and abused by
Oracle marketing for the last 7 years, Daniel.
It's not you, it's them and their silly attitude
that I am against.
Noons
wrote:
Ah well: eventually google will have to stop blocking
my posts or this will end up in the blog as well..
> > I've yet to see you mention a single problem though I've invited
> > you to do so.
Like I said, Daniel: I won't do your homework.
> > Rather than spitting into the wind pick the three bugs that bug
> > you the most and send me code that will demo the problem.
No. You pick your browser and go to Metalink,
search for problems where I mentioned them, and
inspect the test cases there.
> In reply to a comment on a recent blog entryhttp://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
>
> Nuno gave me bug 5092688.8
Ah, you got it! Sorry, I wasn't sure you had
seen the reply. Thanks, Jonathan.
> This bug is marked as an important issue.
> Versions confirmed as being affected 10.1.0.5, 10.2.0.2
> Description: Wrong results are possible if a function based index exists on
> a table used in a query.
Actually there is a similar bug in 9i, different number.
I hit it a couple of years ago. Not nice that it isn't fixed
yet in 10g, let alone 9i!
Not nice at all!
What I meant when I said it is completely unacceptable
that egregious bugs like this, on features released
YEARS ago, are STILL not fixed!
> Workaround: Set "_disable_function_based_index"=TRUE
> Fixed in: 10.2.0.3 (Server Patch Set)
> Note the description - this means that if you are on 10.2.0.2
> you MUST upgrade to 10.2.0.3 or you MUST disable
> all function based indexes. (There is currently no separate
> patch reported for the problem).
In other words: if you are using Peopletools 8.48,
which for the FIRST time tries to make use of FBIs
- I wonder why, given they been available
since 8i, could it be Oracle knew of the problems
and told no one? - you'll be up the proverbial creek
without a paddle!
Meanwhile, if you are a sucker like me and have tried
to design a full-on application making extensive use of
said indexes and other new functionality in anything
before 10.2.0.3, you might as well have been shooting
yourself in the foot when it comes to providing
stability and reliability.
Given that those two requirements might be somewhat
essential to one's reputation as a designer and dba,
don't make me explain further how *pissed off* I am
at this and other little pearls of new functionality that
just plain do NOT work or are flaky as heck...
> If Oracle has managed to patch the problem (in a full release),
> why can't they describe the problem properly so that we can
> decide whether to patch it or ignore it as irrelevant. And why
> should I believe that a full patch release isn't going to introduce
> other problems on my system - I just want to fix the problem
> I know I have.
I don't want to flog this one much further, but indeed there is
a patch to this problem. For 10.2.0.2. Now, given that
other patches I have installed to solve similar problems
with FBI have ALL failed to deliver, what guarantees to
me that I won't be having incorrect results in my queries?
It's *only* the payroll system of a 65 billion dollar company,
what the heck, we can afford this sort of risk?
> Given the nature of many large organisations today - how often
> do you think people would notice if they got results which were
> a 'little bit' wrong ? How many people run reports and create
> screens which have guaranteed consistency checks built in so
> that a wrong answer has to appear twice in exactly the same
> way before it can get past audit ?
Well, try to explain to a payroll manager that her results
DA Morgan
Well you won't find me defending marketing until they finally learn the
difference between RAC and The Grid.
Every RAC class I teach I have to explain that it has nothing to do
with OEM Grid. And every Grid class that it doesn't require RAC. I
used to cringe every time I saw their advertisement on CNN. Where they
presented a graphical illustration of a cluster and then said "This is
the Oracle Grid." <shiver>
DA Morgan
> On Jul 17, 3:35 pm, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
> wrote:
>
> Ah well: eventually google will have to stop blocking
> my posts or this will end up in the blog as well..
>
>>> I've yet to see you mention a single problem though I've invited
>>> you to do so.
>
> Like I said, Daniel: I won't do your homework.
This is getting to be a broken record. You were the one complaining
about Oracle not fixing legacy bugs: Not me.
I've no issues so I'm perfectly content to keep digging into 11g
and verifying functionality.
I've an 11g RAC cluster in the lab that's been up since the minute it
was installed. Bounced the SAN while the instances were up. And crsctl
had it all back up in less than two minutes. No complaints here.
So, yet again, I've no problem ... I was offering to help you.
Apparently you've no issues with Oracle either so we are all happy.
Mark Townsend
>
> In reply to a comment on a recent blog entry
> http://dbasrus.blogspot.com/2007/07/vs-b-grand-final.html
>
> Nuno gave me bug 5092688.8
>
> The detail on Metalink is as follows:
>
> This bug is marked as an important issue.
> Versions confirmed as being affected 10.1.0.5, 10.2.0.2
> Description: Wrong results are possible if a function based index exists on
> a table used in a query.
> Workaround: Set "_disable_function_based_index"=TRUE
> Fixed in: 10.2.0.3 (Server Patch Set)
>
> Note the description - this means that if you are on 10.2.0.2
> you MUST upgrade to 10.2.0.3 or you MUST disable
> all function based indexes. (There is currently no separate
> patch reported for the problem).
I looked this one up. Bug was found internally by the Peoplesoft
regression testing, it was a regression introduced in 10.1.0.5 and also
found in 10.2.0.2. Reported on 13th April, workaround in place on the
21st of April, patches provided and also fixed via the patchset
mentioned. Basic problem is if a query is driving to a predicate based
on a column, and a filter on the same column uses an FBI, and the query
drives to a FFS, then there is a possibility of wrong results (too few
rows), in these two releases only. I will check why you can't see the
patches in Metalink.
I don't think this is what Nuno is talking about
Mark Townsend
>:-(
Mark Townsend
> Niall Litchfield wrote:
>> On Jul 17, 3:47 am, DA Morgan <damor...@psoug.org> wrote:
>>> I've yet to see you mention a single problem though I've invited
>>> you to do so.
>>
>> Should be a simple enough search on metalink.
>>
>> Look up for example bug 5014578 - reported a year and a half ago -
>> customer gets wrong results - slated to be fixed in 11 - admittedly
>> the customer is running solaris 64bit so the wait to get correct data
>> out of their database may only be a couple of years or so.
>
> I don't have a machine capable of running 64bit Solaris in the lab: 32
> but not 64. There is, however a 64 bit Solaris Beta available.
>
> If anyone in the Seattle area has a machine I could borrow for one day
> I'd be happy to run the test.
I looked at this one tonight. The problem boils down to the following
reproducible case
select 1 from dual
where ('Tout' = CASE 'Oui'
WHEN 'Oui' THEN 'Y'
WHEN 'Non' THEN 'N'
ELSE 'Tout' END)
/
Exactly as this - i.e it has to be literals used in this manner, with
this outcome.
This was reported in Feb 01, diagnosed by Feb 28, and assigned to a
developer to fix. Based on perceived priority it was fixed and checked
into the 11g code line in June. Priority was set low basically because
the query is pretty darn stupid when you look at it. In this case, it
was generated by an end-user access tool, which is presumably doing some
sort of weird type of dynamic query macro processing to force a certain
behavior that works across more than one database implemenation. There
has not been a single request for a backport for this bug in the year
and a half it has been open, and I also couldn't find any subsequent SRs
that were soft closed based on this as a known problem (My SR search was
not exhaustive).
However, I really don't think this bug is indicative of what Nuno is
talking about.
Mark Townsend
>
> I looked at this one tonight. The problem boils down to the following
> reproducible case
>
> select 1 from dual
> where ('Tout' = CASE 'Oui'
> WHEN 'Oui' THEN 'Y'
> WHEN 'Non' THEN 'N'
> ELSE 'Tout' END)
> /
>
> Exactly as this - i.e it has to be literals used in this manner, with
> this outcome.
>
Wow - Suddenly I had a flashback.
In a past life before Oracle I wrote language compilers in PL/1.
PL/1 allowed you to define literals that were also part of the reserved
word list for the language itself. So compiler code that read as
followed was entirely possible
If if = if then then = then else then = else.
You could also have boolean literals - true, false, yes, no, on, off etc
So code such as
if if is true then then is false else then is true
was also regular.
In fact, we delighted in writing the most obtuse code we could come up
with - youthful exuberance and maybe a modicum of job protection
One day a particular customers program caused a pointer exception in the
stack that flipped the static bits in the exact 2 byte word where the
boolean literals were stored.
So literals for true became false and vice versa.
Code that read one way now behaved exactly the opposite way.
That one took two of us 6 weeks to diagnose.
Noons
> Not my homework.
> Not my issue.
> Your issue.
Believe me: it ain't our issue.
It's Oracle's.
>
> I offered to help you by championing your issue. It is you, not me,
> that brought it up. So which is it?
>
> 1. Mark was right about the whining?
If customers - note the plural - complaining
about bugs still not fixed after YEARS of neglect
is now called "whining", then so be it.
> 2. In all sincerity you really don't care that much about the bugs
> because they are minor and only nuisance value?
1- A table gets updated in the WRONG schema.
2- A CLOB can't be reliably used in an ASSM tablespace.
3- A query returns WRONG number of rows or
just plain WRONG result set, randomly.
All of those are really "minor" problems.
Of course!
Well, they are for me now: I don't design/develop
as much as I used to. But it still aggravates
me to find that after so many years the darn things
are still not fixed!
> 3. As a fellow Aussie you like giving Mark a bad time?
Didn't even know he was one. You know: it's
hard for me to remember every single one
of the other 20,999,999 Aussies... :-)
>
> The questions are rhetorical, I'm just giving you a hard time, so
> don't feel obliged to respond. Going to New Zealand in November and
> if time permits stopping up your way so perhaps I can apologize for
> this harangue in person. <g>
I'll feel personaly slighted if you pop up and we
don't get a chance to share a few local brews,
or maybe indulge in a little bit of single malt
sampling. Might even be able to scrounge
a few old friends from Oracle as well to share
in the proceedings!
DA Morgan
>
>>
>> I looked at this one tonight. The problem boils down to the following
>> reproducible case
>>
>> select 1 from dual
>> where ('Tout' = CASE 'Oui'
>> WHEN 'Oui' THEN 'Y'
>> WHEN 'Non' THEN 'N'
>> ELSE 'Tout' END)
>> /
>>
>> Exactly as this - i.e it has to be literals used in this manner, with
>> this outcome.
>>
>
> Wow - Suddenly I had a flashback.
Great:
CREATE FLASHBACK ARCHIVE cdos
TABLESPACE flasharc
QUOTA 1 P
RETENTION 30 YEAR;
ALTER TABLE townsend FLASHBACK ARCHIVE cdos;
> In a past life before Oracle I wrote language compilers in PL/1.
>
> PL/1 allowed you to define literals that were also part of the reserved
> word list for the language itself. So compiler code that read as
> followed was entirely possible
>
> If if = if then then = then else then = else.
No doubt PLW-06010 was written with you in mind.
Note: Anyone interested in the FLASHBACK ARCHIVE syntax,above, will find
it released by Oracle at:
http://www.oracle.com/technology/products/database/oracle11g/pdf/flashback-data-archive-whitepaper.pdf
and a demo you can run when you get 11g is at:
http://www.psoug.org/reference/flash_archive.html
DA Morgan
> On Jul 18, 4:21 pm, DA Morgan <damor...@psoug.org> wrote:
>
>> Not my homework.
>> Not my issue.
>> Your issue.
>
> Believe me: it ain't our issue.
> It's Oracle's.
Well if Oracle doesn't have an issue
And I don't have an issue
And you don't have an issue
Who's got the champagne.
>> I offered to help you by championing your issue. It is you, not me,
>> that brought it up. So which is it?
>>
>> 1. Mark was right about the whining?
>
> If customers - note the plural - complaining
> about bugs still not fixed after YEARS of neglect
> is now called "whining", then so be it.
It is when they are asked to provide an example and then claim it
is someone else's issue. At least that's the dictionary definition
of whining.
>> 2. In all sincerity you really don't care that much about the bugs
>> because they are minor and only nuisance value?
>
> 1- A table gets updated in the WRONG schema.
So it is an issue for you: Send me a case I can test in 11g.
> 2- A CLOB can't be reliably used in an ASSM tablespace.
So it is an issue for you: Send me a case I can test in 11g.
> 3- A query returns WRONG number of rows or
> just plain WRONG result set, randomly.
So it is an issue for you: Send me a case I can test in 11g.
> All of those are really "minor" problems. Of course!
Yesterday it was my homework ... today it is your issue: What changed?
>> 3. As a fellow Aussie you like giving Mark a bad time?
>
> Didn't even know he was one. You know: it's
> hard for me to remember every single one
> of the other 20,999,999 Aussies... :-)
Mark is unforgettable. The other 20,999,998 I don't know about.
>> The questions are rhetorical, I'm just giving you a hard time, so
>> don't feel obliged to respond. Going to New Zealand in November and
>> if time permits stopping up your way so perhaps I can apologize for
>> this harangue in person. <g>
>
> I'll feel personaly slighted if you pop up and we
> don't get a chance to share a few local brews,
> or maybe indulge in a little bit of single malt
> sampling. Might even be able to scrounge
> a few old friends from Oracle as well to share
> in the proceedings!
Single malt sampling ... now you've got my attention. I'll be
in touch if my schedule allows me a stop: What city/airport?
Niall Litchfield
> CREATE FLASHBACK ARCHIVE cdos
> TABLESPACE flasharc
> QUOTA 1 P
> RETENTION 30 YEAR;
> Note: Anyone interested in the FLASHBACK ARCHIVE syntax,above, will find
> and a demo you can run when you get 11g is at:http://www.psoug.org/reference/flash_archive.html
all well and good - now if someone can dust off that 30 year old
software and the associated hardware and run it on the 30 year old os
and ...
archives worked when they were written - I think that they are
basically broken with digital storage.
Niall
Niall Litchfield
> I looked at this one tonight. The problem boils down to the following
> reproducible case
>
> select 1 from dual
> where ('Tout' = CASE 'Oui'
> WHEN 'Oui' THEN 'Y'
> WHEN 'Non' THEN 'N'
> ELSE 'Tout' END)
> /
>
> Exactly as this - i.e it has to be literals used in this manner, with
> this outcome.
>
> This was reported in Feb 01, diagnosed by Feb 28, and assigned to a
> developer to fix. Based on perceived priority it was fixed and checked
> into the 11g code line in June. Priority was set low basically because
> the query is pretty darn stupid when you look at it. In this case, it
> was generated by an end-user access tool, which is presumably doing some
> sort of weird type of dynamic query macro processing to force a certain
> behavior that works across more than one database implemenation.
Yes it's a stupid query - though describing business objects as a
weird end-user tool is perhaps a little harsh. Yes it does bad things,
it's users do bad things - but they are still valid things and they
tend to be for fairly valid business reasons.
In the end though I still stick with the fact that it was an example
of a class of bug (wrong results) that go to the heart of why someone
buys an rdbms product in the first place that doesn't get fixed
rapidly - personally I find three classes of bug particularly
pernicious and that sometimes, not always - appear to get treated
lightly by Oracle. For the record they are
wrong results.
database irrecoverability - eg.Note 434527.1, or the whole class of
rman errors with ntfs mounts that started with 10.2.0.x - nfs volume
not mounted with correct options.
security fixes.
> However, I really don't think this bug is indicative of what Nuno is
> talking about.- Hide quoted text -
well having now seen the blog I agree - it looks like there's a whole
raft of FBI and peoplesoft related issues at the heart of the problem.
I'm not going to go into application patching since I've yet to see a
vendor - including Oracle but also including their major competitors
that makes application patch management as simple as it should be.
Niall
Noons
Sydney Kingsford-Smith, of course!
Is there any other place in Australia?
<g,d&r, vvf>
Noons
wrote:
Let me see, Mark: I provide the bug
number to Jonathan and "this is not what
I'm talking about"? Are you even
READING?
Now: others may call it a "regression" in 10.1.0.5
and 10.2.0.2. If so,a regression to WHAT?
An earlier manifestation of the same bug,
isn't it?
Me, I prefer to call it a bug. And it negates the
whole pointof using a database, if it causes the wrong
resultset to be seen. And it has been around under
another bug number, since 9i. And it is a bug on
a feature that has been available since 8i: FBIs.
All points that both you and Daniel have repeatedly
ignored!
And like this one, there are at least two other
enormous bugs that are not yet guaranteed
of a fix, which I mentioned. I've hit them repeatedly
in 9i and 10g. And every single time I opened
a call with Metalick on them, only to be told they were
"known problems" that would be fixed in 10.2.0.3
and 11g.
Still haven't seen proof of it.
Noons
Before I forget:
>
> > 1- A table gets updated in the WRONG schema.
>
> So it is an issue for you: Send me a case I can test in 11g.
Set SGA to auto memory management
for everything and use a pga_aggregate
as well.
Create two schemas in the database,
with differently named tables and one
table with same name in both.
Load the system with heavy updating,
using vanilla UPDATE <tablename>
statements in both schemas. Add a few
heavy ORDER BY selects. Make sure
you are not using UPDATE <owner.tablename>.
Run them all under the username of one
of the schemas.
Then after a while, inject a few of those updates,
but this time on the table that is commonly named.
Increase load on these and watch which table
gets updated.
Happens since 9i, various Metalink SRs.
Workaround? Turn off the pga_aggregate and the
SGA auto memory management and go back to setting
all the umpteen memory caches manually.
No fix "until 11g".
>
> > 2- A CLOB can't be reliably used in an ASSM tablespace.
>
> So it is an issue for you: Send me a case I can test in 11g.
This one is easy: create tablespace with ASSM
turned on. Slap a CLOB extension there.
Insert a bucketload of rows in table with the CLOB,
less than 4K CLOB size.
Update those rows, set CLOB > 4K.
Rinse and repeat with a couple of concurrent
updaters.
Once the ASSM tablespace starts growing, watch
alert log for ORA600s. Fails with all
9i, all 10g.
Workaround? Turn off ASSM for tablespaces
with CLOB. No fix "until 11g".
>
> > 3- A query returns WRONG number of rows or
> > just plain WRONG result set, randomly.
>
> So it is an issue for you: Send me a case I can test in 11g.
This one is highly dependent on syntax
and load conditions. Admittedly, I wouldn't write
syntax like that. But others do. And it's legal
syntax so it better work properly, no?
I've got a variation with Peoplesoft tables,
that blows in execution time if I do a
INSERT SELECT, but runs OK if I
do just the SELECT itself.
Again, to do with FBIs: turn them into
normal indexes and the problem goes away.
Workaround? One cumulative patch to 10.2.0.2,
another extra patch and three undocumented
parameters set to FALSE. That's for 10.2.0.2.
Check the cumulative patch I gave before for
details on which releases are affected and which
patches are available. Starts in 9i, goes to
10.2.0.3.
Have fun. Or not...
DA Morgan
Not everyone is so fortune. The daughter of one my best friends in the
States will be spending the next two years of her life in Rockhampton at
CQU getting her BA degree. She wanted something different from Seattle:
She got it ... and she's happy ... go figure.
DA Morgan
Thanks. I will duplicate it Saturday.
Note to Mark: I sure hope I don't find it. <g>
Niall Litchfield
> Thanks. I will duplicate it Saturday.
>
> Note to Mark: I sure hope I don't find it. <g>
> --
> Daniel A. Morgan
> University of Washington
> Puget Sound Oracle Users Groupwww.psoug.org
Note 392673.1
You will likely want to be on 10.2.0.3 if this scenario applies -
though the intermittent nature of the bug makes it difficult to tell
if it's really fixed.
cheers
Niall
Mark Townsend
> On Jul 19, 12:35 pm, Mark Townsend <markbtowns...@sbcglobal.net>
> wrote:
>>> Nuno gave me bug 5092688.8
>>
>> I don't think this is what Nuno is talking about
>
> Let me see, Mark: I provide the bug
> number to Jonathan and "this is not what
> I'm talking about"? Are you even
> READING?
>
Yes.
You claimed that "Oracle continues to deliver new releases without
fixing first what are absolutely egregious bugs."
You also stated that the database (?) "fails consistently for nearly 7
years and the "dedicated" folks do preciously NOTHING to fix problems
that have seen three major releases without a permanent fix"
This concerns me. I asked you for some pointers to such problems so I
could investigate them.
You told me offline to go pound sand.
However, based on a posting on your blog, Jonathan offered 5092688.8 as
a potential example. You seemed to indicate that this was a correct example.
However when I looked at the specific problem, it has been fixed within
7 days of it being reported, it was fixed before 11g, it was not 7 years
old, and it has not been outstanding for three active releases.
Nuno - you have our attention. I would love to have concrete examples of
what you are reporting in the forum. I can then assure you that any
such examples will be actively reviewed at the highest levels in
development.
But you need to throw me a bone - give me a list of specific SRs or Bugs
that you think are indicative. I would love to remove as much as the
invective from this conversation as possible to get to a description of
a problem that is actionable.
Michel Cadot
"Mark Townsend" <markbt...@sbcglobal.net> a écrit dans le message de news: 46A0C746...@sbcglobal.net...
As you talk about a bone, here's one I found 2 days ago (SR6427362.992).
It is closed as a duplicate of bug 2499608 opened on 06-AUG-2002 and
never fixed.
The description is the following one:
<quote>
When NLS_NUMERIC_CHARACTERS is not set to the default '.,'
we get the following errors:
SQL> alter session set nls_numeric_characters='!:';
Session altered.
SQL> select to_number('1,234','9,999') from dual;
select to_number('1,234','9,999') from dual
*
ERROR at line 1:
ORA-01722: invalid number
SQL> select to_number('1,234','9,999.9') from dual;
TO_NUMBER('1,234','9,999.9')
----------------------------
1234
1 row selected.
First question: Why the error is reached in the first case?
Second question: Then why it is not in the second one?
</quote>
OK, it's not a terrific bug, easy to workaround, but
why 5 years without being fixed?
Regards
Michel
DA Morgan
I'm going to make sure it isn't in 11.1.0.x. <g>
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Cristian Cudizio
I found this example more an example of bad use of to_number (that
should not be permit in my opinion), because i think it is ambiguous.
I think that it should be used only with syntax select
to_number('1,234','9G999') A FROM DUAL; as said on metalink note
about the bug. I say this because i'm writing from italy where the
comma is used to separate decimals and so the ambiguity is frequent.
So i think it is normal to request at least to correct the problem
with new release but to hope Oracle will release a patch only for this
is too much.
Bye
Cristian Cudizio
http://oracledb.wordpress.com
http://cristiancudizio.wordpress.com
Michel Cadot
"Cristian Cudizio" <cristian...@yahoo.it> a écrit dans le message de news:
1185185715.3...@k79g2000hse.googlegroups.com...
Bye
Cristian Cudizio
http://oracledb.wordpress.com
http://cristiancudizio.wordpress.com
----------------------------------------
But there were 3 major versions since the problem was raised.
So it is not a matter of patch.
As for the matter of knowing if it is a bad use or not, this is
irrelevant to the fact that this MUST be corrected.
In France, we also use comma to separate decimals and dot
to separate groups but we get data for USA that use comma
to separate groups, this is why we have this statement for these
data and not 'G' that we use for ours.
Regards
Michel Cadot
NetComrade
wrote:
We hit this, we have many db's with almost identical schemas.. Is this
still not fixed? After we applied 10.2.0.3, I heard maybe one
complain. Lucky it was not a payroll database :)
http://groups.google.com/group/comp.databases.oracle.server/browse_frm/thread/84db8cf221d5781/eed68bf53ca0f7b6?lnk=st&q=author%3Anetcomrade&rnum=34#eed68bf53ca0f7b6
.......
We run Oracle 9iR2,10gR1/2 on RH4/RH3 and Solaris 10 (Sparc)
remove NSPAM to email
NetComrade
>On Mon, 16 Jul 2007 18:21:09 -0700, DA Morgan <damo...@psoug.org>
>wrote:
>
>>> ... why do you think so many things only use 7.3 features?
>>
>>Because many people are terminally lazy and many companies would
>>rather make money selling consulting services (tuning) rather
>>than making a decent product.
>
>Actually, no: Because many companies don't NEED the new features.
>We have one customer running a HRM package on 8i and Win2k.
>They don't upgrade the HRM package, because they don't need a new
>version (probably they aren't even aware there is a new one).
>Consequently they don't upgrade Microsux and they don't upgrade
>Oracle.
>Their server is 5 years old. It works!
If you walk into some datacenter, and you'll walk around the racks,
you'd be surprised how manymany 8-12year old servers still appear to
work. I have an 8 year old desktop that works.
NetComrade
wrote:
>Noons wrote:
>> On Jul 16, 11:54 pm, DA Morgan <damor...@psoug.org> wrote:
>> Let's see if google drops my reply now...
>
>We now have at least 4 copies of this exact same posting.
>
>Perhaps rather than jumping up and down about Oracle you should focus
>on your inability to master google.
>
>Sorry ... couldn't resist.
Did I mention Free Agent before ;)?
Noons
wrote:
> >Then after a while, inject a few of those updates,
> >but this time on the table that is commonly named.
> >Increase load on these and watch which table
> >gets updated.
>
> >Happens since 9i, various Metalink SRs.
> >Workaround? Turn off the pga_aggregate and the
> >SGA auto memory management and go back to setting
> >all the umpteen memory caches manually.
> >No fix "until 11g".
>
> We hit this, we have many db's with almost identical schemas.. Is this
> still not fixed? After we applied 10.2.0.3, I heard maybe one
> complain. Lucky it was not a payroll database :)
>
You're not the only one. Anyone running the same
table name in two schemas in same instance is exposed
to this problem, since 9ir1. There are umpteen calls on
this in Metalink since then, all answered and closed the
same way: upgrade to 10.2.0.3 or 11 or turn off all the
sga auto management switches. Oracle has done bleeding
nothing to fix this until 10.2.0.3 and even then it's not
reliable!
I got hit by this one when pulling in click results from
google, two years ago. Took us ages to figure out why
the heck we losing clicks! Then we found them in the
wrong schema... Suffice to say management was not
impressed at all!
It's why Oracle never recommends running two or
more of Peoplesoft or their own applications in the
same instance. No wonder, with 25000 tables getting
mixed data...
And they want to convince me they're running
"very large and mixed applications databases" in their
outsource service sites?
Yeah! Right...
NetComrade
wrote:
>On Jul 26, 2:04 pm, NetComrade <netcomradeNS...@bookexchange.net>
>wrote:
>
>> >Then after a while, inject a few of those updates,
>> >but this time on the table that is commonly named.
>> >Increase load on these and watch which table
>> >gets updated.
>>
>> >Happens since 9i, various Metalink SRs.
>> >Workaround? Turn off the pga_aggregate and the
>> >SGA auto memory management and go back to setting
>> >all the umpteen memory caches manually.
>> >No fix "until 11g".
>>
>> We hit this, we have many db's with almost identical schemas.. Is this
>> still not fixed? After we applied 10.2.0.3, I heard maybe one
>> complain. Lucky it was not a payroll database :)
>>
>
>You're not the only one. Anyone running the same
>table name in two schemas in same instance is exposed
>to this problem, since 9ir1. There are umpteen calls on
>this in Metalink since then, all answered and closed the
>same way: upgrade to 10.2.0.3 or 11 or turn off all the
>sga auto management switches. Oracle has done bleeding
>nothing to fix this until 10.2.0.3 and even then it's not
>reliable!
>
Actually, turning off sga management switches was not one of the
suggestions for us, but we don't use pga_aggregate_target b/c of
another extremely suckly oracle product called MTS (aka Shared Server)
(I think you mentioned this one earlier as well)
We'll keep this in mind, thanks. I had only one unconfirmed report of
this problem since 10.2.0.3 upgrade, but in 10.2.0.2 it was pretty
obvious, data 'owned' by certain app users inserted in the wrong
schema, which could be verified with timestamps only, didn't even have
to dig with 'log miner' (which I wasn't really looking forward to do
anyway)