ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SQL优化--删除表的数据来加速

SQL优化--删除表的数据来加速

原创 Linux操作系统 作者:wadekobe9 时间:2012-01-19 14:55:23 0 删除 编辑

今天上午查看em工具,在9点半的时候applications又升

到了60去,虽然很快释放,没有引起数据库慢,但是这

里还是重视一下。用上午8点到10的快照做成一个awr报告,

通过查看 SQL Statistice-SQL ordered by elapsed time,

找出排名第一的SQL,Sql如下:

SELECT message_id, reciver_employee_id, msg_type, msg_title, msg_content,

       operator_time, linkurl, TIMEOUT, position_id, awake_time

  FROM t_s_message

 WHERE (show_times > 0 AND awake_time <= SYSDATE)

    OR (show_times > 0 AND awake_time IS NULL)


查看这个SQL,发现执行计划很糟糕,其实就是一个全表扫描,t_s_message这张

表应该也清理一下了,但是整理数据库表空间的时候看这个表小就暂时没有做处

理,现在处理一下当时说的t_s_message这张表留半年的


删出表内容的时候要注意的一个地方

select   a.owner 主键拥有者,

         a.table_name 主键表,

         b.column_name 主键列,

         C.OWNER 外键拥有者,

         c.table_name 外键表,

         d.column_name 外键列

from user_constraints a,

     user_cons_columns b,

     user_constraints C,

     user_cons_columns d

where  a.constraint_name=b.constraint_name 

and C.R_CONSTRAINT_NAME=a.constraint_name 

and c.constraint_name=d.constraint_name 

and a.constraint_type='P' 

and a.table_name='T_S_MESSAGE' --需要查看主外键关系的表

order by a.table_name


结果为零行,说明这个表里面的数据没有被其他表的外键所参考,

这样的话,这个表就可以删除,还是用移表的方式,直接删除肯

定还是会报外键约束删不掉的错误,但是如果用rename的方式移

除表的话,数据库就会报错了



Create Table t_s_Message_bak_2011 As Select * From t_s_message

 

保险期间还是分时间段删除,这个很重要,有次在测试机上面直接

删100W数据就出现了性能问题,整个数据库性能急剧下滑,当我要

停掉会话的时候发现还停不掉,我手工从系统层面将会话结束,不

过数据库仍然很慢,我知道据库还在做回滚,一次删除太多,回滚

的时间也会很长,而且在这期间仍然是影响性能的,所以正式库上

删除数据一定要小心再小心

Delete From t_s_message a Where a.operator_time

 Between to_date('2010-03-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS') and to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')  

 

Delete From t_s_message a Where a.operator_time

 Between to_date('2011-01-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS') and to_date('2011-06-01 00:00:00','yyyy/MM/DD/ HH24:MI:SS')  


 

删除完后,查看执行计划仍然没有改变,收缩一下表

SQL> alter table t_s_message shrink space;


alter index MESSAGE_RECIVER_POSTION_FK rebuild

alter index PK_T_S_MESSAGE rebuild

alter index CASE_MESSAGE_FK rebuild

alter index MESSAGE_SENDER_FK rebuild

alter index MESSAGE_RECIVER_FK rebuild

这里直接用的rebuild,没有用online,速度比较快,他们的具体差异

大致说就是有一张临时表的过渡,让rebuild online的时候索引仍然

能正常使用,不过这种操作还是比较消耗系统资源,应当在系统较为

空闲的时候再做次操作


收集一下统计信息

exec dbms_stats.gather_table_stats('GC','T_S_MESSAGE');


整个完成后,上面那条SQL运行就很快了,我渐渐意识

到有的SQL并不是说要如何如何优化,一个合理的业务

需求也是很重要的,在线交易系统里面的表是不是应该

控制一下大小,不能无限制的增大



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10678398/viewspace-715103/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-11-30

  • 博文量
    36
  • 访问量
    56709