oracle数据清理日志

时间:2022-12-29 08:13:50

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;