The script is prompting for a child number as opposed to a plan hash value. The child_number should be 2 in your example.

Kerry

Enter value for sql_id: a0j23muc76nuz
Enter value for plan_hash_value: 2627696582
Enter value for category:
Enter value for force_matching:
old 18: sql_id = ‘&&1′
new 18: sql_id = ‘a0j23muc76nuz’
old 19: and child_number = &&2
new 19: and child_number = 2627696582
old 31: sql_id = ‘&&1′
new 31: sql_id = ‘a0j23muc76nuz’
old 32: and child_number = &&2;
new 32: and child_number = 2627696582;
old 37: , category => ‘&&3′
new 37: , category => ‘DEFAULT’
old 38: , name => ‘PROFILE_&&1′
new 38: , name => ‘PROFILE_a0j23muc76nuz’
old 43: , force_match => &&4
new 43: , force_match => false
declare
*
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 24

Two hash values exists for a SQL_id.
# Plan Hash Value Total Elapsed Time(ms) Executions 1st Capture Snap ID Last Capture Snap ID
1 3347154448 68,154,693 31,359 981 1060
2 2627696582 31,026,788 185 1061 1101

If a Profile exists for a given statement it should be used regardless of which user is executing the statement. There are a couple of things you can check to make sure it should be used. Look at the signature columns in v$sql and dba_sql_profiles. They should match. Also, if the statement is using the Profile, the sql_profile column in v$sql will have the name of the profile in it. If the signatures match but it’s not being picked up, that’s probably a bug. I have seen this happen with force_matching=true. So you might try without setting that option. By the way, there are many posts on this site with information on how Profiles work “under the covers”. Good luck.

Kerry

I created SQl profile through EM via advisory central using system .
Now if the same query gets executed via other user profile does not get used. How do i transfer that profile for all the users?

Kerry

Wanted to drop a line to say thanks for the create_sql_profile_awr.sql script. I found a situation today that allowed me to solve a production issue using it. I have a script that shows sql execution stats over time from awr. Note that on the 25th of Jan at 10am there was a plan change and buffer gets shot through the roof, at 16:00 we ran your sql script picking a previous hash plan value and the timings returned to normal.

TIMESTAMP       #PLANS                     #EXEC        ROWS_PROC    DISKREADS        GETS/EXEC        IOWAIT   SECS/EXEC    TOTSECS
--------------- --------------- ---------------- ---------------- ------------ ---------------- ------------- ----------- ----------
24-JAN-10 19:00 1                             12            4,111    1,236,962          141,876      28967057      109.34       1312
24-JAN-10 20:00 1                             39           17,606    3,896,737          137,358      18416723      138.30       5394
24-JAN-10 21:00 1                              5                0      388,688           81,958       1040703       68.50        342
24-JAN-10 22:00 1                              8               17      675,832          116,810      16315202       81.39        651
25-JAN-10 00:00 1                             24           12,503    2,419,987          144,586      20789949      104.10       2498
25-JAN-10 04:00 1                              8                1      661,590          105,532       4596278       87.86        703
25-JAN-10 05:00 1                             26            1,234    2,536,143          124,302      12789703      109.04       2835
25-JAN-10 06:00 1                             24           38,856    2,655,137          239,436      28886629      126.63       3039
25-JAN-10 07:00 1                              5               23      442,966          238,767       6298353       75.51        378
25-JAN-10 08:00 1                              2              340      357,109          139,357      51294885      104.54        209
25-JAN-10 10:00 1 (plan change)               27              446      130,702       81,869,479      79355932      356.71       9631
25-JAN-10 11:00 1                              7            1,268    1,765,948      570,996,611    2281600856    3,380.09      23661
25-JAN-10 12:00 1                              7              934    1,506,704      500,435,949    1813018245    6,662.60      46638
25-JAN-10 13:00 1                              3            1,493       65,852    1,283,852,131      99695415   16,010.25      48031
25-JAN-10 14:00 1                              1            1,247       34,879    4,227,746,967      19951869   48,673.53      48674
25-JAN-10 15:00 1                              5            2,020       63,546      800,010,218     100884565    9,538.32      47692
25-JAN-10 16:00 1 (plan change)                1                1      247,574          141,598      44470601      127.12        127

Thanks for your reply.

I’ve solved plan instability by manually correcting statistics (DBMS_STATS.SET_TABLE_STATS) that caused the execution plan to change.

Regards
Fredy

Sorry, I completely missed your point on the first post - skipped over the multi-table insert part. Yes, that restriction appears to have been carried over to SQL Profiles. I expect they took the Outline code as a baseline and modified it to come up with SQL Profiles and Baselines in 11g. It doesn’t appear that SQL Profiles or Baselines will work for multi-table inserts. If you look in the other_xml column of v$sql you won’t see any hints (which is normally what’s used when you create an Outline or Baseline).

Note, you can use this script to see the hints that Oracle will use to create an Outline:

http://kerryosborne.oracle-guy.com/scripts/sql_hints.sql

I did a quick test to see if a one line SQL Profile could be created and applied that didn’t depend on the Outline Hints and even that did not work. It created the Profile, but did not apply it to the statement. So I believe you are correct in that you can’t apply a SQL Profile to a multi-table insert.

Kerry

When I execute DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE, I get signature value of 15926012898303819840,
and when I query dba_sql_profiles table, I get in signature field value of 1,59260128983038E19.
That means that it should work, but accepted SQL Profile is still not used
(I can see it from SELECT * FROM table(dbms_xplan.display(NULL,NULL,’basic +note’)); after I do
explain plan for my SQL statement).

I’ve also tried to store my SQL in CLOB in table, and pull the stored SQL text back as imput in
DBMS_SQLTUNE.CREATE_TUNING_TASK procedure, but still with no success.

I’ve tried to create and accept SQL Profile for my SQL statement from AWR, but without success too.

My conclusion is that it must be some restriction in Oracle SQL Profile functionality that prevents
Oracle engine to use my complex DML SQL statement (multi-table insert which includes db_links)
which is generated by Oracle Warehouse builder.

I know that there are a lot of restrictions in Stored Outlines (multi table insert, remote tables…). Maybe is the same with SQL Profiles.

For less compex statements, SQL Profile works fine.

Regards,

Fredy

There are not any restrictions that I’m aware of. But it’s possible. When you say that you can’t persuade Oracle to use it, if you mean that you create a SQL Profile on a statement, but when it is executed the next time, the Profile is not used at all, then this should only happen if the text doesn’t really match. If you mean, it’s used but you don’t get the plan you expect, there are all kinds of things that can cause that to happen, especially on complex statements. If you send a few more details I’ll be happy to try to help.

Kerry