I do agree with you that SQL Profiles have the advantage of being able to force matching of statements using literals. Outlines, SQL Profiles, and now Baselines all can provide similar functionality, each with their own little twist. I have primarily used SQL Profiles in conjunction with the SQL Tuning Advisor where by SQL Profiles are created based on it’s analysis. These SQL Profiles often make use of the OPT_ESTIMATE hint to scale an estimate for a particular step one direction or the other. These are the hints that make SQL Profiles less attractive to my way of thinking, because these scaling factors stay fixed although the statistics and data in the object can and do change. So a scaling factor that made sense last month may not make any sense this month. That’s why I said that they tend to sour over time. Again, I believe this is specific to using the SQL Tuning Advisor and the SQL Profiles that it generates, so I should probably re-word my post to be a little more clear on that issue.

I must say, that trying to come up with a set of hints that will only allow the optimizer to choose one plan seems like an approach that is doomed to failure (at least some of the time). That said, the approach has worked pretty well for quite a while, at least on relatively simple queries where the optimizer doesn’t have that many choices to begin with. And it is really the only option prior to 11g. I am working on a post on Baselines now, as I have been able to work with a production 11g system for a while now where we are using them. It will be interesting to see how the hint based mechanism has matured with 11g.

Thanks for your comments and the heads up on your post.

Kerry

I’ve recently published a blog post where I compare Stored Outlines and SQL Profiles in 10g when attempting to lock down execution plans having the “good” one already in the shared pool (or e.g. AWR, see blog). The method described in my blog post using SQL Profiles offers some additional functionality/flexibility you don’t have with Stored Outlines, so it might be worth a try.

In passing I’ve noticed an odd behaviour of the DBMS_OUTLN.CREATE_OUTLINE procedure in my 10.2.0.4 test runs (apart from the bug in the previous releases) since it didn’t pick up the hints stored along with the plan in the shared pool, but obviously created an outline using the present statistics, which might be irritating.

For more details, see the blog post.

Regards,
Randolf

Oracle related stuff blog:
http://oracle-randolf.blogspot.com/

SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Sorry for the delay in replying (I’ve been a bit swamped lately). It’s true that outlines don’t always work. The idea is for Oracle to come up with a set of hints that keep the optimizer from doing anything except the current plan. Unfortunately, occasionally there is still room for the optimizer to pick more than one plan. A good example is the new form of the index hint that specifies the table and the column that you want to use an index on (as I mentioned in my previous comment). This hint does not force the use of a single index, it will allow the optimizer to pick any index that contains that combination. So if you have the same column in more than one index, you can get a different plan. Or if you add a new index, the outline might actually pick it up. This is more likely in later releases and obviously in more complicated SQL statements. So as always, testing is important to make sure it’s doing what you want. I do continue to believe that outlines are more stable than SQL profiles. Of course the best way to deal with the issue is to give the optimizer the info it needs using literals where histograms are needed, so we’re really talking about situations where we can’t directly affect the code.

On a side note, I have created a few outlines in an 11g production environment now, and for simple statements they seem to behave themselves. I am currently experimenting with baselines, as I believe that is a much better approach (actually capturing and saving the execution plan). I hope to write something up on that shortly.

Kerry

select plan_hash_value, sql_id, hash_value, child_number, OUTLINE_CATEGORY, SQL_PROFILE
from v$sql
where sql_id = ’2g985t2xpm0gf’;

PLAN_HASH_VALUE SQL_ID HASH_VALUE CHILD_NUMBER OUTLINE_CATEGORY SQL_PROFILE
—————- ————— ———– ————- —————- ———–
2269489710 2g985t2xpm0gf 3143205358 0

begin
dbms_sqltune.alter_sql_profile(
name => ‘to_fix_with_outline’,
attribute_name => ‘status’,
value => ‘enabled’
);
end;
/

select plan_hash_value, sql_id, hash_value, child_number, OUTLINE_CATEGORY, SQL_PROFILE
from v$sql
where sql_id = ’2g985t2xpm0gf’;

PLAN_HASH_VALUE SQL_ID HASH_VALUE CHILD_NUMBER OUTLINE_CATEGORY SQL_PROFILE
—————- ————— ———– ————- —————- ——————–
482806775 2g985t2xpm0gf 3143205358 0 to_fix_with_outline

alter session set use_stored_outlines = true;

select plan_hash_value, sql_id, hash_value, child_number, OUTLINE_CATEGORY, SQL_PROFILE
from v$sql
where sql_id = ’2g985t2xpm0gf’;

PLAN_HASH_VALUE SQL_ID HASH_VALUE CHILD_NUMBER OUTLINE_CATEGORY SQL_PROFILE
—————- ————— ———– ————- —————- ——————–
482806775 2g985t2xpm0gf 3143205358 0 to_fix_with_outline
2269489710 2g985t2xpm0gf 3143205358 1 DEFAULT

Since I verified some times the method don’t work, I believed it was a wrong method generally.
But I tried with a artificial case test and it works actually, hence is a possible method.
Can you suggest me any clue because the plan changes?

Best regards,
Roberto