小操作有大效用-一个数据库碎片整理的优化案例

小操作有大效用-一个数据库碎片整理的优化案例

数据库的碎片整理是我们日常运维工作中的一项不起眼的工作，技术含量不高，做的也不多。很多系统上线后从来不做碎片整理，也运行的好好的。不过也不要小看这个小操作，有时候碎片整理是能够发挥大作用的。今天和大家分享的是老白2013年的一个案例。有个客户，核心系统上线5年了，数据库服务器是两台IBM P570,32核满配的。近期由于新增了一些业务，数据库服务器的负载经常会比较高，特别是月底业务高峰期，基本上一上班CPU负载就会达到90%以上，业务系统明显觉得变慢。

我们到现场的时候，系统高峰已经过了，不过系统的负载还是很高。我们看了一下数据库的LOAD PROFILE

从系统的负载上看，不算大，也不算小。按照这个负载，能把两台P570的CPU撑爆还是有点让我感到意外的。从等待事件上看：

基本也算正常，单块读响应时间6毫秒，多块读的比例2.8%，存在一些GC的争用，比例也不高3%，这和INTERCONNECT网络流量较大有关，在高峰期，网络流量已经超过60M了。这个系统是两节点的RAC,采用完全的负载均衡模式的，这种系统也经常会出现一些类似的问题。我们的采集工具采集了一下数据库的高水位情况：

我们发现数据段高水位是11TB左右，现在大约9.7TB，而数据表的数量高水位是9359，而现在是5426。继续观察TOP 10的段的情况：

我们发现系统中的一些大对象达到几十GB，而且有不少索引的大小也十分大。最大的表有90多GB，而最大的索引居然有40多GB。这是十分不正常的。于是我们立即想到了碎片问题，是不是很多表和索引存在较多的碎片呢，于是立即进行了碎片分析，发现：

以某张表为例:

有一张表只有1行数据，行长216字节，不过这个表占了67M的空间，对该表的访问产生了大量不必要的逻辑读。某些索引就更夸张了：

一张表才4480M大小，而它上面的一个索引居然有36GB，对全表进行扫描100毫秒可以完成，而全扫描一个索引需要600毫秒。于是我们建议用户在晚上时候对表碎片和索引碎片进行一次整理，表采用MOVE操作进行碎片整理，索引可以单独通过REBUILD ONLINE。通过一晚上的努力，第二天奇迹出现了，表空间腾出了1TB多的空间，CPU使用率降低到40%多，大量的SQL性能也有大幅提升：