ORACLE 回收站导致的故障
一、故障
（1）现象
一个生产环境，oracle数据库挂死，严重影响生产。查死锁sql，发现大量日志插入语句，并且每条运行时间都超过一分钟，插入非常缓慢。据分析，可能是由于日志表过大，日志表索引不合理等，对表进行的优化，但是，问题继续。
（2）分析
查数据库服务器宕机的时间段的dwr，发现，除插入大量日志语句外，delete from RecycleBin$语句跑了近百万次。豁然开朗，原来是回收站在回收数据。现场的表空间紧张，然而在晚上有跑了大量的数据，没有truncate表，直接drop掉表，导致表空间没有释放，回收站在没有空间的情况下，清理回收站，以便释放空间。直接导致插入等待，而使oracle挂死。
（3）解决
1：关闭回收站
2：新增表空间
3：大量跑数据，需要使用临时表。临时表的数据不会入回收站。
临时表空间不会存储永久类型的对象，所以它不会也不需要备份。另外，对临时数据文件的操作不产生redo日志，不过会生成undo日志。
创建临时表空间或临时表空间添加临时数据文件时，即使临时数据文件很大，添加过程也相当快。这是因为ORACLE的临时数据文件是一类特殊的数据文件:稀疏文件（Sparse File）,当临时表空间文件创建时，它只会写入文件头部和最后块信息。它的空间是延后分配的.这就是创建临时表空间或给临时表空间添加数据文件飞快的原因。
二、回收站介绍
回收站(Recycle Bin）从原理上来说就是一个数据字典表，放置用户删除（drop）掉的数据库对象信息。用户进行删除操作的对象并没有被数据库删除，仍然会占用空间。除非是由于用户手工进行Purge或者因为存储空间不够而被数据库清掉。如果一个表被删除，那么与该表有关联的对象，例如索引、约束和其他依赖对象都会在前面加bin$$这个前缀。它以表空间中现有已经分配的空间为基础，而不是从表空间上物理划出一个固定区域用作回收站。这意味着回收站和表空间中的对象共用存储区域、系统没有给回收站预留空间。。因此，当表被DROP后，如果可用空间充足，并且没有对回收站进行清理，那么被DROP掉的对象会一直存在回收站中，但是如果可用空间紧张的情况下，数据库会根据先进先出的顺序覆盖Recycle Bin中的对象。所以回收站机制也不是百分百的保险机制。另外从原理上来说它就是一个数据字典表，放置用户Drop掉的数据库对象信息。用户进行Drop操作的对象并没有真正被数据库删除，仍然会占用空间。除非是由于用户手工进行Purge或者因为存储空间不够而被数据库清掉。数据库有了这样的功能，能够减少很多不必要的麻烦。当用户、开发人员、甚至DBA误操作删除了表，那么我们不必还原整个数据库或表空间，直接使用ORACLE 10g的闪回(FLASHBACK,闪回)功能来还原被删除的表。这样我们就能避免大量的人工误操作。这是一个对DBA相当有用的功能。
（1）回收站的启动和关闭
SELECT Value FROM V$parameter WHERE Name = 'recyclebin';
ALTER SYSTEM SET recyclebin = ON; //OFF
(2) 闪回
对表进行了误操作，drop掉了，在回收站打开的情况下，可以闪回。
FLASHBACK TABLE <<Dropped_Table_Name>> TO BEFORE DROP;