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 of all three seems much better than trying to come up with a set of hints that will only allow the optimizer to choose one plan. The later seems like an approach that is doomed to failure. 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 may 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 an production 11g system for a while now where we are using them.

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

First off, thanks for you comment. Outlines (and profiles too for that matter) are definitely not foolproof. They don’t actually store the plan, just a set of hints that they hope will force the optimizer to choose a certain plan. Seems like it would have been easier just to save the plan itself, rather than to try to come up with a set of hints. But that’s a whole other discussion.

A common technique with outlines is to try to coerce a statement to use the plan you want (obviously without changing it’s text). This can be done in many ways, changing optimizer parameters at session level, changing stats, creating views with embedded hints, etc… Creating a profile is just another way to coerce a plan you want. I must admit that I have not used this trick extensively (only on one production system). But the technic appears valid. By that I mean, that you can create an outline on a statement that has a profile already created on it. And that the optimizer appears to then use the outline. It probably would be wise to disable the profile if you do this by the way. My main point was that outlines (while certainly not perfect) are much more likely to remain constant than profiles, because profiles tend to adjust optimizer calculations by applying scaling factors. So they tend to “sour” - that is, as the statistics change, the scaling factors no longer have the desired affect.

I will say that I have seen outlines that were much less specific than I would have expected. For example, the index hints in 10.2 commonly use the form that specifies the columns instead of the actual index name, like so:

INDEX(@”SEL$1″ “SKEW”@”SEL$1″ (”SKEW”.”PK_COL”))

This hint just says use an index on the skew.pk_col column if one exists. It doesn’t specify which index to use. So even with outlines, Oracle sometimes leaves itself some wiggly room. And the more complicated the statement, the more chance there is that this type of issue might crop up.

One final thought, I really like outlines because they allow us to manipulate the system (trick it if you will) when we can’t touch the code. I also like them because they are relatively quick to turn on and off. But, and this is a big but, they should really be considered just a temporary fix until you can get the optimizer doing what it should by having the correct statistics, using literals where necessary, etc…

There are certainly cases where outlines go wrong. I’d be interested in seeing an example of one where you had a profile and created an outline that changed the plan.

Kerry

Roberto