The numbers help to explan what’s going on in the buffer sort. We see a merge join cartesian (which, in this case, looks like an accident – the optimizer may have expected just one row to come out of the GTT_REB_GRP_HDLE_RATE table – the name suggests it’s a global temporary table, and they often cause problems to the optimizer). To make this join more efficient, Oracle has scanned the VP_REBATE_CONTROL_DTL just once, producing 119 rows and stuffing them into a buffer.

We then see that the buffer sort operation has produced 7,854 rows – why ? Because Oracle has scanned the buffer once for every row in the driving table. (Quick check: 66 * 119 = 7,854).

Footnote: The owner of the query is going to be using dbms_xplan, checking the estimated cardinalities and predicates, to check why Oracle came up with a Cartesian merge join.