数据清理的遗留问题处理(二)(r6笔记第91天)

之前尝试了历史数据的清理,在逻辑层面清除了数据,可以参见 http://blog.itpub.net/23718752/viewspace-1814000/

但是从物理层面来看,数据文件还是那么大,空间还是没有释放掉。

从计划的500多G数据空间清理到了90G

SEGMENT_TYPE          SIZE_MB
------------------ ----------
INDEX PARTITION        260279
TABLE PARTITION        294120

然后在经过一番清理之后,对应的段空间一下子就将下来了。

EGMENT_TYPE          SIZE_MB
------------------ ----------
INDEX PARTITION         31823
TABLE PARTITION         47218

最后全部清理完

check segement size summary from year xxx
no rows selected

现在问题来了。清理数据文件该怎么做。思路应该是在dba_segments里面去找是否存在相应的段。如果没有即代表着可以删除这些数据文件。

有的朋友可能会说为什么一定要清掉这些数据文件,这个也有历史原因,就是表空间和时间也有关系,比如某年的某月可能就会根据逻辑生成一个表空间,按照这种 思路,尽管我清除了端数据,但是放着那些数据文件,它们是不会被使用到的,还是占着地方,所以需要直接清掉,给后续的数据留空间。

目前想达到的效果就是,根据表空间能够查出来,如果某个表空间没有对应的段对象,显示为0,标志着可以清理。

select tablespace_name,count(*) from dba_segments where tablespace_name in ('xxxxx','xxx') group by tablespace_name;
xxxxx   0
xxx     0

但是实际上去写的时候发现还是没那么好弄,经过一番折腾写出了一个基本实现要求的语句,但是算是一个初始版本,因为结果显示还是有些牵强。

select tablespace_name,count(*)cnt from dba_segments where tablespace_name like '%DATA%2012%' group by tablespace_name
 union 
select tablespace_name,null cnt from dba_segments where tablespace_name  like '%DATA%2012%' group by tablespace_name
TABLESPACE_NAME                       CNT
------------------------------ ----------
SERLOG_DATA_20120705                  0
SERLOG_DATA_20120705                 11
SERLOG_DATA_20120706                  0
SERLOG_DATA_20120706                 19
SERLOG_DATA_20121007                  0
SERLOG_DATA_20121007                 31
SERLOG_DATA_20121008                  0
SERLOG_DATA_20121010                  0

按照这个情况,只有表空间SERLOG_DATA_20121010是可以删除的。其他的都会和一个dummy列并存。

当然sql写成这样也是醉了,能实现基本需求也行,但是成百上千的表空间,我觉得还是不好。继续改进。使用了minus的方式。

select tablespace_name from dba_tablespaces s1 where tablespace_name like '%DATA%2012%' 
minus
select tablespace_name  from dba_segments s1 where tablespace_name like '%DATA%2012%' group by s1.tablespace_name 

这种方式就会做一个减法,先把相关的表空间罗列出来,然后在dba_segements里面过滤组合只会显示有段对象的表空间。

这样那些隐藏着的表空间都会一一罗列出来。

直接使用drop tablespace来清理。

查看asm磁盘空间,清理前剩余80多G

GROUP_NUMBER NAME                              FREE_MB   TOTAL_MB
------------ ------------------------------ ---------- ----------
           1 ARCH                               204740     204800
           2 DATA                                84336    6383104

清除多余的数据文件,可以看到立马剩出了快400G.

GROUP_NUMBER NAME                    FREE_MB   TOTAL_MB
------------ -------------------- ---------- ----------
           1 ARCH                     204740     204800
           2 DATA                     390360    6383104

这个时候别被这些成绩所迷惑,删除分区的同时会清楚分区索引,这些分区索引的空间又是不少。至于有多少呢,我们还是使用minus的方式来清理。

清除多余的索引数据文件,清理之后剩余了近1T的空间。

GROUP_NUMBER NAME                    FREE_MB   TOTAL_MB
------------ -------------------- ---------- ----------
           1 ARCH                     203906     204800
           2 DATA                     981640    6383104

这个例子不是说明minus清理有多好,是想说清理的时候,逻辑清理100%完成,物理清理很可能会漏掉,清理了不到50%,这样我们的工作就不彻底,半途而废。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-10-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

MySQL-性能优化-索引和查询优化

14510
来自专栏Java面试通关手册

Mysql锁机制简单了解一下

Java面试通关手册(Java学习指南,欢迎Star,会一直完善下去,欢迎建议和指导):https://github.com/Snailclimb/Java_G...

171110
来自专栏吴伟祥

百万级数据库优化方案 转

1.对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

11720
来自专栏jouypub

MySQL的语句执行顺序

MySQL的语句一共分为11步,如下图所标注的那样,最先执行的总是FROM操作,最后执行的是LIMIT操作。其中每一个操作都会产生一张虚拟的表,这个虚拟的表作为...

5210
来自专栏chenssy

【死磕Sharding-jdbc】---结果合并总结

这句SQL会使得MySQL在无法利用索引的情况下跳过1000000条记录后,再获取10条记录,其性能可想而知。而在分库分表的情况下(假设分为2个库),为了保证数...

19430
来自专栏逸鹏说道

程序猿是如何解决SQLServer占CPU100%的

文章目录 遇到的问题 使用SQLServer Profiler监控数据库 SQL1:查找最新的30条告警事件 SQL2:获取当前的总报警记录数 有哪些SQL语句...

38580
来自专栏杨建荣的学习笔记

MySQL和Oracle对比学习之事务(r5笔记第4天)

MySQL中的存储引擎很是丰富,常用的有InnoDB,MyISAM等,也查看了不少的资料,基本也有所了解,从一些参考书中看MySQL中的sql部分也是一扫而过,...

47780
来自专栏Java进阶干货

MySql常用30种SQL查询语句优化方法

1、应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。

11410
来自专栏小怪聊职场

MySQL(七)|MySQL分库分表的那点事(小怪的Java群第一次话题讨论)

29940
来自专栏沈唁志

谈谈在SQL语句中的优化技巧

19340

扫码关注云+社区

领取腾讯云代金券