Comments on: Invalid Hints are Silently Ignored? An Invalid USE_HASH Hint Transforms a Sort-Merge Join into a Nested Loops Join http://hoopercharles.wordpress.com/2011/09/30/invalid-hints-are-silently-ignored-an-invalid-use_hash-hint-transforms-a-sort-merge-join-into-a-nested-loops-join/ Miscellaneous Random Oracle Topics: Stop, Think, ... Understand Thu, 23 May 2013 04:02:42 +0000 hourly 1 http://wordpress.com/ By: Charles Hooper http://hoopercharles.wordpress.com/2011/09/30/invalid-hints-are-silently-ignored-an-invalid-use_hash-hint-transforms-a-sort-merge-join-into-a-nested-loops-join/#comment-3991 Fri, 30 Sep 2011 18:34:36 +0000 http://hoopercharles.wordpress.com/?p=5492#comment-3991 Here is another fun experiment. Page 502 of the book (that was mentioned at the beginning of this article) showed how to use the OPTIMIZER_FEATURES_ENABLE hint:

SELECT /*+ optimizer_features_enable('10.2') */ *
FROM EMP JOIN DEPT USING(DEPTNO);

That hint does not look right. Why?

SQL> ALTER SESSION SET OPTIMIZER_FEATURES_ENABLE='10.2';
ERROR:
ORA-00096: invalid value 10.2 for parameter optimizer_features_enable, must be
from among 11.2.0.2.1, 11.2.0.2, 11.2.0.1, 11.1.0.7, 11.1.0.6, 10.2.0.5,
10.2.0.4, 10.2.0.3, 10.2.0.2, 10.2.0.1, 10.1.0.5, 10.1.0.4, 10.1.0.3, 10.1.0,
9.2.0.8, 9.2.0, 9.0.1, 9.0.0, 8.1.7, 8.1.6, 8.1.5, 8.1.4, 8.1.3, 8.1.0, 8.0.7,
8.0.6, 8.0.5, 8.0.4, 8.0.3, 8.0.0

OK, so changing the parameter directly to 10.2 does not work. What happens when it is attempted in a hint? Here is a test script to see what happens:

ALTER SESSION SET TRACEFILE_IDENTIFIER = 'USE_HASH2_10053';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';

SET AUTOTRACE TRACEONLY EXPLAIN
SELECT /*+ OPTIMIZER_FEATURES_ENABLE('10.2') USE_HASH(T1 T2) */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;
 
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
 
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'USE_HASH3_10053';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
 
SELECT /*+ USE_HASH(T1 T2) OPTIMIZER_FEATURES_ENABLE('10.2') */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;
 
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';
 
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'USE_HASH4_10053';
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
 
SELECT /*+ OPTIMIZER_FEATURES_ENABLE('10.2.0.4') USE_HASH(T1 T2) */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;
 
ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT OFF';

The results follow:

SQL> SELECT /*+ OPTIMIZER_FEATURES_ENABLE('10.2') USE_HASH(T1 T2) */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 412793182

----------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   1 |  MERGE JOIN         |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   2 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  4 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL| T2   |   100 |   300 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))
       filter(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))

Note that in the above, the error in the OPTIMIZER_FEATURES_ENABLE hint caused the optimizer to apparently not see the USE_HASH hint.

So, what happens when we reverse the order of the hints?:

SQL> SELECT /*+ USE_HASH(T1 T2) OPTIMIZER_FEATURES_ENABLE('10.2') */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1967407726
 
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |  4950 | 29700 |   144   (5)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |  4950 | 29700 |   144   (5)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |    50 |   150 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter("T1"."RN">"T2"."RN")

Note in the above that the optimizer saw the USE_HASH hint (even though a nested loops join was the result).

Now for the final part of the output, a properly specified OPTIMIZER_FEATURES_ENABLE:

