http://docs.oracle.com/cd/E11882_01/server.112/e26088/img/index_hint.gif

Kerry

Hint syntax is descrribed in the SQL reference manual. For example, the syntax for specifying an index hint is here:

http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements006.htm#BABEFDFC

As you can see, the query block specification is optional but the table specification is not. I have been unable to get your syntax to work on 10g or 11g. Are you sure that the use of the index in your example isn’t purely coincidental?

Thanks for the comment. Hint syntax is a bit confusing (and not really documented anywhere that I’m aware of – at least with a formal syntax diagram of list of arguments). Jonathan and I were using the less formal hint syntax which leaves out the 1st and 2nd arguments (Query_Block and Alias). This is commonly done when adding hints directly to SQL statements. So the common version of the new INDEX hint syntax would look like this:

/*+ INDEX(TABLE_NAME.COLUMN_NAME TABLE_NAME.COLUMN_NAME) */

If in fact you use this format it works fine but it will be applied within the scope of the current QB. Here’s an example:

SYS@dbm1> select /*+ index(skew.col1 skew.col2) */ count(col1) from kso.skew t  where col1 = 1 and col2 = 'asddsadasd';

 COUNT(COL1)
------------
     3199977

1 row selected.

Elapsed: 00:00:07.08
SYS@dbm1> @x

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  3v5nxcb4nnwga, child number 0
-------------------------------------
select /*+ index(skew.col1 skew.col2) */ count(col1) from kso.skew t
where col1 = 1 and col2 = 'asddsadasd'

Plan hash value: 4272108972

-----------------------------------------------------
| Id  | Operation         | Name           | E-Rows |
-----------------------------------------------------
|   0 | SELECT STATEMENT  |                |        |
|   1 |  SORT AGGREGATE   |                |      1 |
|*  2 |   INDEX RANGE SCAN| SKEW_COL1_COL2 |      1 |
-----------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("COL1"=1 AND "COL2"='asddsadasd')

Note
-----
   - Warning: basic plan statistics not available. These are only collected when:
       * hint 'gather_plan_statistics' is used for the statement or
       * parameter 'statistics_level' is set to 'ALL', at session or system level

26 rows selected.

Elapsed: 00:00:00.02
SYS@dbm1> @sql_hints
Enter value for sql_id: 3v5nxcb4nnwga
Enter value for child_no: 0

OUTLINE_HINTS
-----------------------------------------------------------------------------------------------------------------------------------------------------------
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('_optimizer_use_feedback' 'false')
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX(@"SEL$1" "T"@"SEL$1" ("SKEW"."COL1" "SKEW"."COL2"))

7 rows selected.

Elapsed: 00:00:01.05

So as you can see, the fully specified hint ends up looking like INDEX(QB_NAME ALIAS (TABLE_NAME.COLUMN_NAME TABLE_NAME.COLUMN_NAME)) Your syntax also works as long as the hint is defined in the Query Block where you want it applied and there is not an alias specified for the table. The full syntax is needed for many hints to work when using SQL Profiles by the way. Thanks again for pointing out this out as it is confusing and needed to be spelled out a little more clearly.

Kerry

I know this is an old blog but it is still of interest. There is a typo in your description of the new index format that Jonathan has repeated in his reply. Please feel free to correct it (I suggest both places..I doubt JL will object) and delete this comment.

The new format is not:

INDEX(TABLE_NAME.COLUMN_NAME TABLE.NAME.COLUMN_NAME …)

but

INDEX(TABLE_NAME (TABLE_NAME.COLUMN_NAME TABLE.NAME.COLUMN_NAME …))

Note the TABLE_NAME at the start and the extra brackets around the columns specifications.

Thanks for the comments.

I totally agree that your paraphrase of what the index hint is saying is more accurate than mine. (too bad they don’t document hints better, and that they don’t have the option to raise a warning when they are ignored).

I also agree that the INDEX_RS(_ASC/DSC) hints are more specific and therefore a better choice when trying to force a specific plan. Unfortunately, there are some problems (i.e. bug) that cause Oracle to create an invalid hint. In the particular case I showed (2nd batch of code), the other_xml field contains the hint

INDEX_RS_ASC(@”SEL$1″ “A”@”SEL$1″ (“SKEW”.”COL2″ “SKEW”.”COL1″))

– even though the actual plan does an

INDEX FULL SCAN

Therefore, creating an Outline on this statement changes the plan. In this case, changing the hint to the more generic INDEX(xxx), allows the optimizer to use an INDEX FULL SCAN. By the way, 11.2 works around this bug by doing exactly that, changing the INDEX_RS_ASC to INDEX. So I am agreeing with you on this point as well, more specific is certainly better (unless of course it doesn’t work, like in this corner case).

I’m not much of a fan of the new index format though. I understand your point about changing indexes and in general it makes sense. With respect to Outlines/Profiles/Baselines though it seems too flexible at times. By that I mean that occasionally an Outline or Profile will not keep a plan from changing – and sometimes it’s due to this non-specific Index Hint format. I think one of the reasons is that the Outline Hint created by Oracle (again pulled from the other_xml field) specifies every column contained in the index. That is to say that if a plan uses an index that contains 10 columns, all ten will be listed in the hint, regardless of the fact that only a couple of them may actually be used in the statement. You can see this in the example in the post as well. The SKEW_COL2_COL1 index has COL2 and COL1. So the hints specifies both columns, even though the SQL only references COL1. I guess it just seems more straight forward and less error prone to actually specify the index name (although I acknowledge that it may go bad at some point in the future if someone changes the indexes).

Thanks again for your comments.

Note: I’ll have to do a little verification (and refreshing my memory) before I respond to your comments on
Why Isn’t Oracle Using My Outline / Profile / Baseline.

Kerry

Regarding this comment:

INDEX(TABLE_NAME (TABLE_NAME.COLUMN_NAME TABLE.NAME.COLUMN_NAME …))
Translation: If possible, use any available index on any of these columns.

I think the translation should be more like:

“Use the index on this set of columns in this order but if the required index doesn’t exist then use the cheapest index that starts with this set of columns in this order.”

Personally I think it’s a better way of hinting an index than the old “index(alias index_name)” method given that (a) people sometimes rename indexes to conform to naming conventions and (b) people sometimes drop one index because it starts the same way as another. In both cases, the new mechanism is likely to reduce the risk of damage.

The “index_rs(_asc/_desc)” hints were introduced, by the way, because an index() hint could allow the optimizer to choose between a range scan and a full scan – and that meant that a hinted query could still change its execution path dramatically unless all the other hints had been carefully set up to avoid the error – so I wouldn’t be too keen to change a index range scan hint to a simple index hint.

Regards
Jonathan Lewis