|
I haven't looked at your detailed analysis in the later messages. But to answer "对这些超长的SQL ,调优步骤是什么? 有什么好的建议?", here's my suggestion: focus on the biggest cost jump or jumps. In this case, your execution plan in message #4 has this part:
| HASH JOIN | | 1 | 199 | 254 |
| NESTED LOOPS | | 1 | 180 | 14 |
...
| TABLE ACCESS FULL |PS_PER_ORG_ASGN | 12K| 237K| 239 |
The total cost 283 is mostly the hash join shown above, with a cost of 254. Of this 254, 239 is contributed by the FTS of PS_PER_ORG_ASGN. So check to see if this FTS can be eliminated.
Of course this assumes your actual plan is indeed this one and cost is accurate (in the sense that it reflects the relative buffer gets among all the lines). A more accurate check of the lines in the plan is to find the line specific buffer gets:
alter session set "_rowsource_execution_statistics"=true;
--run the SQL
select * from table(dbms_xplan.display_cursor('', '', 'allstats'));
Yong Huang
[ 本帖最后由 Yong Huang 于 2011-8-19 12:38 编辑 ] |
|