How to add a hint to ORACLE query without touching its text
If you’ve been a DBA long enough, you’ve probably seen multiple cases where certain SQL queries just refuse to cooperate.
I.e. you KNOW that the query is supposed to use index IDX1, but ORACLE stubbornly decides to take IDX2. Rats!
The usual suspect here is bad statistics and thus the usual advise is: start re-collecting them. But while this might help, the success is far from guaranteed! Moreover, with a ‘real production’ data statistics collection could take hours (days?) and you already have people screaming about slow performance … In other words, you need to fix the problem NOW and waiting until stats collection maybe fixes the problem a few hours down the road is just not an option!
The troubling global nature of SQL Profiles and SPM Baselines
Did you know that SQL profiles and SPM baselines collected for SQL statements in one schema can apply to “the same” SQL statements in another schema ?
They do ! And, besides, objects that these SQLs apply to do NOT need to be exactly the same … And I’m not just talking about different data values or different number of records … The objects can have different structure! Or, they can actually be of different type, i.e. views instead of tables …
The only things that matter are: SQL text and object names.
This strange behavior is summarized in the table below:
| BEHAVIOR | SQL Profile | SPM Baseline |
|---|---|---|
| “Fire” for object in a different schema | YES | YES |
| “Fire” for object with a different DATA | YES | YES |
| “Fire” for object with a different STRUCTURE | YES | YES |
| “Fire” when indexes are different | YES | MAYBE, will “fire” if the same execution plan is still produced |
| “Fire” when indexes are missing | YES | NO |
| “Fire” when TABLE is replaced by VIEW | YES | NO |
| “Fire” when TABLE is replaced by MVIEW | YES | NO |
And, if you do not believe me, read on …
What is the difference between SQL Profile and SPM Baseline ?
-----
- SQL profile "SYS_SQLPROF_012ad8267d9c0000" used FOR this statement
and SPM Baselines
-----
- SQL plan baseline "SQL_PLAN_01yu884fpund494ecae5c" used FOR this statement
are both relatively new features of ORACLE Optimizer with Profiles first appearing in version 10 and SPM Baselines in version 11.
Both SQL Profiles and SPM Baselines are designed to deal with the same problem: Optimizer may sometimes produce a very inefficient execution plan, and they are both doing it by essentially abandoning the idea that “all SQLs are created equal”. Instead, another idea is put forward: “Some SQLs are special and deserve individual treatment”.
What are SQL Profiles and why do we need them ?
If you use DBMS_XPLAN package to analyze execution plans for your SQL statements (and you really should these days), you might have noticed that at times the following line might be displayed along with your execution plan:
-----
- SQL profile "SYS_SQLPROF_012ad8267d9c0000" used FOR this statement
This seems to mean that:
- An external ‘helper’ object was used during evaluation of your SQL statement
- This ‘helper’ object changed (or, at least, influenced) its execution plan
While having some extra help is nice, one has to wonder: what exactly is this “profile” object ? What does it do ? And, in a bigger picture, why do we need “external” help evaluating SQL statements at all ?