4月18号下午，客户找到我，说有个SQL跑不出来：“现在这张表的数据才4个月，之前12个月的都是能跑的。”
我看了他的SQL，很简单的CTAS语句：
create table t1 as
select a ,c,d from t2
where b='2022';
听到他说跑不出来，我的第一反应是这SQL该优化了，表t2是个很大的分区表。SQL的谓词条件很简单，主要看字段b的选择性怎么样。他说以前12个月的数据能跑出来，现在跑不出来，我首先怀疑，字段b上是不是有失效的索引。随后我进到数据库，看了表t2.b的选择性，很遗憾的，distinct只有6，可以说是相当差了。
此时，客户给我发来了SQL执行过程中的报错：
如果你觉得是temp表空间不足，那就大意了。以上报错的表空间rpt，是一个业务表空间，非temp表空间。普通的表空间里，哪来的temp段呢？很可能是rpt的空间分配有问题。
我当时下意识地说，rpt表空间满了。得到了以下回复：
这就很奇怪了，70多个G，难不成表T1超过了70G？实际上，表t2才20+G，T1是远小于表空间剩余量的。
难道真的是temp不够了吗？我加了一个30G的temp文件，PGA从4G硬生生加到了12G，并没有用。这个SQL，既不需要做排序，也不需要hash。表也不大。怎么会消耗那么多temp？
然后我一边跑SQL，一边观察temp的使用情况，人家SQL根本就用不了多少temp。
基本可以排除temp的问题了。
我长达11个月的运维经验告诉我，这个RPT表空间一定有问题。我换了一个表空间执行该SQL，很顺利地执行出来了，表T1 大小为760+MB。基本可以断定是RPT的问题了。
我又突然想起来，一个表空间里的剩余空间，有一部分是独特的，那就是回收站里的段。这些段里仍旧保留着被drop的表的数据，在需要的时候可以闪回数据，在表空间不足的时候可以重新使用。
我查看了回收站，里面居然有380多W条记录。
假设77431MB 的空间 全部是回收站的空间，则平均每个回收站对象的大小为0.02MB，purge 760MB的空间大约需要3h，远远超过了建表的时间。就此可以推测:由于表空间存在大量的小的回收站对象，导致在建表的过程中，回收站对象的释放太慢，出现了空间不足的情况。
接下来我执行了purge dba_recyclebin;操作，但是一分钟仅能清理200个回收站对象，380w个，全部清理需要14天。下班前开了9个会话在分月purge table。。明天再看看清理后的效果哈哈^^
今天（4月19号）看了，还有320W。。
回收站有77G，跟表空间剩余量差不多，哈哈
通过等待事件以及10046事件可以看到，在purge过程中需要访问以及修改各种数据字典……^^。路漫漫其修远兮。过几天再看了
4月21号更新：
历时3天，删了200w个回收站对象，再次建表没有再出现报错了
跟客户沟通了，以后drop表尽量带上purge子句。
