I’m with you now on this one – I don’t think the USE_NL (C2) hint I added will have any effect on the optimizer. Another lesson learned for me about the right ways of using hints, and why it is probably better to just avoid them. I also think the NO_USE_HASH (C2) would be ignored by the optimizer for the same reason – the reference to C2 is not qualified by the inner query block name.

The hints I have mentioned from the outline section in the 10053 trace file were only from the first execution of the query with no hints at all. So anything listed in that outline section was put there by the optimizer itself. I’ve not done a 10053 trace since, so I have no idea what hints were in the outline that resulted from the hinted query. So USE_HASH was produced by the optimizer itself. I think I also said that all of the hints from the optimizer outline section were fully qualified – each had a leading ‘@’ top level query block name argument, followed by table aliases each qualified by the query block name within the query e.g. SC@SEL1, C2@SEL2.

If I wanted a set of “useful” hints then I would now more closely follow Jonathan’s recommendations – use query block names and qualify all table references, and add in as many hints as possible to be totally unambiguous e.g. LEADING, UNNEST and others.

Thanks, John

answering to some of your notes:

1. Of course EXISTS has been transformed to SEMI JOIN. BTW, I think, this the reason why oracle depricated %_SJ and %_AJ hints (you can always achive semi or anti join by using different hints). But the name od default queryblcock name SEL$1 has been transformed and that’s the problem as Jonathan wrote, too
3. You have seen USE_HASH in the final outline, but you don’t know, weather because of your hint, or not. CBO always generates an outline, also in cases, where no hints were used in original query

I have tried my examples also on 10.2.0.5 Solaris 32 bit and I have same results. Let’s run explain plan on following queries and please, paste us here execution plans
generated on your solaris 64bit box.

CREATE TABLE t1 (n1 NUMBER, n2 NUMBER, v1 VARCHAR2(100))
/
CREATE INDEX t1_i ON t1(n1)
/
CREATE TABLE t2 (n1 NUMBER, n2 NUMBER, v2 VARCHAR2(100))
/

select
   /*+ LEADING(t2) USE_NL(t1) */ *
from
    t2
where   t2.n2 = 15
and exists (
        select
            null
        from    t1
        where   t1.n1 = t2.n1
    )
;

select
   /*+ LEADING(t2) USE_HASH(t1) */ *
from
    t2
where   t2.n2 = 15
and exists (
        select
            null
        from    t1
        where   t1.n1 = t2.n1
    )
;

If the first plan will contain NESTED LOOPS SEMI and the second HASH_JOIN_SEMI, you are right. But as you can see my exampeles abov, optimizer didn’t follow hints in one of them (I have tried LINUX 64bit, HP 64 bit and Solaris 32bit, all DB were 10.2.0.5 ). I think it will be the same story at your DB and will be the final contradiction of your theory.

Johnathan also suggested that two of your hints are invalid. And yes, OPTIMIZER IGNORES hints when they are not valid (referencing nonexisting tables, indexes etc.).

“We’ll have to agree to differ on our opinions of use_nl(@subq t1) – since there is no definitive statement in the manuals” – I absolutely agree.

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

One of the other hints in the outline output of the 10053 trace file was an optimizer features hint:

OPTIMIZER_FEATURES_ENABLE('10.2.0.4')

All of this feedback from everyone is just reinforcing my view that hints should be avoided because it is so difficult to know for certain that each hint is individually doing what you want it to. As Pavol has said, it could be one of the other hints that ended up producing the NESTED LOOP join, rather than the USE_NL (C2) itself – either the NO_USE_HASH or the INDEX on SC. And as I said before, the second alternative I came up with after some further analysis of reducing the column density value seems safer from the perspective of it more directly controlling the desired impact on the execution plan produced. “Safe” is a relative term here, as one way or another we are trying to force the Oracle optimizer to pick a different execution plan to the one it naturally believes is “best”.

I have to say that I am a little surprised that your hints did work – which (exact) version of Oracle are you using, by the way, because the “unparse” line in your trace file means it’s not the same as the one I was testing on.

In principle a hint like operation(object) ought to be a short hand for operation(@current_query_block object@current_query_block), so your use_nl(t2) should have been interpreted as use_nl(@sel$1 t2@sel$1) because the location of the hint is in the query block with the default name of sel$1.

