CBO is smart enough. It kicks in whenever you issue a query and can apply lots of tricks to simplify query processing. So, another thing it can do is elimination of the ORDER BY clause from a query. This can be useful to know if you expect sorting in the plan which does not show up and you have to know the “why”. For example, consider the following query:
SELECT * FROM TESTTABLE1 S WHERE ID = 6 ORDER BY ID;
Looks like the plan should have a SORT ORDER BY operator which is not the case:
Plan hash value: 3427422027 ———————————————————————————————————————————————— | Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | ———————————————————————————————————————————————— | 0 | SELECT STATEMENT | | 2501 | 1292K| 122 (0) | 00:00:01 | |* 1 | TABLE ACCESS FULL | TESTTABLE1 | 2501 | 1292K| 122 (0) | 00:00:01 | ———————————————————————————————————————————————— Predicate Information (identified by operation id): —————————————————
Let’s see what happens behind the scene via the CBO trace:
OBYE: Order by element marked for removal from query block SEL$1 (#0) equality filter pred “ID” OBYE: Removed ORDER BY from query block SEL$1 (#0) Registered qb: SEL$9FB2EC53 0xbf94df8 (ORDER BY REMOVED FROM QUERY BLOCK SEL$1; SEL$1) Final query after transformations:******* UNPARSED QUERY IS ******* SELECT [not showing columns here] FROM “TESTTABLE1” WHERE “TESTTABLE1”.”ID”=6 kkoqbc: optimizing query block SEL$9FB2EC53 (#0)
So, the CBO sees an equality predicate and decides to remove the ORDER BY clause from it. This makes sense because no matter what the cardinality is – all values going to be the same – no need to do any sorting, therefore. It works in 12.1 and later; didn’t check it for earlier versions. So, no surprise why we expect sorting but don’t observe it in the final plan.
This can be controlled via “_optimizer_order_by_elimination_enabled” undocumented parameter. Plus, two hints are also there for switching it on and off: /*+ ELIMINATE_OBY */ and /*+ NO_ELIMINATE_OBY */.