-----------------------------------------------------------------------------------
| 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

The CARDINALITY hint only tells the Optimizer how many rows to expect from a given row source, so it must be applied to a table, subquery, query block, table function, etc.

In your case I think you will have to use a query block alias because you want to tell the Optimizer the cardinality coming out of a join. There easiest way to do this is to use this command:
select * from table(dbms_xplan.display_cursor(null,null,'+alias'));
to print the Query Block Name and Object Alias.

Here is a simple example with EMP and DEPT:

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------
SQL_ID	3s509v1mg0f9c, child number 0
-------------------------------------
select a.ename from emp a, dept b where a.sal > 100 and b.deptno > 10
and a.empno = (select max(c.empno) from emp c where c.deptno=b.deptno)

Plan hash value: 1741140072

---------------------------------------------------------------------------------
| Id  | Operation	      | Name	| Rows	| Bytes | Cost (%CPU)| Time	|
---------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      | 	|	|	|     8 (100)|		|
|*  1 |  HASH JOIN	      | 	|     8 |   696 |     8  (25)| 00:00:01 |
|   2 |   NESTED LOOPS	      | 	|     8 |   432 |     4  (25)| 00:00:01 |
|   3 |    VIEW 	      | VW_SQ_1 |    11 |   308 |     4  (25)| 00:00:01 |
|   4 |     HASH GROUP BY     | 	|    11 |   572 |     4  (25)| 00:00:01 |
|*  5 |      TABLE ACCESS FULL| EMP	|    11 |   572 |     3   (0)| 00:00:01 |
|*  6 |    INDEX UNIQUE SCAN  | PK_DEPT |     1 |    26 |     0   (0)|		|
|*  7 |   TABLE ACCESS FULL   | EMP	|    14 |   462 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$C772B8D1
   3 - SEL$683B0107 / VW_SQ_1@SEL$7511BFD2
   4 - SEL$683B0107
   5 - SEL$683B0107 / C@SEL$2
   6 - SEL$C772B8D1 / B@SEL$1
   7 - SEL$C772B8D1 / A@SEL$1

Now add the hint.

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
SQL_ID	71qkwmpfycyug, child number 0
-------------------------------------
select /*+ cardinality(SEL$683B0107 1000) */ a.ename from emp a, dept b where
a.sal > 100 and b.deptno > 10 and a.empno = (select max(c.empno) from emp c
where c.deptno=b.deptno)

Plan hash value: 2484712894

-----------------------------------------------------------------------------------------
| Id  | Operation		      | Name	| Rows	| Bytes | Cost (%CPU)| Time	|
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT	      | 	|	|	|     7 (100)|		|
|   1 |  NESTED LOOPS		      | 	|     3 |   144 |     7  (29)| 00:00:01 |
|   2 |   MERGE JOIN		      | 	|     3 |   126 |     7  (29)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| EMP	|    14 |   196 |     2   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN	      | PK_EMP	|    14 |	|     1   (0)| 00:00:01 |
|*  5 |    SORT JOIN		      | 	|     3 |    84 |     5  (40)| 00:00:01 |
|   6 |     VIEW		      | VW_SQ_1 |     3 |    84 |     4  (25)| 00:00:01 |
|   7 |      HASH GROUP BY	      | 	|     3 |    39 |     4  (25)| 00:00:01 |
|*  8 |       TABLE ACCESS FULL       | EMP	|    11 |   143 |     3   (0)| 00:00:01 |
|*  9 |   INDEX UNIQUE SCAN	      | PK_DEPT |     1 |     6 |     0   (0)|		|
-----------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$C772B8D1
   3 - SEL$C772B8D1 / A@SEL$1
   4 - SEL$C772B8D1 / A@SEL$1
   6 - SEL$683B0107 / VW_SQ_1@SEL$7511BFD2
   7 - SEL$683B0107
   8 - SEL$683B0107 / C@SEL$2
   9 - SEL$C772B8D1 / B@SEL$1

Hope this helps.

 STARTS     E_ROWS     A_ROWS      RATIO operation
------- ---------- ---------- ---------- ------------------------------------------
                                         SELECT STATEMENT ~
      1          1          1          1  SORT ~ AGGREGATE
      1          1       1657      .0006   TABLE ACCESS ~ BY INDEX ROWID WB_JOB
      1          1      46346          0    NESTED LOOPS ~
      1          1      23171          0     HASH JOIN ~
      1          1          1          1      INDEX ~ RANGE SCAN PS0PAY_CALENDAR
      1       1925      23171      .0831      VIEW ~  VW_SQ_1
      1       1925      23171      .0831       HASH ~ GROUP BY
      1       1925      33020      .0583        NESTED LOOPS ~
      1          1          1          1         INDEX ~ RANGE SCAN PS0PAY_CALENDAR
      1       2000      33020      .0606         INDEX ~ FAST FULL SCAN WB_JOB
  23171      23171      23174      .9999     INDEX ~ RANGE SCAN WB_JOB

I’ve tried cardinality hint to fix the discrepancy at the next to last line of the plan. For example

SELECT
    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
      /*+ cardinality(F 33000) */
	 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)
/

but whether I shift the cardinality up or down via the hint, the discrepancy in the plan becomes works (both with higher and lower cardinality hint values)

They aren’t completely OLTP, there’s some amount of batching.

Some FTS (and Index FFS) happen due to purposeful trade-offs on whether an index is there. Some issues also happen by accident or functional creep.

So, your test is a little bit applicable to OLTP too, and thank you for it, and thanks to Oracle for making the best of odd situations by default (absent bugs, of course).

>> It would be interesting to observe the impact of the back-end RAID (or ASM stripe size) on this test.

What would be interesting about it?
What metrics would you want to observe?
What would you expect to happen?

I don’t think it is any secret that when reading a significant amount of data (e.g FTS) that larger I/Os are more efficient. MBRC exists for this exact reason. Unfortunately there are many layers that I/Os can be fragmented before the I/O actually gets to the physical disk. Sometimes they are reassembled at the storage level, but not always. This doesn’t present a problem in itself per se, but it does lower the efficiency of each physical disk. Some storage also uses read-ahead/prefetch algorithms to accelerate such scans.

>> let’s not forget that this only applies to full-scan reads

I don’t think anyone is forgetting. I clearly stated this experiment was run with 100% physical I/O and a FTS. I would hope that neither of these would be present in an OLTP database. This is most applicable to a DSS workload (partition scans) where large reads are common.

>> the Oracle database can decide the optimal MBRC no matter what the blocksize, demonstrating there is no advantage to a larger (or even smaller) blocksize in this case.

It would be interesting to observe the impact of the back-end RAID (or ASM stripe size) on this test.

Also, let’s not forget that this only applies to full-scan reads, and MBRC will not help many OLTP systems.