I have emphasised the “ought to be” because I don’t know if that claim is true – it’s my working hypothesis, but I haven’t seen anything in the manuals or on Metalink that makes this statement.

If I am correct, two of your hints ought to be invalid because they demand a join method in a query block with only one table, and one ought to be invalid because it references an object that does not exist in that block.

You were correct to ignore the observation someone had made about the hash join being a semi-join, the hints dictate the join method whether the specific case is “normal”, semi or anti.

I wasn’t planning to say anything about getting the best plan for this query – it’s always down to volume, distribution, and available indexes – but there’s always the generality that when the optimizer gives you a hash join when you want a nested loop, it’s probably about the cardinality estimates or the precision of the available indexes, so adjusting some statistics (in a truthful type of way) to tell Oracle that it’s a small volume of data or that there’s a really precise good can be a very good strategy.

In fact, in one of the models I created for this statement, all I had to do was put the correct index hint into the subquery (although I could have done the same by hinting from the main query) to make Oracle use that index. The optimizer decided that the cheapest path using that index was the nested loop semi-join. (If anyone did that – and no more – on a production system, though, I’d point out that they had emporarily got the right plan by accident.)

I also think I may have misunderstood a bit your original reply – its clear from re-reading your replies that you do know about hints and how they work.

I think the USE_NL(C2) should be used by the optimizer for the following reasons:

1. The 10053 trace file showed that the query was being rewritten as a join between the two aliases of the table.

*****************************
Cost-Based Subquery Unnesting
*****************************
SU: No subqueries to consider in query block SEL$2 (#2).
SU: Considering subquery unnesting in query block SEL$1 (#1)
SU: Performing unnesting that does not require costing.
SU: Considering subquery unnest on SEL$1 (#1).
SU:   Checking validity of unnesting subquery SEL$2 (#2)
SU:   Passed validity checks.
SU:   Transforming EXISTS subquery to a join.
Registered qb: SEL$5DA710D3 0x7dc108e0 (SUBQUERY UNNEST SEL$1; SEL$2)
  signature (): qb_name=SEL$5DA710D3 nbfros=2 flg=0
    fro(0): flg=0 objn=xxx hint_alias="SC"@"SEL$1"
    fro(1): flg=0 objn=xxx hint_alias="C2"@"SEL$2"

The last line of comments prefixed “SU” states that it has transformed the EXISTS to a join instead.

Later on in the 10053 file it has:

SQL:******* UNPARSED QUERY IS *******
SELECT ... FROM "SCHEMA"."SSCLASS" "C2", "SCHEMA"."SSCLASS" "SC" 
WHERE ... AND "C2"."SSCID" = "SC"."SSCID" AND "C2"."AUDATE" >= TO_DATE ...

So again I read this as saying that the sub-query had been unnested into a join.

2. The reported bad execution plan has a JOIN in it, though it is a SEMI JOIN
3. The hints reported in the outline in the 10053 trace file referred to “USE_HASH (@SEL$5DA710D3 C2@SEL$2)”, from which I infer that a USE_HASH hint was controlling the join between the two data sets, so a join was occurring
4. All of the references to the 2 table aliases in the hints in the outline are prefixed by @SEL$5DA710D3 as the first argument. These include hints of OUTLINE_LEAF, INDEX, LEADING, USE_HASH and SWAP_JOIN_INPUTS. So all references were within the same single top level query block.

This lead me to believe that I did not need to qualify the C2 reference in the USE_NL hint by a query block name. I’m not saying that “I know the USE_NL hint is correct”, but instead that “I believe it would work”. Generally I do avoid hints because of the dangers of them not quite working the way you want them to, for one reason or another. In this case I am saying that this was the set of evidence I considered when deciding that a hint of “USE_NL (C2)” and others would be right and would be applied by the optimizer. But I have no direct evidence that that specific hint was recognised and applied by the optimizer, only that the execution plan used was that desired after the 4 hints were added to the SQL.

I do concede that the reference to C2 in the optimizer produced USE_HASH has @SEL$2 after it, which I take to be the nested sub-query, because the SC references are qualified by @SEL$1. I don’t know how this affects the meaning of the reference to C2 in either the USE_HASH or USE_NL hints.