I've discussed this with several colleagues but this is something new for
them also. This has been hard to believe for them also, so they have tried
these by themselves. Some queries give correct results but some doesn't.
I've used sqlplus, Oracle Enterprice Manager and Toad so the software is not
the problem.
- Jake -
SQL> select count(*) from ci_customer;
COUNT(*)
----------
138295
SQL> SELECT count(*) FROM ci_customer WHERE customer_state = 'ACTIVE';
COUNT(*)
----------
135324
SQL> SELECT count(*) FROM ci_customer WHERE customer_type <> 'PERSON';
COUNT(*)
----------
138292
SQL> SELECT count(*) FROM ci_customer WHERE customer_state = 'ACTIVE' AND
customer_type <> 'PERSON';
COUNT(*)
----------
4
"Jake S" <nos...@nospam.net> a écrit dans le message news:
jtLA9.151$ZR5....@read2.inet.fi...
The example you have given is entirely possible as you are attempting to
compare oranges and apples (customer_state and customer_type).
Have you a more concrete example of the data to show the count is wrong?
Have you done a select * instead of a select count(*) and got more than 4
records in your final example?
HTH
Mark Stafford
Sciamus Limited
http://www.sciamus.com
Please, read the example more carefully. Using common sense it's easy to
understand that customers that there are more than 4 customers that are not
'PERSON' but are 'ACTIVE'. I'm not a beginner with databases nor SQL and
there are more people in my company that are puzzled with this problem. I
don't post unnecessary messages. This is a cry for help.
> Have you a more concrete example of the data to show the count is wrong?
>
Unfortunately I cannot do that. This is a production database.
> Have you done a select * instead of a select count(*) and got more than 4
> records in your final example?
>
Yes I have. I've also tried all the possible combinations with this query.
- Jake -
It seems that you didn't understand. Please, read the example more
carefully. Using common sense it's easy to understand that there are more
than 4 customers that are not 'PERSON' but are 'ACTIVE'. I'm not a beginner
with databases nor SQL and there are more people in my company that are
puzzled with this problem. I don't post unnecessary messages. This is a cry
for help.
- Jake -
The answer was: yes, I've done that and no, I only get 4. I'm thinking that
indexes might be the problem.
- Jake -
I think you might receive that kind of result if the customer_type column
contains a null value because testing customer_type <> 'PERSON' is not the
correct way of doing it (in Oracle's SQL) if the field can contain a NULL
value. Moreover is the combination of the two logical expressions that is
misleading you in this case. I believe that what you wrote is legitimate on
AS400's SQL dialect where nulls do not exist, but not in Oracle's SQL.
Unfortunately at the moment of writing I can't test this, but what if you
replace the latter expression with ... AND (customer_type IS NULL OR
customer_type <> 'PERSON') ?
Bye,
Flavio
>I'm having strange problems with Oracle (8.1.7). Queries give results that
>are not possible. I added a simple example below. First two count values are
>correct, third is not possible, as you can see. Have you ever seen anything
>like this?
>
Seems strange indeed. I would say that the 3rd and the 4th result seem
to conflict with each other. Is ci_customer a plain table?
You might suffer from bugs. Go to metalink, go to bug database searchm
search with the keywords 'wrong result' and expect to find dozens...
Check the execution plan, and if any indexes are used for a query, try
specifying a full hint, in order to force a full table scan.
Kind Regards,
Herman de Boer
IT Consultancy Group bv.
You're right but in this case your logic is not applicaple because there is
a NOT NULL constraint:
SQL> select count(*) from ci_customer where customer_type IS NULL;
COUNT(*)
----------
0
- Jake -
No problems:
SQL> ANALYZE TABLE ci_customer VALIDATE STRUCTURE CASCADE;
Table analyzed.
- Jake -
Just for fun, try putting a /*+ full(ci_customer) */ hint on the query. If
an index is indeed that problem this should give you the correct result.
Do both columns have NOT NULL constraints on them?
just for interest:
what is the result of
select count(*) from
(select customer_state, customer_type
from ci_customer
where customer_state = 'ACTIVE'
intersect
select customer_state, customer_type
from ci_customer
where customer_type <> 'PERSON');
is customer_state nullable ?
(U already mentioned that customer_state isn't)
COUNT(*)
----------
138295
SQL> SELECT count(*) FROM ci_customer WHERE customer_state = 'ACTIVE';
COUNT(*)
----------
135324
select count(*), filter by customer_state='ACTIVE' and customer_state
not in ('ACTIVE')
If the sum of the last two does not sum up to count(*) then you
either have null columns in your table or may then have a real reason
to worry
Michael Tubuo Ngong
What happens when you try
SELECT count(*) FROM ci_customer WHERE customer_state <> 'ACTIVE' AND
customer_type = 'PERSON';
-- rajXesh
Jake,
The wrong result might be related to a bug in "bitmap conversion". Can
you check what the execution plan is for the last query? You could
also try something like
SELECT /*+ RULE */ count(*)
FROM ci_customer
WHERE customer_state = 'ACTIVE'
AND customer_type <> 'PERSON';
Regards,
Mike
Hmm. This should be a correct result.
SQL> SELECT /*+ RULE */ count(*)
FROM ci_customer
WHERE customer_state = 'ACTIVE'
AND customer_type <> 'PERSON';
COUNT(*)
----------
135321
We also found out that:
SQL> SELECT count(*) FROM ci_customer WHERE UPPER(customer_type) !=
'PERSON';
COUNT(*)
----------
138292
Could this be related with character sets somehow? If you see the first
example I posted, this doesn't completely make sense because:
SQL> select distinct customer_type from ci_customer;
CUSTOMER_TYPE
----------------------------------------------------------------------------
----
COMPANY
PERSON
- Jake -
SQL> SELECT count(*) FROM ci_customer WHERE customer_state <> 'ACTIVE' AND
customer_type = 'PERSON';
COUNT(*)
Soryy, I forgot to tell that both have NOT NULL constraint.
SQL> select count(*) from
(select customer_state, customer_type
from ci_customer
where customer_state = 'ACTIVE'
intersect
select customer_state, customer_type
from ci_customer
where customer_type <> 'PERSON');
COUNT(*)
----------
1
- Jake -
SQL> SELECT /*+ FORCE */ count(*) FROM ci_customer WHERE customer_state =
'ACTIVE' AND customer_type <> 'PERSON';
COUNT(*)
----------
4
- Jake -
Sorry you're having so much grief :(
Just a quick note to say that FORCE is not a valid hint (and is hence
ignored), FULL is the one you're after.
Cheers
Richard
"Jake S" <nos...@nospam.net> wrote in message
news:W50B9.22$Ph....@read2.inet.fi...
I'm getting used to the weird problems :) I didn't have time to check
syntax, so this is the correct one?
SQL> SELECT /*+ FULL */ count(*) FROM ci_customer WHERE customer_state =
'ACTIVE' AND customer_type <> 'PERSON';
COUNT(*)
----------
4
SQL> SELECT /*+ FULL */ count(*) FROM ci_customer WHERE customer_type <>
'PERSON' AND customer_state = 'ACTIVE';
> Using common sense it's easy to understand that there are more
> than 4 customers that are not 'PERSON' but are 'ACTIVE'.
I failed to see how this is common sense.
Did I misunderstand you or did you come to this conclusion :
count( customer_state = 'ACTIVE and customer_type <>
'PERSON')
must be much larger than 4 because both these counts are so high
count(customer_state = 'ACTIVE) : 135324
count(customer_type <> 'PERSON') : 138292
?
(123450000444555666667890123456780xxxx)
(xxxxabcdefghijklmmmmmmmnnnoppppptyuuuuu)
The two groups above can each have many, many members. But there may
be only a few members (the xxxx) that belong to both groups ( the
"and" operator in your case).
You can even try a count on the "or"
count( customer_state = 'ACTIVE' or customer_type <>
'PERSON')
The result should be 135324 + 138292 - 4.
This will be true regardless whether or not there are NULLs in the
table.
- Jusung Yang
You're completely right but e.g. use calculator and you understand. You just
didn' read the example carefully enough. When I said we are not beginners I
meant that.
By common sense I meant that if there are 10 customers in a database and 8
of them are 'ACTIVE' and 8 of them <> 'PERSON' that means that there must be
more than 1 customers that are both 'ACTIVE' AND <> 'PERSON'. Both columns
has NOT NULL constraint.
This is just a basic example, please don't argue with other possibilities, I
understand.
001 NOTACTIVE 'PERSON'
002 NOTACTIVE 'PERSON'
003 ACTIVE 'NOTPERSON'
004 ACTIVE 'NOTPERSON'
005 ACTIVE 'PERSON'
006 ACTIVE 'PERSON'
007 ACTIVE 'PERSON'
008 ACTIVE 'PERSON'
009 ACTIVE 'PERSON'
010 ACTIVE 'PERSON'
My mistake was to post the simpliest possible example at the first place.
And we haven't figured this out yet. First we thought this might be an index
problem but it's not. Now I'm trying to figure out what kind of a character
set problem might cause this. Refer to my other posts to see what I mean.
- Jake -
So would you post a full execution path for each
of the four queries - (not just the autotrace thing)
and check that the execution plan Oracle reports
is the one it actually uses.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____USA__________November 7/9 (Detroit)
____USA__________November 19/21 (Dallas)
____England______November 12/14
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Jake S wrote in message ...
Hi Jusung,
I think you've failed to notice that there are only 138295 rows in the
table. Therefore your result above is somewhat unlikely (actually, make that
impossible).
If there are only 138295 rows of which customer_state = 'ACTIVE' is 135324
and customer_type <> 'PERSON' is 138292, then the value of customer_state =
'ACTIVE' AND customer_type <> 'PERSON' *MUST* be between 135321 and 135324
inclusive (I think ;)
Therefore a value of just 4 can only be deemed as highly unfortunate (or to
put in another way, "what the ....".
Something is amiss.
I personally would like to see the execution plan and see what the optimizer
"thinks" it's doing. It certainly looks like the CBO has chucked a wobbly,
or some structure that the optimizer is trying to use (such as an index) is
corrupt in some way.
A search of metalink might shed some light.
Cheers
Richard
when you have a (finite) set
- of course in this newsgroup every set is finite -
with say n elements
"count(*) = n"
and you have property P1 which is fulfilled by p1 members of the set
"(count(*) where P1) = p1"
and a property P2 which is fulfilled by p2 members of the set
"(count(*) where P2) = p2"
"count(*) where (P1 AND P2)"
MUST BE AT LEAST p1 + p2 - n
so in jakes case
n = 138295
p1 = 135324
p2 = 138292
so jake's final query which results in "4" should be at least 135321.
as jake posted , a
SELECT /*+ RULE */ count(*)
FROM ci_customer
WHERE customer_state = 'ACTIVE'
AND customer_type <> 'PERSON';
yields exactly 135321
ok,
a simple select with no optimizer hint gives the wrong result 4,
a select with /*+RULE */ gives the right result.
IMHO, the following is clear:
a. either software (oracle) is buggy or index is corrupt
b. if index were corrupt (my first conjecture), an
analyze table ...
would have thrown an exception
(in which case i would have suggested, drop index and recreate it)
c. since it didn't throw an exception, still index can be corrupt
but then there is a bug in
analyze ..
Conclusion:
- in either case, software (oracle engine) is proved to be buggy
since mike liu posted
'...
The wrong result might be related to a bug in "bitmap conversion". Can
...'
I am quite sure he is right.
(mike: are U a programmer for oracle ?)
matthias
I certainly don't use my working hours to fool others if that's what you
meant. I appreciate all the help all of you have provided. The next step
would be to give you the execution plan as many of you have requested.
However, I'm reluctant to do that because if I follow the rules of my
complany I shouldn't post any messages that concern our business or
production.
Anyway, I'm thinking that we are in the wrong tracks. Indexes are not the
problem. I think this is some really weird character set problem because the
data is originated from a legacy system. However, that shouldn't be possible
because we (not me) used Java+JDBC to send data. Anyway, there are several
conversions along the way (don't ask). The next step we are going to take is
to send all this data to another database and see if we have the same
problems.
In any case that could be related to character sets because all the 4
customers we are discussed has been inserted with GUI i.e. different way
than all the others. That supports my theory because it's possible to get
right result several ways (sorry I didn't send these earlier):
SQL> SELECT count(*) FROM ci_customer WHERE customer_state = 'ACTIVE' AND
UPPER(customer_type) <> 'PERSON';
COUNT(*)
----------
135321
SQL> SELECT count(*) FROM ci_customer WHERE customer_type LIKE 'COMPANY' AND
customer_state LIKE 'ACTIVE';
COUNT(*)
----------
135321
- Jake -
Gentlemen,
I think we have a canard.
Jim
"Jake S" <nos...@nospam.net> wrote in message
news:Po4B9.149$Ph....@read2.inet.fi...
- Jusung yang
"Richard Foote" <richar...@bigpond.com> wrote in message news:<BD3B9.76954$g9.2...@newsfeeds.bigpond.com>...
You claim me to post false messages without checking my posts to other
newsgroups. It's quite easy to trace someone's message history, so I don't
think that was a nice thing to do.
- Jake -
"Jim Kennedy" <kennedy...@attbi.com> wrote in message
news:pj8B9.10527$WL3.2608@rwcrnsc54...
If it walks like a duck and it talks like a duck, its probably a duck.
Jim
"Jake S" <nos...@nospam.net> wrote in message
news:py1C9.47$od5....@read2.inet.fi...
Hi Jim,
Bloody hell Jim, if you ever come across a talking duck, for goodness sake
catch it. They're believed to be extremely rare. Although a right pain to
cook as they have tendency to plead "please don't eat me, please don't, ouch
..., that really hurt, put that feather back, oh please, someone help me,
HHHEEELLLPPPPPP ...."
English cricket batsmen are said to be extremely fond of ducks ...
Cheers ;)
Richard
I told you the other day to stop that.
Anyway, the RUGBY!
HaHa!
Regards,
Fighting back pommie whinger (with a grin).
Best as ever (and never take it too seriously).
Paul
If you do that again I'm afraid we'll have to ensure that Mr Bowie never
makes another trip down under <g>.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************
Hi Niall,
mmmmmmmmmmmmmmmm
Richard ;)
Hi Paul
I deserved that !!
Just wait until the World Cup, just you wait ....
>
> Regards,
> Fighting back pommie whinger (with a grin).
>
> Best as ever (and never take it too seriously).
Only way to be ;)
Cheers
Richard
> Paul
>
>
>
>> mmmmmmmmmmmmmmmm
Interseting choice of music - isn't that the opening few bars to 'Rivers
of Babylon' by Boney M, certainly sounds like it.
Also, on the subject of strange, I say Rolf Harris (bless him) on telly
tho other night doing a version of Bohemian Rhapsody - nice !
Cheers,
Norman.
PS. On TV the orther night there was a program called something like
'the best selling 100 singles of the past 50 years'. Tony Orlando and
Dawn were on doing 'Tie a yellow gibbon round the old paper bark tree'
and guess who was in the audience - you got it, Ziggy himself.
-------------------------------------
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:Norman...@LFS.co.uk
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-------------------------------------
You're kidding me, right???
Ughhh.
Shudder.
(Where did I leave my Stylophone?)
Regards
HJR
Nope - Rolf is big over here in the UK...
sad but true
--
==============================
Connor McDonald
"Some days you're the pigeon, some days you're the statue..."
--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************
"Howard J. Rogers" <howard...@yahoo.com.au> wrote in message
news:gfwC9.80000$g9.2...@newsfeeds.bigpond.com...
Hi Mr. Litchfield,
please let me know: How can you kill something that is already cold, stiff,
well - *dead*? This former beautiful piece of a musical genius has been
murdered by everyone who played it which name is not Mr. Page.
And I confess: I'm among the killers ;-)
Greetings from Germany,
Guido
--
My thougths don't reflect the ones of my employer. I'm grateful.
I'm afraid it's true, Rolf did do Bohemian Rhapsody - he even had a
video out as well :o)
It was not as good as his brilliant rendition of 'Stairway To Heaven' -
which I absolutely loved.
In fact, I have a CD from an Aussie TV program which features many
different versions of STH - how sick am I then ?
Cheers,
Norman.
PS. You left your stylophone here
http://mars.spaceports.com/~stimpyjc/stylophone.htm
<evil cackling laughter goes here>
I've just spent a very pleasant 17 seconds re-living the very best moments
of my childhood.
Many thanks!!!!
Now... where did I pack the larger of my two wobble boards?
;-)
HJR
"Norman Dunbar" <Norman...@lfs.co.uk> wrote in message
news:E2F6A70FE45242488C86...@lnewton.leeds.lfs.co.uk...
>
> Now... where did I pack the larger of my two wobble boards?
>
I was done posting for the night, until I saw this.
Never mind where I packed the larger of my two wobble boards.
The important question is where did I pack my two wobble boards of lager?
Regards,
Paul
http://www.amazon.com/exec/obidos/ASIN/B000001XVK/avsearch-musicasin-20/102-5341632-1172907
and http://www.dreadzeppelin.com/ ( ledzep in rasta style with
mexican elvis impersonator. I must say, I've seen them in concert and
they are actually very good.)
And of course, http://www.iloverichardcheese.com
And I'm just blanking on the name of the group that does
>
> Cheers,
> Norman.
>
> PS. You left your stylophone here
> http://mars.spaceports.com/~stimpyjc/stylophone.htm
> <evil cackling laughter goes here>
That's goin' on the webpage! Haven't tried it on my AMD that always
does extremely strange behaviour with flash.
>
> -------------------------------------
> Norman Dunbar
> Database/Unix administrator
> Lynx Financial Systems Ltd.
> mailto:Norman...@LFS.co.uk
> Tel: 0113 289 6265
> Fax: 0113 289 3146
> URL: http://www.Lynx-FS.com
> -------------------------------------
jg
--
@home is bogus.
What is it with geeks and music?
I thought you'd like that one !!!
How I came up with it was quite simple. Many years ago, I was sent a URL
to another website featuring an on-line stylopohone and I was going to
post that on, however, I tested it first and found that it no longer
exists. So I did a quick Google for "online stylophone' and got quite a
few hits.
You'd be surprised how many on-line whachamacallits there are out there
:o)
Now, why can't I learn to 'circular breathe' so I can play my damned
didgeridoo without passing out :o)
Cheers,
Norman.
-------------------------------------
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:Norman...@LFS.co.uk
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-------------------------------------
http://www.amazon.com/exec/obidos/tg/detail/-/B000005J65/qid=1037872725/
sr=1-1/ref=sr_1_1/104-5593226-3194344?v=glance&s=music
Cheers,
Norman.
-------------------------------------
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:Norman...@LFS.co.uk
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-------------------------------------
-----Original Message-----
From: joel-...@home.com (Joel Garry) [mailto:joel-...@home.com]
Posted At: Thursday, November 21, 2002 1:21 AM
Posted To: server
Conversation: Queries give impossible results
Subject: Re: Queries give impossible results
http://www.amazon.com/exec/obidos/ASIN/B000001XVK/avsearch-musicasin-20/
Regards
HJR
"Norman Dunbar" <Norman...@lfs.co.uk> wrote in message
news:E2F6A70FE45242488C86...@lnewton.leeds.lfs.co.uk...
Given that using the UPPER() function returns the proper result Jake's
assessment that it's data-related (possibly due to the tool used for
insertion) appears to be correct. I also imagine that Jake is busy
working on what anomalies are present in the data causing such
behaviour. Yes, an explain plan may help dissect this and shed light
on the problem, it also may not. Confidentiality agreements can be
quite, well, 'sticky' and being overly cautious is not a crime. He is
NOT the 'boss' in this situation, someone ELSE is and Jake is subject
to his superior's wishes and decisions. And, you have no place
second-guessing that decision.
You've again made rude, useless comments and baseless accusations. Is
this what you do best? Prove that Jake is lying; I doubt you can.
"Jim Kennedy" <kennedy...@attbi.com> wrote in message news:<V_4C9.40922$WL3.17139@rwcrnsc54>...
any news from your part of the (Oracle-)world ?
matthias
I really think that this is a data related problem, because UPPER fixes the
problem and customer_type LIKE 'COMPANY' AND customer_state LIKE 'ACTIVE'
works fine also. I've met some problems with character sets before but
nothing like this, so I actually understand if there are some of you who
think that the original message was a hoax (especially when most of my
messages are posted in finnish with my real name :). I have my doubts but
I'll post you a solution when everything is clear. Hope that won't take
longer than a week or two.
- Jake -
"Matthias Rogel" <ro...@web.de> wrote in message
news:3DDDD2A6...@web.de...