oracle数据清理日志
背景：
公司生产数据库服务器表空间free不足，整个空间32个G，92%的空间被5%的表给占了；
这几张大表中大部分都是历史数据，实际可用数据只需6个月内即可，每张表有2000万左右的数据，检索效率较低；
为了节省空间，提供表的检索效率，所以考虑对这几张大表进行历史数据清理；
方案：
1）利用凌晨0：00到5：00生产系统停服的机会，停应用服务，让数据库处于空闲状态；
2）历史数据清理，采用procedures使用delete进行500条每次批量清理，每10000条要commint一次，且sleep5秒；
3）对于可清空的表，推荐使用truncate table drop storage，这样效率高，清理彻底；
3）表空间释放，采用move table、deallocate table、rebuild index
实施：
1）0点后，开始，第一步，stop app-server，检查数据库连接数及数据库服务器cpu情况，确认数据库服务器处于空闲状态，一切顺利；
2）第二步，truncate了2张表，非常快；如果发现truncate掉的表的空间仍然很大，建议使用alter table deallocate unused keep 0进行整理；
3）move了2张表，虽然速度较慢，但是还算顺利，move前检查了表空间freespace大小，第二步truncate释放出了一些空间，所以够move用的；
4）第三步，move完了对索引进行重建，出了个岔子，吓得满头大汉，事情是这样的：重建其中一个索引时，突然数据库连接中断并报错ORA-00257 archiver error:Connect internal only,util freed.，怎么连也连不上，晕了，赶紧查google，还算找到原因，原来是快速恢复区的归档日志滿了，解决办法就是清理归档日志即可；接下来的事情让我痛不欲生哈；我直接去归档日志目录下，用rm命令清理了20个G的日志文档，以外这样就可以恢复了，可是还是没恢复，尝试重启数据库也失败，崩溃啊，后悔准备工作没到位；当时是凌晨，叫天天不应叫地地不灵啊，只能硬着头皮继续google，终于想起来清理归档日志手工方式是不可取的，应该用ram进行，失望了，rm掉的东西基本很难恢复，系统5点前要恢复哪有可能？真想找个时空隧道永远消失。。。。。。继续google吧，真幸运，有人遇到过类似的问题，并给出的解决办法：
rman target /
crosscheck archivelog all;
delete expired archivelog all;尝试了一下果然奏效，数据库重启后恢复了，窃喜！
这把快速恢复区空了，继续我的index rebuild工作吧，很快把2张表的index重建完毕；
5）再去查看了表空间，厉害，差不多释放了50%的空间，16个G啊；
6）检查数据库服务正常后，启动各个应用服务，一切正常；
7）好了，清理结束，大功告成，手工，很有成就感
总结：
1）进行大数据量清理时，最好保持数据库空闲，如果有可能最好进行备份；
2）Move前，确保tablespace中有一倍于被move的表大小的free space，否则会报错；
3）Move和rebuild前，检查一下快速恢复区的归档日志大小，如果比较大建议使用ram进行清理，否则会导致数据库服务异常；
4）Move后，被move表的索引必须rebuild;