我们平台在查找使用全表扫描执行计划的SQL时，发现有些应用跑过逻辑的SQL，确认用的全表扫，但是未能实时的检索到，于是，看下用的SQL，
-
SELECT s.sql_text, P.OBJECT_OWNER,
-
P.SQL_ID,
-
P.OPERATION,
-
P.OPTIONS,
-
S.LAST_LOAD_TIME,
-
ROW_NUMBER()
OVER(
PARTITION
BY P.SQL_ID
ORDER
BY P.SQL_ID)
AS ROWNUMS
-
FROM V$SQL_PLAN P, V$SQLAREA S
-
WHERE S.SQL_ID = P.SQL_ID
-
AND P.OPERATION =
'TABLE ACCESS'
-
AND P.OPTIONS =
'FULL'
-
AND S.LAST_LOAD_TIME >= trunc(
SYSDATE
-1)
-
ORDER
BY S.SQL_TEXT, P.SQL_ID
逻辑其实很简单，就是将v$sql_plan和v$sqlarea视图进行关联，根据operation和options找到TABLE ACCESS FULL关键字，并加上时间条件，但是为什么应用确认肯定跑过的逻辑，而且肯定是全表扫描的SQL，不能找到？
究其原因，就和这个时间条件相关。我们看到，SQL中过滤时间的字段是v$sqlarea中的last_load_time，指定了大于等于昨天的00:00:00，除了这个字段，其实有个last_active_time字段，和这个很像，两者有什么区别？
在v$sqlarea视图中，last_load_time和last_active_time，解释如下，
LAST_LOAD_TIME，DATE类型
Time at which the query plan was loaded into the library cache执行计划载入library cache库缓存的时间
LAST_ACTIVE_TIME，DATE类型
Time at which the query plan was last activeSQL最新一次执行的时间
在v$sql视图中，last_load_time和last_active_time，解释如下，
LAST_LOAD_TIME，VARCHAR2(19)类型
Time at which the query plan was loaded into the library cache执行计划载入library cache库缓存的时间，但是他是VARCHAR2(19)类型
LAST_ACTIVE_TIME，DATE类型
TIme at which the query plan was last activeSQL最新一次执行的时间
执行新的SQL，这个SQL不在共享池中，这时会进行硬解析，v$sql中的last_active_time和last_load_time是硬解析的时间。
执行共享池内已经存在的SQL，会进行软解析，last_active_time是软解析的时间，也是SQL最新执行的时间，last_load_time的值不变。
因此，如果我的需求是找出前一天应用跑过的逻辑中使用全表扫描执行计划的SQL，从准确性讲，应该用的是last_active_time，不是last_load_time，因为很可能由于缓存了执行计划，last_load_time的值一直未变，此时last_active_time才会更可能满足到我们最初的需求。
近期热文：
《虚拟内存详解》
转载：https://blog.csdn.net/bisal/article/details/105630136