vacuum清理数据库

转载地址：http://www.91linux.com/html/article/guanli/20070621/2902.html

1. 综述

为了保持所安装的 PostgreSQL 服务器平稳运行, 我们必须做一些日常性的维护工作。
我们在这里讨论的这些工作都是经常重复的事情， 可以很容易地使用标准的 Unix 工具，比如cron 脚本来实现。 不过，设置合适的脚本以及检查它们是否成功执行则是数据库管理员的责任， 一件很明显的维护工作就是经常性地创建数据的备份拷贝。 
如果没有最近的备份，那么您就没有从灾难中恢复的机会（比如磁盘坏了，失火，误删了表等等）。
其它主要的维护范畴的工作包括周期性的 "vacuuming" （清理）数据库。
其它需要周期性注意的东西是日志文件的管理。
PostgreSQL 和其它数据库产品比较起来是低维护量的。 
但是，适当在这些任务上放一些注意将更加能够确保我们的愉快工作和获取对这个系统富有成效的经验。 
操作环境：PostgreSQL9.6+centos 7.0


2.常清理
2.1 VACUUM;


2.1.1 语法结构；
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ]
VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]


2.1.2 描述；
VACUUM 
回收已删除元组占据的存储空间。 在一般的 PostgreSQL 操作里， 那些已经 DELETE 的元组或者被 UPDATE 过后过时的元组是没有从它们所属的表中物理删除的； 在完成 VACUUM 之前它们仍然存在。 因此我们有必须周期地运行 VACUUM， 特别是在常更新的表上，如果没有参数，VACUUM 处理当前数据库里每个表， 如果有参数，VACUUM 只处理那个表，简单的 VACUUM （没有FULL） 只是简单地回收空间并且令其可以再次使用；


2.1.3 参数；
FULL 
------选择"完全"清理，这样可以恢复更多的空间， 但是花的时间更多并且在表上施加了排它锁。
FREEZE 
------选择激进的元组"冻结"。
VERBOSE 
------为每个表打印一份详细的清理工作报告。
ANALYZE 
------更新用于优化器的统计信息，以决定执行查询的最有效方法。
table 
------要清理的表的名称（可以有模式修饰）。缺省时是当前数据库中的所有表。
column 
------要分析的具体的列/字段名称。缺省是所有列/字段。


2.1.4 
为什么要用VACUUM；
VACUUM命令的含义为：垃圾收集以及可选地分析一个数据库。VACUUM回收已删除元组占据的存储空间。
在一般的 PostgreSQL 操作里，那些已经 DELETE 的元组或者被 UPDATE 过后过时的元组是没有从它们所属的表中物理删除的； 在完成 VACUUM 
之前它们仍然存在。 
由于以下几个原因，我们必须周期性运行 PostgreSQL 的 VACUUM 命令∶ 
1.恢复那些由已更新的或已删除的行占据的磁盘空间。
2.更新 PostgreSQL 查询规划器使用的数据统计信息。
3.避免因为事务 ID 重叠造成的老旧数据的丢失。 
对上面每个条件进行 VACUUM 操作的频率和范围因不同的节点而不同。 
因此，数据库管理员必须理解这些问题并且开发出合适的维护策略。
建议经常VACUUM（清理）（至少每晚一次）生产数据库， 以保证不断地删除失效的行。尤其是在增删了大量记录之后， 对受影响的表执行 VACUUM ANALYZE 命令是一个很好的习惯。例如：
MH=> vacuum full verbose  analyze r_data_main_test;
INFO:  vacuuming "public.r_data_main_test"
INFO:  "r_data_main_test": found 29230324 removable, 31473910 nonremovable row versions in 1076558 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 11.11s/35.82u sec elapsed 152.01 sec.
INFO:  analyzing "public.r_data_main_test"
INFO:  "r_data_main_test": scanned 30000 of 481500 pages, containing 1961024 live rows and 0 dead rows; 30000 rows in sample, 31473943 estimated total rows
VACUUM
Time: 311716.828 m





VACUUM
这样做将更新系统目录为最近的更改，并且允许 PostgreSQL 查询优化器在规划用户查询时有更好的选择。
不建议日常使用 FULL 选项，但是可以在特殊情况下使用。 一个例子就是在您删除了一个表的大部分行之后，希望从物理上缩小该表以减少磁盘空间占用。VACUUM FULL 通常要比单纯的 VACUUM 收缩更多表的尺寸。


