最近发现一个奇怪的问题,因为需要备份公司省份数据,使用pg_dump备份表，发现备份后的大小只有几个G大小，但是统计了表，发现居然是备份出来的几倍以上。刚开始还以为备份过程中中断出现问题了，重新备份一次大小还是一样。后来才发现是出现了膨胀非常厉害的表导致的。

如果不及时处理可能会出现 transaction wraparound的错误!详情请看:GreenPlum维护年龄的处理

膨胀表的产生

首先Greenplum的核心其实就是pg,而说到pg需要从pg的MVCC机制说起，MVCC即多版本并发控制，也就是说，在PostgreSQL中，一次行的update和delete不会立即删除旧的版本，而是被标记为删除，一旦被标记删除的行数非常多后，统计信息发现表中预期的行数和实际的行数相差很大，表的膨胀程度就很大。

膨胀表的维护

Greenplum是基于MVCC版本控制的，所有的delete并没有删除数据，而是将这一行数据标记为删除，

而且update其实就是delete加insert。所以，随着操作越来越多，表的大小也会越来越大。对于OLAP

Greenplum的VACUUM工具的介绍及使用

介绍

Greenplum的VACUUM工具，可以回收已经删除行占据的存储空间。

语法：

vacuum table;

简单的vacuum table只是简单的回收空间且令其可以再次使用。可以缓解表的增长。

这个命令执行的时候，其他操作仍可以对标的读写并发操作，没有请求排他锁。

vacuum full table;

vacuum full执行更广泛的处理，包括跨块移动行，把表压缩到最少的磁盘块数目存储。

这个命令执行的时候，需要加排他锁。

执行vacuum后，最好对表上的索引进行重建

使用

数据库层的使用：

在适当的数据库上执行建议的VACUUM; 这里我们使用默认数据库lte_mr，因此用适当的数据库名称替换该名称。

psql -d lte_mr -c "vacuum freeze"

数据表层-批量操作：

select 'psql -d lte_mr -c' || ' ' || '"VACUUM FREEZE -c'|| schemaname || '.' ||tablename || '";' 
from pg_tables;

--或者精确到schemaname

select 'psql -d lte_mr -c' || ' ' || '"VACUUM FREEZE '|| schemaname || '.' ||tablename || '";' 
from pg_tables where schemaname = 'smartinsight'  order by tablename

先执行这个sql 把这个sql 的执行结果重定向到一个sql文件中，然后执行这个文件即可。

消除数据膨胀建议:

大型update和delete操作之后务必运行vacuum ，vacuum full 不建议使用

如果一个表膨胀严重，对于小表可以通过vacuum full table_name 回收页空间

对于重度膨胀的大表有以下方法处理:

创建大表拷贝，删掉原表，然后重命名拷贝

BEGIN;
LOCK TABLE tablename;
CREATE TABLE tablename_tmp  SELECT * FROM tablename;
DROP TABLE tablename;
ALTER TABLE tablename_tmp RENAME TO tablename;
COMMIT;

可在每日空闲时定时执行:

#!/bin/bash
source /home/gpadmin/.bash_profile
psql -d postgres -c "vacuum freeze"
psql -d lte_mr -c "vacuum freeze"
psql -d pe2e_lte -c "vacuum freeze"

在直接执行nohup sh vacuum.sh > vacuum.log 2>&1 &命令