This is the first grocery store 450 articles
He has written articles on how to get the Oracle implementation of the plan, "the implementation of a plan to change the abnormal case - rumor query execution plan in several ways," which describes various methods to get the SQL execution plan, Liang teacher's book " harvest, more than SQL optimization ", this in several ways, in terms of acquiring step, the advantages and disadvantages, application scenarios, etc., to do a systematic order, you can compare learning,
|
method |
An acquisition step |
advantage |
Shortcoming |
Scenarios |
|---|---|---|---|---|
|
explain plan for |
Step 1: explain plan for the SQL to be executed Step 2: select * from table (dbms_xplan.display ()); PS For convenience display format can be set, for example: set long 10000set pagesize 10000set linesize 10000 |
Without real implementation, fast and convenient |
1. There is no runtime statistics relevant output (the logical number is generated read, how many recursive calls, the number of times where physical time);. 2 process can not determine how many rows; 3 can not be determined how many times the table has been visited; |
If a SQL execution time is a long time to guess the result or not return results |
|
set autotrace on |
Step 1: set autotrace on Step 2: Perform your SQL here |
1. relevant statistical information can be output at runtime (produce much logic to read, how many times recursive calls, how many cases of physical read); 2. While the statement is finished must wait before they can output execution plan, but may have traceonly switch control returns to the result of not playing screen output; |
1. have to wait until after the statement is true is finished, it can be the result; 2 can not see how many times the table is accessed; |
I want to know roughly the number of recursive calls recursive calls, using this method, detailed by 10046 trace method |
|
statistics_level=all |
Step 1: alter session set statistics_level = all; Step 2: execute your SQL here; Step 3: select * from table (dbms_xplan.display_cursor (null, null, 'allstats last')); |
1. STARTS can be clearly derived from the table is accessed many times;. 2 to obtain the number of rows can be clearly predicted and actual number of lines from the E-ROWS A-ROWS, and thereby can accurately determine the accuracy of assessment of Oracle; 3 Although no specific statistics about the runtime output, but the execution plan BUFFERS is the real value of logical read; |
1. have to wait until after the statement is true is finished, it can be the result; 2 can not control the output records to show or not, and autotrace and traceonly can not control the output hit record screen; 3. do not see the number of recursive calls, see no values of physical read; |
To get the number of tables that are accessed only use 3 |
|
dbms_xplan.display_cursor |
select * from table (dbms_xplan.display_cursor ( '& sql_id')) ;, which is obtained from the shared pool |
1. know sql_id immediately available implementation plans, and explain plan for execution without the same; 2. can get the real implementation plan; |
1. There is no runtime statistics relevant output (the logical number is generated read, how many recursive calls, the number of times where physical time);. 2 process can not determine how many rows; 3 can not be determined how many times the table has been visited; |
Observe a strip a number of SQL execution plan case |
|
Event 10046 trace track |
Step 1: alter session set events '10046 trace name context forever, level 12'; (open track) Step 2: execute your words; Step 3: alter session set events '10046 trace name context off'; (off-track); step 4: locate the file produced after tracking; step 5: tkprof trc file destination; |
1. As can be seen SQL statements corresponding wait event; 2. If the SQL statement has a function call, SQL has SQL, all will be listed, nowhere to hide; 3 can be easily seen that the number of rows processed , the physical logic generates read;. 4 can be easily seen that the analysis time and execution time; 5 can track the entire package; |
1. Step cumbersome, too much trouble; 2 can not determine how many times the table is accessed; 3. predicate part of the implementation plan does not clearly show up; |
If the SQL contains functions, function and sets SQL, etc., that is, multilayered call exist, we want accurate analysis can only use this method |
|
awrsqrpt.sql |
Step 1: @ / rdbms / admin / awrsqrpt.sql; Step 2:? Select a breakpoint (begin snap and end snap) you want; Step 3: Enter your sql_id; |
You can easily see multiple execution plans; |
The process of acquiring too much trouble; |
I wanted to see a strip of multiple SQL execution plans to use the method |
In order to obtain the most accurate possible execution plan, the most important point is that this is truly executed SQL, only really performed, the corresponding implementation plan is the most real, or obtained through estimates, will there is a deviation of ,
In order to facilitate editing, finishing the picture format, as well as excel format, you can download,
1. Picture format
https://github.com/bisal-liu/oracle/blob/master/explain/%E6%89%A7%E8%A1%8C.png
2. excel format
https://github.com/bisal-liu/oracle/blob/master/explain/%E6%89%A7%E8%A1%8C.xlsx