2.2 恢复磁盘空间
2.2.1 概述
在正常的 PostgreSQL 操作里， 对一行的UPDATE或DELETE并未立即删除旧版本的数据行。 这个方法对于获取多版本并行控制的好处是必要的： 
如果一个行的版本仍有可能被其它事务看到，那么您就不能删除它。 但到了最后，不会有任何事务对过期的或者已经删除的元组感兴趣。 而它占据的空间必须为那些新的元组使用而回收， 以避免对磁盘空间增长的无休止的需求。这件事是通过运行 VACUUM 实现的。
很明显，那些经常更新或者删除元组的表需要比那些较少更新的表清理的更频繁一些。 所以，设置一个周期性的 cron 任务 VACUUM那些选定的表，而忽略那些已经知道变化比较少的表． 这个方法只是在您拥有大量更新频繁的表和大量很少更新的表的时候有意义 — 清理一个小表的额外开销根本不值得担心； 
VACUUM 命令有两个变种:
第一种形式，叫做"懒汉 vacuum"或者只是 VACUUM， 
在表和索引中标记过期的数据为将来使用；它并不试图立即恢复这些过期数据使用的空间。因此，表文件不会缩小，并且任何文件中没有使用的空间都不会返回给操作系统。这个变种的 VACUUM 可以和通常的数据库操作并发执行。
第二种形式是 VACUUM FULL 命令。 
这个形式使用一种更加激进的算法来恢复过期的的行版本占据的空间。任何 VACUUM FULL 释放的空间都立即返回给操作系统。 但是，这个形式的 VACUUM 命令不可以和通常的数据库操作并发执行。


2.2.2 VACUUM FULL
VACUUM FULL 一个表的时候在其上要求一个排他锁。 因此，经常使用 VACUUM FULL 会对并发数据库查询有着非常糟糕的影响;
标准形式的 VACUUM 最适合用于维护相当程度的磁盘用量的稳定状态。 
如果您需要把磁盘空间归还给操作系统，那么您可以使用 VACUUM FULL — 不过如果释放的磁盘空间又会很快再次被分配又怎样？ 
如果维护更新频繁的表，那么中等频率的多次标准 VACUUM 运行方法比很低频率的 VACUUM FULL 更好;
对于大多数节点而言，我们推荐的习惯是在一天中的低使用的时段安排一次整个数据库的 VACUUM， 必要时外加对更新频繁的表的更经常的清理。 （有些环境下，对那些更新非常频繁的表可能会每几分钟就 VACUUM 一次。） 
如果您的集群中有多个数据库，别忘记对每个库进行清理； vacuumdb脚本可能会帮您的忙。
如果您知道自己刚删除掉一个表中大部分的行，那么我们建议使用VACUUM FULL，这样该表的稳定态尺寸可以因为VACUUM FULL更富侵略性的方法而显著减小。日常的磁盘空间清理，请使用 VACUUM，而不是 VACUUM FULL。
如果您有一个表，它的内容经常被完全删除，那么可以考虑用 TRUNCATE，而不是后面跟着 VACUUM 的 DELETE。 TRUNCATE 立即删除整个表的内容， 而不要求随后的 VACUUM 或者VACUUM FULL 来恢复现在没有用的磁盘空间; 


2.3 更新规划器统计;
PostgreSQL 的查询规划器依赖一些有关表内容的统计信息用以为查询生成好的规划。 这些统计是通过ANALYZE 命令获得的，您可以直接调用这条命令， 也可以把它当做 VACUUM 里的一个可选步骤来调用。 拥有合理准确的统计是非常重要的，否则，选择了恶劣的规划很可能会降低数据库的性能； 
和为了回收空间做清理一样，经常更新统计信息也是对更新频繁的表更有用。 不过，即使是更新非常频繁的表，如果它的数据的统计分布并不经常改变，那么也不需要更新统计信息。 一条简单的拇指定律就是想想表中字段的最大很最小值改变的幅度。比如，一个包含行更新时间的timestamp字段将是随着行的追加和更新稳定增长最大值的； 这样的字段可能需要比那些包含访问网站的 URL的字段更频繁一些更新统计信息。 那些URL字段可能改变得一样频繁，但是其数值的统计分布的改变相对要缓慢得多；
我们可以在特定的表，甚至是表中特定的字段上运行 ANALYZE ，所以如果您的应用有需求的话，我们是可以对某些信息更新得比其它信息更频繁的。不过，在实际中，这种做法的实用性是值得怀疑的。
ANALYZE是一项相当快的操作，即时在大表上也很快， 因为它使用了统计学上的随机采样的方法进行行采样， 而不是把每一行都读取进来。因此，每隔一段时间对整个数据库运行一便这条命令可能更简单。
注：尽管用 ANALYZE 按字段进行挖掘的方式可能不是很实用， 但您可能还是会发现值得按字段对 ANALYZE 
收集的统计信息的详细级别进行调整。 那些经常在WHERE子句里使用的字段如果有非常不规则的数据分布， 那么就可能需要比其它字段更细致的数据图表．参阅 ALTER TABLE SET STATISTICS．
我们对大多数节点都建议在每天的低使用时段安排一次数据库范围的 ANALYZE： 这个任务可以有效地和每天的 VACUUM 组合在一起。 不过，这对那些表统计信息改变相对缓慢的节点可能会过于夸张，而且少一些的 ANALYZE 也足够了。