Ridiculous query

Question

Have you any heard contraints can change your query results? Here is the one which happened on my 10g database. We found a query with self-join returned a wrong result (in this case, it returns 254, the correct result is 253). But if I drop the associated pk constraint, I got a correct result, if I add back the constraint, the result is wrong again. If you see the execution plan, you'll find oracle use different plan. I don't see any corruption in my database also I didn't get any errors when I run these queries. I have rebuild the index for several times and run analyze table validate structure, but
they are not helpful. Any thoughts about this?
SQL> select count(*)
2 from location.location room, location.location dorm, location.location campus, location.location school
3 where room.location_active_yn_flag = 'Y'
4 and room.parent_location_id = dorm.location_id
5 and dorm.parent_location_id = campus.location_id
6 and campus.parent_location_id = school.location_id
7 and (room.location_type_id = 18 or room.location_id = 1)
8 and (dorm.location_type_id = 17 or dorm.location_id = 1)
9 --and (campus.location_type_id = 16 or campus.location_id = 1)
10 --and (school.location_type_id = 6 or school.location_id = 1);
COUNT(*)
254
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=19 Card=1 Bytes=80
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=19 Card=84 Bytes=6720)
3 2 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Card
=172 Bytes=6708)
4 2 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Card
=259 Bytes=10619)
SQL> ALTER TABLE location.location
drop CONSTRAINT pk_location;
2
Table altered.
### Run above query again
COUNT(*)
253
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=38 Card=1 Bytes=11
9)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=38 Card=84 Bytes=9996)
3 2 HASH JOIN (Cost=28 Card=84 Bytes=8904)
4 3 HASH JOIN (Cost=19 Card=84 Bytes=6720)
5 4 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9
Card=172 Bytes=6708)
6 4 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9
Card=259 Bytes=10619)
7 3 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Ca
rd=1639 Bytes=42614)
8 2 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Card
=1639 Bytes=21307)
SQL> SQL> ALTER TABLE location.location
ADD CONSTRAINT pk_location PRIMARY KEY (location_id);
2
Table altered.
### Run above query again
COUNT(*)
254
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=19 Card=1 Bytes=80
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (Cost=19 Card=84 Bytes=6720)
3 2 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Card
=172 Bytes=6708)
4 2 TABLE ACCESS (FULL) OF 'LOCATION' (TABLE) (Cost=9 Card
=259 Bytes=10619)

Answer 1

Marcus,
Thank you for your reply. I have checked the bug you mentioned, I think it doesn't fit my case. Here in my case, the primary key changed the execution plan and gave me wrong results. I have contacted oracle support regarding this issue and submitted the trace file, but they ask me to provide the database to build the test case. Although we have seen this problem on 10.1.0.2 (solaris), 10.1.0.3 (linux) and 10.1.0.4 (solaris) with same query, but expdp/impdp the only table doesn't reproduce the error. No any errors returned while this query ran, this makes me not feel so confident for all other queries in my database. I would like to get some inputs from experts to figure out exactly what exactly goes wrong here.