这种情况我帮不少同行排查过，核心问题基本都和Oracle共享池的内存管理机制有关，咱们来拆解原因和解决办法：

核心原因 #

• 共享池的LRU清理机制：Oracle的共享池会用LRU（最近最少使用）算法自动清理内存中的SQL语句，尤其是当共享池内存不足、或者SQL长时间未被再次执行时，这些语句会被从内存中移除。你第二天查不到前一天的执行记录，甚至测试语句select * from cat也找不到，大概率是这些SQL已经被共享池“淘汰”了。
• 共享池被手动刷新：如果有人执行了ALTER SYSTEM FLUSH SHARED_POOL;命令，共享池中的所有SQL记录会被清空，自然也查不到任何历史执行语句。

解决办法 #

如果需要长期保留SQL执行历史，别再依赖内存级的v$sqltext了，试试这些方案：

1. 查询AWR历史SQL记录 #

AWR（自动工作负载库）会定期把SQL执行信息快照到磁盘上，默认每小时生成一次快照，保留7天（可通过参数调整）。你可以通过DBA_HIST_SQLTEXT视图查询历史SQL：

SELECT sql_id, sql_text 
FROM dba_hist_sqltext 
WHERE sql_text LIKE '%select * from cat%' -- 替换成你要找的SQL关键词
ORDER BY snap_id DESC;

注意：查询这个视图需要SELECT_CATALOG_ROLE权限。

2. 实时监控近期SQL #

如果只是想查最近执行的SQL（还没被共享池清理的），可以用V$SQL或者V$SQLAREA视图，它们比v$sqltext更完整，包含了SQL的执行统计信息：

SELECT sql_id, sql_text, last_active_time
FROM v$sql
WHERE sql_text LIKE '%select * from cat%'
ORDER BY last_active_time DESC;

3. 调整共享池配置（可选） #

如果你的业务需要频繁查询历史SQL，可以考虑调整共享池大小，减少SQL被LRU清理的概率：

ALTER SYSTEM SET shared_pool_size = 2G SCOPE=SPFILE; -- 根据实际内存调整大小

调整后需要重启数据库生效，建议先评估系统内存使用情况再操作。

额外提醒 #

• v$sqltext里的记录仅存在于共享池内存中，一旦数据库重启、共享池被刷新或内存不足，这些记录就会丢失，不适合长期存储执行历史。
• 如果你的SQL使用了大量字面量（而非绑定变量），会导致共享池产生大量重复SQL，加快内存清理速度，建议尽量使用绑定变量优化SQL执行。

内容的提问来源于stack exchange，提问作者user3595099