So yes, something must have happened to the sql somewhere along the line.

I understand your point of not moving profiles between environments, but this is a VLDB and I’m not permitted to modify the sql so I was considering this as an alternative for plan stability when needed.

Thanks for all the help

By the way, I generally don’t move Profiles from one environment to another. It seems more productive to me to work directly in the production environment on a test copy of the problem SQL (one with a comment in it for example). There’s no guarantee that the hints that produce the desired plan in TEST will produce the same plan in PROD even if you get it to use the Profile. That’s because there are so many possible differences in the inputs into the optimizer (stats, parameters, memory sizing, etc…) If you do want to move an existing Profile you can also use the DBMS_SQLTUNE.PACK_STGTAB_SQLPROF and DBMS_SQLTUNE.UNPACK_STGTAB_SQLPROF procedures. We’ve used these for migrating a set of Profiles to a new platform, but I’ve not written about it on the blog as it’s a relatively uncommon thing for me.

Hope that gives you some ideas.

Kerry

SYSTEM-c4prd1-H3PRD-> select EXACT_MATCHING_SIGNATURE from v$sql
2 where sql_id = ‘d9a4x6bvkkfhr’;

EXACT_MATCHING_SIGNATURE
————————
2.9681E+18

SYSTEM-c4tst1-H3PRD-> select EXACT_MATCHING_SIGNATURE from v$sql where sql_id = ‘d9a4x6bvkkfhr’;

EXACT_MATCHING_SIGNATURE
————————
2.9681E+18

SYSTEM-c4tst1-H3PRD-> select name, category, signature, created, last_modified, type, status, force_matching from dba_sql_profiles

NAME CATEGORY SIGNATURE CREATED LAST_MODIFIED TYPE STATUS
—————————— —————————— ———- ——————- ——————- ——— ——–
coe_d9a4x6bvkkfhr_1957636171 DEFAULT 1.5067E+19 09-01-2012 15:56:28 09-01-2012 16:17:58 MANUAL ENABLED

I’m not sure. There is a signature that’s calculated in order to match a statement to a SQL Profile. Check and see if those are the same. You didn’t say how you were generating the Profile but the text has to match pretty much exactly (except for literals if you use FORCE_MATCHING).

Kerry

Many issues.., primary one being the length of the hint (ORA-06502).., but found solutions between your blog and Randolf’s (thanks both).

So I was finally able to extract the hints from the PROD system and create the profile on the TEST system, but it is not using it. Same sqlid, sqltext, but xplans are still different and TEST does not show the profile being used. What am I missing?

The method documented here should work. Steps are:

1. Log into 10g DB
2. Find sql_id and hplan_hash_value for the statement
3. run coe_xfr_sql_profile.sql (it will generate a file containing the sql_id and plan_hash_value in the name)
4. Copy the generated script to the machine running 11g
5. Log in to 11g DB and verify that the statement is there
6. Run the generated script
7. Check to make sure the SQL Profile generates the expected plan

By the way, I should mention that I consider using SQL Profiles in this manner as a band aid, best used for emergency situations to give you time to figure out why you’re not getting the plan you expect.

Do we have a method to pull a plan from 10.2 and bring over to 11.1? There is a query taking a bad plan. Statistics on the tables involved in the query look to be the same (were imported ok). I’d like to bring the plan over but don’t know the steps.

Kerry