SQL-statements with TABLE SCAN and INDEX FAST FULL SCAN

From time to time it can be smart checking your database for unwanted table scans or index fast full scans. An table scan or index full scan is not necessarily evil, but can sometimes be an indication that you are not hitting an optimal execution plan. This other day I read a note from Jonathan Lewis showing howto gather all executions plans from memory and search for such execution plans including such scans.

Warning! This SQL will really hit your shared pool while it´s running (library cache), especially if you´re having a large shared pool and a database with a relativly high workload.

select
        plan_table_output  -- (the column of the pipelined function)
from    (
                select
                        distinct sql_id, child_number
                from
                        v$sql_plan
                where   (operation = 'TABLE ACCESS' and options = 'FULL')
                or      (operation = 'INDEX' and options = 'FAST FULL SCAN')
        ) v,
        table(dbms_xplan.display_cursor(v.sql_id, v.child_number))
;

The dbms_xplan.display_cursor() is a “pipelined function”, which means it can be treated as a table using the table() operator. Spool to a file, and then walk through the different execution plans looking for odeties.

Post a Comment

Your email is never published nor shared. Required fields are marked *