SQL> SELECT /*+ OPTIMIZER_FEATURES_ENABLE('10.2.0.4') USE_HASH(T1 T2) */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1967407726
 
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   500 |  3000 |   144   (5)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |   500 |  3000 |   144   (5)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |     5 |    15 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter("T1"."RN">"T2"."RN")

Note that in the above, the optimizer saw the USE_HASH hint (even though a nested loops join was the result).

]]> By: Charles Hooper http://hoopercharles.wordpress.com/2011/09/30/invalid-hints-are-silently-ignored-an-invalid-use_hash-hint-transforms-a-sort-merge-join-into-a-nested-loops-join/#comment-3990 Fri, 30 Sep 2011 15:56:17 +0000 http://hoopercharles.wordpress.com/?p=5492#comment-3990 Just to be complete, reversing the order of the hints, placing the undocumented FAST hint last:

SELECT /*+ USE_HASH(T1 T2) FAST(TRUE) */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;

SQL> SELECT /*+ USE_HASH(T1 T2) FAST(TRUE) */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1967407726
 
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |  4950 | 29700 |   144   (5)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |  4950 | 29700 |   144   (5)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| T2   |    50 |   150 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter("T1"."RN">"T2"."RN")

To the casual observer, the order of the hints potentially matters. However, for those who read the articles at the start of this blog article, it is quite clear why the execution plan reverted back from the sort-merge join (well, almost… why was that 10053 trace enabled?).

]]> By: Charles Hooper http://hoopercharles.wordpress.com/2011/09/30/invalid-hints-are-silently-ignored-an-invalid-use_hash-hint-transforms-a-sort-merge-join-into-a-nested-loops-join/#comment-3989 Fri, 30 Sep 2011 15:46:32 +0000 http://hoopercharles.wordpress.com/?p=5492#comment-3989 Nigel, that is an interesting perspective.

Here is a little more fun (explained in the links at the top of this article). The undocumented FAST hint :-) :

SELECT /*+ FAST=TRUE USE_HASH(T1 T2) */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;

SQL> SELECT /*+ FAST=TRUE USE_HASH(T1 T2) */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 412793182
 
----------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   1 |  MERGE JOIN         |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   2 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  4 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL| T2   |   100 |   300 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))
       filter(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))

Trying again, just to make certain that the syntax of the undocumented hint is correct:

SELECT /*+ FAST(TRUE) USE_HASH(T1 T2) */
  *
FROM
  T1,
  T2
WHERE
  T1.RN>T2.RN;

 
SQL> SELECT /*+ FAST(TRUE) USE_HASH(T1 T2) */
  2    *
  3  FROM
  4    T1,
  5    T2
  6  WHERE
  7    T1.RN>T2.RN;
 
Execution Plan
----------------------------------------------------------
Plan hash value: 412793182
 
----------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   1 |  MERGE JOIN         |      |  4950 | 29700 |     9  (34)| 00:00:01 |
|   2 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| T1   |   100 |   300 |     3   (0)| 00:00:01 |
|*  4 |   SORT JOIN         |      |   100 |   300 |     4  (25)| 00:00:01 |
|   5 |    TABLE ACCESS FULL| T2   |   100 |   300 |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))
       filter(INTERNAL_FUNCTION("T1"."RN")>INTERNAL_FUNCTION("T2"."RN"))
]]> By: Nigel Thomas http://hoopercharles.wordpress.com/2011/09/30/invalid-hints-are-silently-ignored-an-invalid-use_hash-hint-transforms-a-sort-merge-join-into-a-nested-loops-join/#comment-3988 Fri, 30 Sep 2011 15:30:00 +0000 http://hoopercharles.wordpress.com/?p=5492#comment-3988 Arguably, the USE_HASH hint is not invalid – just inapplicable. An invalid hint would be something like /*+ GO_FASTER */. But your test suggests it may be misnamed – perhaps it should have been NO_USE_SORT_MERGE? That’s the trouble with the CBO – what looks like a binary choice in 1990 becomes much more complex by 2011.

]]>