Professional Documents
Culture Documents
Customers should not interpret or use information in these case studies as solutions
or recommendations without first contacting Oracle Support.
Each Case Study contains a skill level rating. The rating provides an indication of what
skill level the reader should have as it relates to the information in the case study.
Ratings are:
This case study is discussed that how we can stabilize a query plan using outlines. It
might happen that, for a SQL statement due to some reason optimizer is opting for a
wrong plan instead of the optimize plan. Hints can be used to guide optimizer optimizer,
but in some cases it is not possible to edit application SQL to add index hint. In this case
stored outline can be used to select a desired plan. But text of the SQL should be same
while using stored outline which will not be case after adding index hint.
Case History
This case study is based on a real issue running on an oracle 9.2.0.5 database. This is
about how plan change after gathering the statistics and how can be stabilize them using
outline. Concurrent " EOTH daily " a customized one was running proper earlier taking
around 2-3 hours . But user started to complain that it's not getting completed even in
whole day. Moreover, COLD backup was scheduled on daily basis. So Concurrent gets
restarted after the COLD backup. After analyzing we found the plan of the query has
been changed because of monthly scheduled stats gather activity. As this Concurrent was
very critical thus we’re not allowed to change any logic in the program source code. So
we decided to create the outline for the same.
We ask the user to unable the trace for the problematic concurrent program. In Oracle
APPS environment trace can be enable through the front end using.
Here search for the program name and then click on the Enable Trace ( there at the left –
bottom )
But it won’t work for as the program was not getting completed within the 1 day time and
thus it was not possible to us to find the problematic query using trace. So we decided to
monitor at runtime and thus we used the query mentioned below to find the sid of the
concurrent program with the help of its request id.
Page 2
select s.sid from v$session S ,fnd_concurrent_requests R where
r.oracle_session_id=S.audsid and r.request_id=&request_id
So with the help of above mentioned query we find the sid for the respective concurrent
program.
We got the sid as 135 and thus we used the v$sqlarea & v$session to find the
problematic sql . We found that one query with hash_value 2925922762 was
running for a very long time and didn’t complete
Detail
Page 3
STATSPACK SQL report for Hash Value: 2925922762 Module: EOTHDAILY
SQL Statistics
~~~~~~~~~~~~~~
-> CPU and Elapsed Time are in seconds (s) for Statement Total and in
milliseconds (ms) for Per Execute
% Snap
Statement Total Per Execute Total
--------------- --------------- ------
Buffer Gets: 29,099,706 29,099,706.0 .05
Disk Reads: 1,548,458 1,548,458.0 .20
Rows processed: 4,481 4,481.0
CPU Time(s/ms): 460 459,520.0
Elapsed Time(s/ms): 19,992 19,991,502.4
Sorts: 1 1.0
Parse Calls: 1 1.0
Invalidations: 0
Version count: 1
Sharable Mem(K): 55
Executions: 1
SQL Text
~~~~~~~~
SELECT DISTINCT X.INVENTORY_ITEM_ID FROM EINV_ONHAND_TXN_HISTORY
_DAILY X,EINV_PRICE_LIST_GT Y WHERE X.INVENTORY_ITEM_ID = Y.INVE
NTORY_ITEM_ID AND X.CREATION_DAY =NVL(:B1,TRUNC(SYSDATE)-1)
Plan
Hash Value Snap Id Cost Optimizer
------------ -------- ---------- --------------------
4209813261 8152 20 CHOOSE
1573558166 9713 19 CHOOSE
501312428 11598 20 CHOOSE
3745587098 11706 22 CHOOSE
--------------------------------------------------------------------------------
| Operation | PHV/Object Name | Rows | Bytes| Cost |
--------------------------------------------------------------------------------
|SELECT STATEMENT |----- 3745587098 ----| | | 22 |
|SORT UNIQUE | | 1 | 27 | 22 |
| CONCATENATION | | | | |
| FILTER | | | | |
| TABLE ACCESS BY INDEX ROWID |EINV_ONHAND_TXN_HIST | 1 | 14 | 2 |
| NESTED LOOPS | | 1 | 27 | 3 |
| INDEX FULL SCAN |EINV_PRICE_LIST_GT_N | 1 | 13 | |
| INDEX RANGE SCAN |EINV_ONHAND_ITEM_ID_ | 1K| | 2 |
| FILTER | | | | |
| TABLE ACCESS BY INDEX ROWID |EINV_ONHAND_TXN_HIST | 1 | 14 | 2 |
| NESTED LOOPS | | 1 | 27 | 3 |
| INDEX FULL SCAN |EINV_PRICE_LIST_GT_N | 1 | 13 | |
| INDEX RANGE SCAN |EINV_ONHAND_ITEM_ID_ | 1K| | 2 |
--------------------------------------------------------------------------------
Page 4
From the sprep.sql we found the the plan was continuously changing and it’s not good.
So we ask the user to run the same program on test environment with enable trace and on
test it got completed within 2 hours . From there we got the optimize plan for the
problematic query .
Explained.
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------
-----------------
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 48 |
| 1 | SORT UNIQUE | | 1 | 27 | 48 |
| 2 | NESTED LOOPS | | 1 | 27 | 32 |
| 3 | TABLE ACCESS BY INDEX ROWID| EINV_ONHAND_TXN_HISTORY_DAILY | 1362 | 19068 | 32 |
|* 4 | INDEX RANGE SCAN | EINV_ONHAND_TXN_HIST_DAILY_UK | 1362 | | 7 |
|* 5 | INDEX RANGE SCAN | EINV_PRICE_LIST_GT_N1 | 1 | 13 | |
------------------------------------------------------------------------------------------------
Explained.
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------
---------------
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 27 | 19 |
| 1 | SORT UNIQUE | | 1 | 27 | 19 |
|* 2 | TABLE ACCESS BY INDEX ROWID| EINV_ONHAND_TXN_HISTORY_DAILY | 1 | 14 | 2 |
| 3 | NESTED LOOPS | | 1 | 27 | 3 |
| 4 | INDEX FULL SCAN | EINV_PRICE_LIST_GT_N1 | 1 | 13 | |
|* 5 | INDEX RANGE SCAN | EINV_ONHAND_ITEM_ID_IDX | 1153 | | 2 |
-----------------------------------------------------------------------------------------------
Page 5
Analysis
After analyzing the test and production environment. We noticed that we have gathered
the stats for the respective tables. Since only one program was showing the unwanted
behavior. Thus it’s not possible for us to revert the stats of the respective tables as it might
cause problem for other programs also. As CBO calculation are based on the tables stats.
To know more about CBO and its limitation refer to the metalink doc: 212809.1 . So we
decided to create the outline for the same.
Create outline <Ouitline Name > for the category <Categorn Name> on <Query >;
i.e.,
Now take the export of the outline. Outline regarding information’s are contained in the
tables ol$ , ol$hints . To know more about how to transfer the outline from one database
to another refer to doc 728647.1
exp parfile=outln_eoth.par
Now , transfer the dump outl_eoth.dmp from Test to Production and import into the
production environment .
Page 6
C ) Force the session to pick the outline
Put the line mentioned below in the starting of the program code to force the
session to pick the outline. Remember here we’re not making any changes in the
code .We’re just executing a session level command at the beginning of program .
After that we ask the user to run the concurrent and it got completed within 2
hours. Thus it made him and me very happy. As a DBA I believe that we should
be thankful to the developers or users. Because it’s because of them we tend
to learn new new things.
References
209197.1
212809.1
728647.1
DISCLAIMER:
The information in this document is the opinion of the author, not of Oracle Corporation. Any content, materials, information or
software downloaded or otherwise obtained through the use of the site is done at your own discretion and risk. Oracle shall have
no responsibility for any damage to your computer system or loss of data that results form the download of any content,
materials, information or software.
Page 7