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

白鳝的洞穴 2020-03-31

1041

数据库的碎片整理是我们日常运维工作中的一项不起眼的工作，技术含量不高，做的也不多。很多系统上线后从来不做碎片整理，也运行的好好的。不过也不要小看这个小操作，有时候碎片整理是能够发挥大作用的。今天和大家分享的是老白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性能也有大幅提升：

序号	SQLID	优化效果
1	akb9zf0ht1haf	性能提升18倍
2	8052aqjpzcnsm	性能提升3倍
3	4ajbwbw0h6vtb	性能提升5倍
4	bn5rynd78k14h	性能提升14倍
5	8nsma6a04pzfw	性能提升3倍
6	81ug5j5p56tma	性能提升2倍
7	17g0t2vdhjcx9	性能提升10倍
8	afp7xqq4mr5d5	性能提升8倍
9	dm1srzhp5ckmm	性能提升4倍
10	bf2sr7juj0atm	可以提高5上
11	cm3a0xrn34wq0	性能提升12倍
12	2gh1ucj3mwtpx	性能提升20倍
13	8j1791514u23f	性能提升8倍

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

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

评论