Thank you and I think that dissecting execution plans would make a great blog post. I shall add that to my list of ideas. Thanks again.

Wow you certainly are a great teacher .
was wondering if that dissection would be an item of your next blog under the heading troubleshooting bad execution plans by dissecting the joins one step at a time.

excellent piece of advise by the way.

regards
Hrishy

You can cancel a query and still call dbms_xplan.display_cursor(format=>’allstats last’), and it will display the actual rows it returned thus far for the row sources that have been executed thus far, but I’m not certain this will be of much use. I would liken it to trying to find out how many rows a query returns without actually running the query. A database does not know how many rows will be returned until there are no more rows to be fetched.

What I would recommend in your case is to break the query into bite size chunks. Start with single table predicates and validate the estimates are reasonable. Then start with a 2 table join, validating the cardinality again. Add one more table, and validate again. Keep doing this until you find the join where the cardinality estimates go wrong.

Hope that helps.

I notice that the gather_plan_statistics hint that you use to have look at the actual and estimated cardinality requires that the sql run to completion and only then the call to the dbms_xplan.display_cursor is made .

If my query takes an hour or so and i am one of those impatient types would it be possible for me to do a control +C on the query and then make a call to the dbms_xplan.display_cursor to reveal the estimated and actual cardinalities .(don’t have accesses to oracle at the moment so i am not able to verify this)or is their any other method

regards
Hrishy

-----------------------------------------------------------------------------------
| Id  | Operation                    | Name            | Starts | E-Rows | A-Rows |
-----------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE              |                 |      1 |      1 |      1 |
|*  2 |   TABLE ACCESS BY INDEX ROWID| WB_JOB          |      1 |      1 |   1657 |
|   3 |    NESTED LOOPS              |                 |      1 |      1 |  46346 |
|*  4 |     HASH JOIN                |                 |      1 |      1 |  23171 |
|*  5 |      INDEX RANGE SCAN        | PS0PAY_CALENDAR |      1 |      1 |      1 |
|   6 |      VIEW                    | VW_SQ_1         |      1 |   1925 |  23171 |
|   7 |       HASH GROUP BY          |                 |      1 |   1925 |  23171 |
|   8 |        NESTED LOOPS          |                 |      1 |   1925 |  33020 |
|*  9 |         INDEX RANGE SCAN     | PS0PAY_CALENDAR |      1 |      1 |      1 |
|* 10 |         INDEX FAST FULL SCAN | WB_JOB          |      1 |   2000 |  33020 |
|* 11 |     INDEX RANGE SCAN         | WB_JOB          |  23171 |      1 |  23174 |
-----------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
   1 - SEL$11A0A147
   2 - SEL$11A0A147 / B@SEL$2
   5 - SEL$11A0A147 / A@SEL$2
   6 - SEL$975CABD1 / VW_SQ_1@SEL$5D2EE882
   7 - SEL$975CABD1
   9 - SEL$975CABD1 / A@SEL$D5F10F0C
  10 - SEL$975CABD1 / F@SEL$3
  11 - SEL$11A0A147 / B@SEL$2

There are only 2 query blocks:
1 – SEL$11A0A147
7 – SEL$975CABD1

Query block ID=1 should have a cardinality of 1657 but says 1 so I’ll put in the hint
cardinality(SEL$11A0A147 1657
Query block at ID=7 should have a cardinality of 23171 but is esitmated at 1925 so I add the hint
cardinality(SEL$975CABD1 23171)
but after adding the hint the query plan and statistics are exactly the same

SELECT
      /*+
       cardinality(SEL$11A0A147  1)
       cardinality(SEL$975CABD1  23171)
	 */
    A.COMPANY
  , A.PAYGROUP
from  PS_PAY_CALENDAR A
    , WB_JOB B
where A.RUN_ID = 'PD2'
  and A.PAY_CONFIRM_RUN = 'N'
  and B.COMPANY = A.COMPANY
  and B.PAYGROUP = A.PAYGROUP
  and B.EFFDT = (
	 SELECT
	 MAX(F.EFFDT)
      from WB_JOB F
      where F.EMPLID = B.EMPLID
        and F.EMPL_RCD# = B.EMPL_RCD#
        and F.EFFDT< = A.PAY_END_DT)
)

----------------------------------------------------------------
| Id  | Operation                    | Name            | Rows  |
----------------------------------------------------------------
|   0 | SELECT STATEMENT             |                 |       |
|   1 |  SORT AGGREGATE              |                 |     1 |  SEL$11A0A147
|*  2 |   TABLE ACCESS BY INDEX ROWID| WB_JOB          |     1 |  SEL$11A0A147 / B@SEL$2
|   3 |    NESTED LOOPS              |                 |     1 |
|*  4 |     HASH JOIN                |                 |    10 |
|*  5 |      INDEX RANGE SCAN        | PS0PAY_CALENDAR |     1 |  SEL$11A0A147 / A@SEL$2
|   6 |      VIEW                    | VW_SQ_1         | 23171 |  SEL$975CABD1 / VW_SQ_1@SEL$5D2EE882
|   7 |       HASH GROUP BY          |                 | 23171 |  SEL$975CABD1
|   8 |        NESTED LOOPS          |                 |  1925 |
|*  9 |         INDEX RANGE SCAN     | PS0PAY_CALENDAR |     1 |  SEL$975CABD1 / A@SEL$D5F10F0C
|* 10 |         INDEX FAST FULL SCAN | WB_JOB          |  2000 |  SEL$975CABD1 / F@SEL$3
|* 11 |     INDEX RANGE SCAN         | WB_JOB          |     1 |  SEL$11A0A147 / B@SEL$2

but the it doesn’t seem to affect the estimated cardinalities

 ID     STARTS     E_ROWS     A_ROWS      RATIO RATIO_G    operation
--- ---------- ---------- ---------- ---------- ---------- -----------------------------------------
  0                                                        SELECT STATEMENT ~
  1          1          1          1          1             SORT ~ AGGREGATE
  2          1          1       1657      .0006 6---         TABLE ACCESS ~ BY INDEX ROWID WB_JOB
  3          1          1      46346          0 2----         NESTED LOOPS ~
  4          1          1      23171          0 4----          HASH JOIN ~
  5          1          1          1          1                 INDEX ~ RANGE SCAN PS0PAY_CALENDAR
  6          1       1925      23171      .0831 8-              VIEW ~  VW_SQ_1
  7          1       1925      23171      .0831 8-               HASH ~ GROUP BY
  8          1       1925      33020      .0583 5-                NESTED LOOPS ~
  9          1          1          1          1                    INDEX ~ RANGE SCAN PS0PAY_CALENDAR
 10          1       2000      33020      .0606 6-                 INDEX ~ FAST FULL SCAN WB_JOB
 11      23171      23171      23174      .9999                INDEX ~ RANGE SCAN WB_JOB