https://www.oraclescripts.com/tags/display_cursor/Recent content in DISPLAY_CURSOR on Oracle ScriptsHugo -- gohugo.ioenOracleScripts.comSun, 13 Sep 2026 00:00:00 +0000https://www.oraclescripts.com/post/get-actual-execution-plan-dbms-xplan-display-cursor/Sun, 13 Sep 2026 00:00:00 +0000https://www.oraclescripts.com/post/get-actual-execution-plan-dbms-xplan-display-cursor/ <h2 id="get-the-actual-execution-plan-with-dbms_xplandisplay_cursor">Get the Actual Execution Plan with DBMS_XPLAN.DISPLAY_CURSOR</h2> <h2 id="purpose">Purpose</h2> <p><code>EXPLAIN PLAN</code> never runs the statement it describes. It asks the optimizer what it <em>would</em> do, based on statistics and cardinality estimates, and prints that guess — which is exactly why a query that looks fine in <code>EXPLAIN PLAN</code> can still run slow in production: skewed data, stale statistics, or a bind variable peeked at parse time can all send the real execution down a different path than the estimate shows. <strong><a href="https://docs.oracle.com/en/database/oracle/oracle-database/18/arpls/DBMS_XPLAN.html">DBMS_XPLAN</a></strong>'s <code>DISPLAY_CURSOR</code> table function closes that gap. Instead of estimating, it reads the plan already sitting in the cursor cache for a statement that has actually executed — sourced from <code>V$SQL_PLAN</code>, <code>V$SQL</code>, and, when the statement was parsed with the right hint in place, <code>V$SQL_PLAN_STATISTICS_ALL</code> — and returns the real operations Oracle chose, not the ones it might have chosen.</p>