![]() If you click on the drop-down bit of the Explain Plan button, what you’ll see are a list of the cached plans for that statement – that is, plans that were ACTUALLY used to execute the statement. So what does this look like in SQL Developer now? Note the drop-down control added to the Explain Plan button in the worksheet toolbar. For EXPLAIN PLAN, you would need to set up an identical environment to get the same plan when executing the statement. The advantage of V$SQL_PLAN over EXPLAIN PLAN is that you do not need to know the compilation environment that was used to execute a particular statement. Its definition is similar to the PLAN_TABLE. V$SQL_PLAN contains the execution plan for every statement stored in the cursor cache. So for version 4.0 of SQL Developer, when you’re in the worksheet and you want to see a plan, you now have the option to look at the plans in V$SQL_PLAN for your query.Īfter the statement has executed, you can display the plan by querying the V$SQL_PLAN view. This can differ from the plan during actual execution for a SQL statement, because of differences in the execution environment and explain plan environment. ![]() EXPLAIN PLAN output shows how Oracle runs the SQL statement when the statement was explained. ![]() With the query optimizer, execution plans can and do change as the underlying optimizer inputs change. If you do an Explain, you’re actually looking at a theoretical plan, not the ‘actual’ plan. To clarify, I would say that explain plans could be useless. Really? Don’t we spend all day looking at execution plans?
0 Comments
Leave a Reply. |