Thanks,
Anu

Bill

http://kerryosborne.oracle-guy.com/2010/07/sqlt-coe_xfr_sql_profilesql/

By the way, I’d be interested to know what access path the INDEX hint allowed that the INDEX_RS_ASC didn’t.

Kerry

BEGIN_OUTLINE_DATA
INDEX_RS_ASC(@SEL$1 NAMES@SEL$1 UPPER_NAME_INDEX)
OUTLINE_LEAF(@SEL$1)
ALL_ROWS
OPT_PARAM(‘optimizer_index_caching’ 40)
OPT_PARAM(‘optimizer_index_cost_adj’ 40)
DB_VERSION(’11.1.0.7′)
OPTIMIZER_FEATURES_ENABLE(’11.1.0.7′)
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA

Also – I used fix_sql_profile_hint.sql to change it to INDEX(@SEL$1 NAMES@SEL$1 UPPER_NAME_INDEX), and now I get the promised 90% improvement! However, it feels like I’m cheating (read “Oracle doesn’t support/recommend this”).
I’m hoping maybe I’m missing a setting or something that would cause the hint to be INDEX instead of INDEX_RS_ASC.

When trying to understand why a hint based mechanism is not doing what you expect, it’s best to look directly at the hints. You say you implemented a SQL profile suggested by the Tuning Advisor. Generally those hints look like OPT_ESTIMATE or statistics modification type hints. Have you run the sql_profile_hints.sql script to see exactly what’s being applied? If so can you paste the output here?

Kerry

I have a query that is doing a full table scan. I ran the tuning optimizer task, and it recommended an SQL profile which I accepted, that promised 90%+ improvement. When comparing the plans, it proposed using an index. Good, so far!

Well, as in your case, when running the query, it still did the full table scan even though it said it used the profile.

The index hint for the profile used INDEX_RS_ASC. I believe that is the culprit.

When I run my query specifically with the /*+ INDEX (table_name my_index) */ hint, then the index is used.

If I run it with /*+ INDEX_RS_ASC (table_name my_index) */ then a full table scan is done.

Is there a way, without using your scripts to change the profile hint, for me to get Oracle to do use the INDEX hint rather than an INDEX_RS_ASC hint?

Thanks,

Bill

SQL Profiles can apply to multiple SQL statements via the FORCE_MATCHING parameter, but there is no finer grained way of applying them than to a single SQL_ID. So no, there is no syntax for applying them to individual children. That would not help you anyway because as soon as you create a SQL Profile, the existing cursors will be invalidated and a new cursor will be created at the next execution. As to why you got the plan you wanted on one child and not others, I am not sure how you created your SQL Profile, maybe with my create_1_hint_sql_profile.sql script? At any rate, the syntax you are using “index (Table_Alias Index_Name)” would need to be modified to include a query block in order for it to work inside a SQL profile like this:

index(Table_Alias@Query_Block Index_Name)

The default query block name is SEL$1 for a simple query (you can see them by doing an XPLAN with ‘alias’)

select * from table(dbms_xplan.display_cursor(‘&sql_id’,'&child_no’,'alias’));

So the plan changing is probably a function of the optimizer just coming up with a different plan (maybe due to bind variable peeking).

Kerry

I have been using SQL hints on sql profiles with good degree of success. Recently, i am facing an issue where after applying the SQL hint (/*+INDEX(Table_ALias Index_Name)*/)to an SQL profile, the plan changes for certain child numbers only. For example, a sql_id had child numbers 0, 2, 4, 6 and dbms_xplan indicated that the child 2 has the hinted plan (good) whereas the others don’t. This is on Oracle 11.1.0.7.

I there a way to apply a sql profile to different child numbers of the same sql_id? Would appreciate if u can explore further?

Regards,
Naren