每日一记：表空间使用情况查询慢问题分析处理（DBA_FREE_SPACE vs 回收站）

相信下边这个sql语句很多人都有用到：

select a.tablespace_name,
       a.bytes / 1024 / 1024 "Sum MB",
       (a.bytes - b.bytes) / 1024 / 1024 used,
       b.bytes / 1024 / 1024 "free MB",
       round(((a.bytes - b.bytes) / a.bytes) * 100, 2) "percent_used"
  from (select tablespace_name, sum(bytes) bytes
          from dba_data_files
         group by tablespace_name) a,
       (select tablespace_name, sum(bytes) bytes, max(bytes) largest
          from dba_free_space
         group by tablespace_name) b
 where a.tablespace_name = b.tablespace_name
 order by a.tablespace_name;

看到这篇文章的人肯定遇到上述sql执行慢的情况，正常来说，这个sql语句应该在毫秒级别内执行完成，如果不是，那么就有必要进行下面的处理了！

基础处理方法可参考：https://blog.csdn.net/shipeng1022/article/details/77990404

可考虑的处理方法是：

1、分析回收站的表是哪个用户下的并确定是否需要恢复；

2、如果需要恢复，建议修改业务逻辑，避免频繁删除对象；

引用网友的说法

如果你不更正开发的错误模式,他们会一直错下去.
从1个项目带到另外一个项目.....

引自：http://www.itpub.net/thread-2102475-1-1.html

如果不需要恢复，建议修改drop语句，带上purge参数，让删除的对象永久删除；

3、数据库层面可以做的：

a.写个job定时清空指定用户的回收站或整个回收站；

b.干脆做法：关闭数据库回收站功能【需三思！】。

什么时候需要考虑禁用回收站的功能呢？
除非有特殊需求（如系统存在大量的drop动作，但未使用到purge选项，防止占用系统空间和降低系统性能），否则不建议关闭这个功能。

引自：http://blog.itpub.net/519536/viewspace-660038/