A couple of things first:

(a) there are articles on this blog pointing out that if you want to give someone an execution plan it should use dbms_xplan, and you have to supply the predicate section
(b) you haven’t helped me to help you by formatting your code to make it easy to read – see the “How to Comment” link near the top right hand side (so I had to edit it)
(c) this isn’t the autotrace output from 10.2.0.4 – are you using a 9i client ?
(d) this isn’t AskTom – I don’t do troubleshooting for people
(e) part of your answer may be related to an example I give in my chapter of “Expert Oracle Practices” (due out January)

Question 1: In theory, cost is time; but the optimizer is not perfect and there are many reasons why the optimizer’s calculated cost and the final run time of the query don’t seem to be related. Your first execution plan operates as a filter subquery, and it’s impossible to predict how many times the subquery will operate – but for the purposes of costing, Oracle assumes it will be once per row returned from the driving rowsource (hence the very high cost in your case). The cardinality of one may be variation of a bug I’ve found in 10gR2 relating to aggregate subqueries that result in a cardinality of one after filtering.

Question 2: See end of question 1.

Can you please help me to understand the following :
Oracle Version :10.2.0.4.0

When I trying running the query1 it takes ages to finish compared to query 2 which takes seconds.

Question 1 :The COST of query2 is almost 350 times more. What is the reason behind this ?
Question 2: The query returns 90 rows. But why the cardinality is different in the plans of the queries ? Isn’t cardinality should be the same as the number of rows returned ?

I have used autotrace to generate the plan and the gem.ref_quotation table is analyzed.

Thanks,

QUERY 1:

select QUOTATION_INSTR_ID, quotation_perm_id from
gem.ref_quotation where QUOTATION_INSTR_ID in
(select QUOTATION_INSTR_ID
 from  gem.ref_quotation
where  QUOTATION_END_DATE is null
and QUOTATION_IS_PRIMARY = 1
group by QUOTATION_INSTR_ID
having count(*) > 1)
order by QUOTATION_INSTR_ID;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=355664 Card=1 Bytes=17)
   1    0   SORT (ORDER BY) (Cost=355664 Card=1 Bytes=17)
   2    1     FILTER
   3    2       TABLE ACCESS (FULL) OF 'REF_QUOTATION' (TABLE) (Cost=385 Card=58769 Bytes=999073)
   4    2       FILTER
   5    4         SORT (GROUP BY NOSORT) (Cost=7 Card=1 Bytes=10)
   6    5           TABLE ACCESS (BY INDEX ROWID) OF 'REF_QUOTATION' (TABLE) (Cost=7 Card=1 Bytes=10)
   7    6             INDEX (RANGE SCAN) OF 'QUOTATION_INSTR_ID' (INDEX) (Cost=3 Card=3)

Query 2:
select QUOTATION_INSTR_ID, quotation_perm_id from
gem.ref_quotation where QUOTATION_INSTR_ID in
(select QUOTATION_INSTR_ID
 from  gem.ref_quotation
where  QUOTATION_END_DATE is null
and QUOTATION_IS_PRIMARY = 1
group by QUOTATION_INSTR_ID
having count(*) > 1)
order by QUOTATION_INSTR_ID;

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1019 Card=379 Bytes=8338)
   1    0   SORT (ORDER BY) (Cost=1019 Card=379 Bytes=8338)
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'REF_QUOTATION' (TABLE) (Cost=6 Card=3 Bytes=45)
   3    2       NESTED LOOPS (Cost=1018 Card=379 Bytes=8338)
   4    3         VIEW OF 'VW_NSO_1' (VIEW) (Cost=402 Card=2433 Bytes=17031)
   5    4           FILTER
   6    5             HASH (GROUP BY) (Cost=402 Card=122 Bytes=24330)
   7    6               TABLE ACCESS (FULL) OF 'REF_QUOTATION' (TABLE)(Cost=387 Card=58769 Bytes=587690)
   8    3         INDEX (RANGE SCAN) OF 'QUOTATION_INSTR_ID' (INDEX) (Cost=2 Card=3)