为了保持所安装的 PostgreSQL 服务器平稳运行, 我们必须做一些日常性的维护工作。我们在这里讨论的这些工作都是经常重复的事情， 可以很容易地使用标准的 Unix 工具，比如cron 脚本来实现。 不过，设置合适的脚本以及检查它们是否成功执行则是数据库管理员的责任，
一件很明显的维护工作就是经常性地创建数据的备份拷贝。 如果没有最近的备份，那么你就没有从灾难中恢复的机会（比如磁盘坏了，失火，误删了表等等）。 可以在PostgreSQL 里面使用的备份和恢复机制在 Chapter 23 里面有比较详细的讨论。
其它主要的维护范畴的工作包括周期性的 "vacuuming" （清理）数据库。 这个工作我们在 Section 22.1里讨论。
其它需要周期性注意的东西是日志文件的管理。 我们在 Section 22.3 里讨论了这个问题。
PostgreSQL 和其它数据库产品比较起来是低维护量的。 但是，适当在这些任务上放一些注意将更加能够确保我们的愉快工作和获取对这个系统富有成效的经验。
由于以下几个原因，必须周期性运行 PostgreSQL 的 VACUUM 命令∶
恢复那些由已更新的或已删除的行占据的磁盘空间。
更新 PostgreSQL 查询规划器使用的数据统计信息。
避免因为事务 ID 重叠造成的老旧数据的丢失。
对上面每个条件进行 VACUUM 操作的频率和范围因不同的节点而不同。 因此，数据库管理员必须理解这些问题并且开发出合适的维护策略。 本节的重点就放在解释这些高级别的问题； 至于命令语法的细节，请参阅 VACUUM 命令手册页。
从 PostgreSQL 7.2 开始， VACUUM 的标准形式可以和普通的数据库操作 （selects, inserts, updates, deletes, 但不包括表定义的修改）。 因此日常的清理也不再象以前的版本那样具有干扰性， 也不再那么特别要求安排在每天的低使用的时间里进行。
从 PostgreSQL 8.0 开始，有一些配置参数可以设置， 用来进一步减小后端清理的的性能影响。参阅 Section 17.4.4。
在 PostgreSQL 8.1 中增加了一个自动的机制，用于执行必要的 VACUUM 操作。参阅 Section 22.1.4。
在正常的 PostgreSQL 操作里， 对一行的UPDATE或DELETE并未立即删除旧版本的数据行。 这个方法对于获取多版本并行控制的好处是必要的（参阅 Chapter 12）： 如果一个行的版本仍有可能被其它事务看到，那么你就不能删除它。 但到了最后，不会有任何事务对过期的或者已经删除的元组感兴趣。 而它占据的空间必须为那些新的元组使用而回收， 以避免对磁盘空间增长的无休止的需求。这件事是通过运行 VACUUM 实现的。
很明显，那些经常更新或者删除元组的表需要比那些较少更新的表清理的更频繁一些。 所以，设置一个周期性的 cron 任务 VACUUM 那些选定的表，而忽略那些已经知道变化比较少的表． 这个方法只是在你拥有大量更新频繁的表和大量很少更新的表的时候有意义 — 清理一个小表的额外开销根本不值得担心．
VACUUM 命令有两个变种。第一种形式，叫做"懒汉 vacuum"或者只是 VACUUM， 在表和索引中标记过期的数据为将来使用；它并不试图立即恢复这些过期数据使用的空间。 因此，表文件不会缩小，并且任何文件中没有使用的空间都不会返回给操作系统。 这个变种的 VACUUM 可以和通常的数据库操作并发执行。
第二种形式是 VACUUM FULL 命令。 这个形式使用一种更加激进的算法来恢复过期的的行版本占据的空间。 任何 VACUUM FULL 释放的空间都立即返回给操作系统。 但是，这个形式的 VACUUM 命令在进行 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 来恢复现在没有用的磁盘空间。
PostgreSQL 的查询规划器依赖一些有关表内容的统计信息用以为查询生成好的规划。 这些统计是通过ANALYZE 命令获得的，你可以直接调用这条命令， 也可以把它当做 VACUUM 里的一个可选步骤来调用。 拥有合理准确的统计是非常重要的，否则，选择了恶劣的规划很可能降低数据库的性能。
和为了回收空间做清理一样，经常更新统计信息也是对更新频繁的表更有用。 不过，即使是更新非常频繁的表，如果它的数据的统计分布并不经常改变，那么也不需要更新统计信息。 一条简单的拇指定律就是想想表中字段的最大很最小值改变的幅度。 比如，一个包含行更新时间的 timestamp 字段将是随着行的追加和更新稳定增长最大值的； 这样的字段可能需要比那些包含访问网站的 URL 的字段更频繁一些更新统计信息。 那些 URL 字段可能改变得一样频繁，但是其数值的统计分布的改变相对要缓慢得多。
我们可以在特定的表，甚至是表中特定的字段上运行 ANALYZE， 所以如果你的应用有需求的话，我们是可以对某些信息更新得比其它信息更频繁的。 不过，在实际中，这种做法的有用性是值得怀疑的。 从 PostgreSQL 7.2 开始， ANALYZE 是一项相当快的操作，即时在大表上也很快， 因为它使用了统计学上的随机采样的方法进行行采样， 而不是把每一行都读取进来。因此，每隔一段时间对整个数据库运行一便这条命令可能更简单。
提示: 尽管用 ANALYZE 按字段进行挖掘的方式可能不是很实用， 但你可能还是会发现值得按字段对 ANALYZE 收集的统计信息的详细级别进行调整。 那些经常在WHERE子句里使用的字段如果有非常不规则的数据分布， 那么就可能需要比其它字段更细致的数据图表．参阅 ALTER TABLE SET STATISTICS．
我们对大多数节点都建议在每天的低使用时段安排一次数据库范围的 ANALYZE： 这个任务可以有效地和每天的 VACUUM 组合在一起。 不过，这对那些表统计信息改变相对缓慢的节点可能会过于夸张， 而且少一些的 ANALYZE 也足够了。
PostgreSQL 的 MVCC 事务语意依赖于比较事务 ID(XID)的数值： 一条带有大于当前事务的 XID 的插入 XID 的行版本是"属于未来的"， 并且不应为当前事务可见。但是因为事务 ID 的大小有限（在我们写这些的时候是 32 位）， 如果一次集群如果运行的时间很长（大于 4 十亿次事务）， 那么它就要受到事务 ID 重叠的折磨：XID 计数器回到零位， 然后突然间所有以前的事务就变成看上去是在将来的 — 这意味着它们的输出将变得可见。 简而言之，可怕的数据丢失，（实际上数据仍然在那里，但是如果你无法获取数据，这么说也只是幸灾乐祸。）
在 PostgreSQL 7.2 之前， 防御 XID 重叠的唯一办法就是至少每4十亿事务就重新做一次initdb。 这种做法对高流量的节点而言当然不是令人满意的做法，所以我们设计了更好的方法。 新的方法允许某个服务器仍然保持运行状态，不需要 initdb 或者任何类型的重启。 代价就是下面这样的维护要求： 数据库中的每个表都必须在每十亿次事务中至少清理一次 ．
从实际角度出发，这个要求不算一个很繁重的要求， 但是因为如果我们没能满足这个要求的后果是全部数据的丢失（而不仅仅是磁盘空间的浪费或者性能的下降）， 我们制作了一些特殊的东西来帮助数据库管理员避免灾难的发生。 对于集群中的每个数据库，PostgreSQL 都跟踪自上次全数据库范围 VACUUM 以来的时间。 如果任何数据库接近了十亿次事务的危险级别，系统就开始发出警告信息。 如果什么都不干，那么系统最终会停止正常的操作，直到进行了合适的手工操作。 本节剩下的部分给出这方面的细节。
XID 比较的新方法剥离出两个特殊的 XID，数字 1 和 2 （BootstrapXID 和 FrozenXID）。 这两个 XID 总是被认为表任何普通的 XID 旧。普通的 XID（那些大于 2 的）使用模-231运算进行比较。 这就意味着对于每个普通的 XID，总是有二十亿个 XID 是"更旧"以及二十亿个 XID"更新"； 表达这个意思的另外一个方法是普通的 XID 空间是没有终点的环。 因此，一旦一条元组带着特定的普通 XID 创建出来，那么该元组 将在以后的二十亿次事务中表现得是"在过去"，而不管我们说的是哪个普通 XID。 如果该元组在超过二十亿次事务之后仍然存在， 那么它就会突然变成在将来的元组。为了避免数据丢失， 老的元组必须在到达二十亿次事务的年龄之前的某个时候赋予 XID FrozenXID。 一旦它被赋予了这个特殊的 XID，那么它们在所有普通事务面前表现为 "在过去"，而不管事务 ID 是否重叠， 因此这样的元组直到删除之前都会完好，不管要保存多长时间．这个 XID 的重新赋值是VACUUM 控制的．
VACUUM 的正常策略是给任何其普通 XID 有超过十亿次已过去事务行版本重新赋值为 FrozenXID。 这个策略保留了原来的插入 XID 直到该数值不再令人感兴趣为止。 （实际上，大多数行版本将可能在还没有"冻结"之前就完成生存和消亡了）。 在这个策略下，任何表在两次 VACUUM 运行之间的最大的安全间隔是十亿次事务： 如果你等的时间更长，那么最后就可能就会有一条不够老的行版本在重新赋值时变成比二十亿次事务更老， 并因此重叠到了未来 — 也就是说，你失去它了。（当然，它在另外二十亿次事务之后会重新出现，不过那样也无济于事。）
因为上面的原因，我们需要周期性地运行 VACUUM， 所以很难有哪个表会到十亿次事务还没有清理过。但是，为了帮助管理员确保满足了这个要求， VACUUM 在系统表pg_database 里存储了事务 ID 统计。 尤其是一个数据库的 pg_database 行中的 datfrozenxid 字段在任何数据库范围的 VACUUM 操作（也就是没有声明任何表的VACUUM）之后将会被更新。 这个字段里存储的数值是该 VACUUM 命令使用的冻结终止的 XID。 系统保证在该数据库中所有比这个终止 XID 老的普通 XID 都被 FrozenXID 代替。 检查这个信息的一个便利的方法是执行下面的查询
SELECT datname, age(datfrozenxid) FROM pg_database;
age 字段用于测量从中止 XID 到当前事务的 XID 的数目。
使用了这种标准的冻结策略，对一个刚清理过的数据库而言， age 字段将从十亿处开始。当age到达二十亿次的时候， 数据库必须再次清理以避免事务标识重叠造成的问题。 我们建议的策略是至少每半个十亿次（5亿次）事务 VACUUM 一次数据库， 这样就可以保证足够的安全边界范围．为了帮助满足这条规则， 如果有任何 pg_database 记录显示出超过15亿次事务的 age， 那么每次数据库范围的VACUUM 都会自动发出一条警告，比如：
play=# VACUUM; WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb". VACUUM
如果忽略了上面这样的 VACUUM 信息，如果距离事务 ID 重叠小于 1 千万次， 那么 PostgreSQL 就会在每次事务开始前发出类似上面的警告。 如果这些警告还是被忽略了，那么系统将在距离重叠小于 1 百万次的时候关闭，并且拒绝执行任何新的事务：
play=# select 2+2; ERROR: database is shut down to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
这个 1 百万的事务安全边界留下来用于让管理员在不丢失数据的情况下进行恢复， 方法是手工执行所需要的 VACUUM 命令。不过，因为一旦进入了安全关闭模式，系统就不能再执行命令， 做这件事情的唯一的方法是停止 postmaster，使用一个单独运行的后端来执行 VACUUM。 关闭模式不会强制于独立运行的后端。参阅 postgres 手册也获取有关使用独立运行后端的细节。
带着 FREEZE 选项的 VACUUM 使用了更大胆的冻结策略： 如果行版本已经老得被所有打开的事务看做是良好的， 那么就都冻结．特别是如果在一个空闲的数据库上运行 VACUUM FREEZE，那么就保证该数据库中所有的行版本都被冻结。 因此，只要该数据库没有其它的变化，那么它就不需要后续的清理以避免事务 ID 重叠问题。 这个技巧被 initdb 用于准备 template0数据库。 我们也应该用这个方法对所有在 pg_database表里标记着 datallowconn = false的数据库进行初始化， 因为我们还没有任何便利的方法 VACUUM 一个你无法联接的数据库。
| Warning |
请注意，那些pg_database 记录里有 datallowconn = false 条件的数据库被认为是正确冻结住的； 自动警告和重叠保护关闭并不会处理这些数据库。 因此，在把数据库标记为 datallowconn = false 之前， 确保这样的数据库的正常冻结是你的责任。 |
从 PostgreSQL 8.1 开始，系统带有一个额外的可选服务进程， 叫做 autovacuum 守护进程，它的目的是自动执行 VACUUM 和 ANALYZE 命令。在打开这个选项之后，autovacuum 守护进程将周期性运行并且检查那些有大量插入，更新或者删除元组操作的表。 这些检查使用行级别的统计收集设施；因此，除非把 stats_row_level 和 stats_row_level 设置为 true，否则无法使用 autovacuum 守护。 还有，在为 superuser_reserved_connections 选择数值的时候，不要忘记给 autovacuum 进程保留一个槽位。
如果打开了 autovacuum 守护，那么它会每隔 autovacuum_naptime 秒钟运行一次，并且检查应该处理哪个数据库。 任何临近事务 ID 重叠的数据库都会被立即处理。这个时候，autovacuum 发出一个数据库范围的 VACUUM 调用，如果是模板数据库，则发出 VACUUM FREEZE， 然后终止。如果没有数据库复合这个标准，则选择被上次 autovacuum 处理时间最远的那个数据库。 这种情况下，该数据库里的表被检查，然后根据需要发出独立的 VACUUM 或者 ANALYZE 命令。
对于每个表，用两个条件来判断应该使用哪个操作。 如果上次 VACUUM 之后的过期元组的数量超过了"清理阈值（vacuum threshold）"， 那么就清理改表。清理阈值是定义为：
清理阈值 = 清理基本阈值 + 清理缩放系数 * 元组数 (vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples)
这里的清理基本阈值是 autovacuum_vacuum_threshold， 清理的缩放系数是 autovacuum_vacuum_scale_factor， 元组的数目是 失效的元组数目是从统计收集器里面获取的；这事一个半精确的计数，由每次 UPDATE 和 DELETE 操作更新。 （它只是半精确的是因为在重载下，有些信息可能会丢失。） 为了分析，使用了一个类似的条件：分析阈值，定义为
分析阈值 = 分析基本阈值 + 分析缩放系数 * 元组数目 (analyze threshold = analyze base threshold + analyze scale factor * number of tuples)
它会和上次 ANALYZE 插入，更新，或者删除的元组总数进行比较。
缺省的阈值和伸缩系数是从 postgresql.conf 里面取得的， 不过，我们可以以每个表独立设置的方式覆盖它，方法就是在系统表 pg_autovacuum 里输入记录。 如果 pg_autovacuum 里面存在对某个特定表的行，那么就使用它声明的设置； 否则使用全局设置。参阅 Section 17.9 获取有关全局设置的更多细节。
除了基本阈值和缩放系数之外，在 pg_autovacuum 里还有三个参数可以为每个表进行设置。 首先，pg_autovacuum.enabled 可以设置为 false， 让 autovacuum 守护进程完全忽略某个表。这种情况下，autovacuum 只有在为了避免事务 ID 重叠清理整个数据库的时候才会动那个表。另外两个参数，清理开销延迟 （pg_autovacuum.vac_cost_delay）和清理开销限制 （pg_autovacuum.vac_cost_limit）， 用于为 基于开销的清理延迟 特性设置表相关的数值。
如果在 pg_autovacuum 里任何数值设置为负数， 或者在 pg_autovacuum 里就根本没有出现特定表的数据行， 那么使用 postgresql.conf 里面对应的数值。
目前没有任何制作 pg_autovacuum 记录的支持， 只能手工向该系统表中 INSERT。这个特性将在以后的版本中改进， 并且这个系统表的定义也很有可能会改变。
| Caution |
目前，pg_autovacuum 的内容没有被工具 pg_dump 和 pg_dumpall 创建的转储所保存。 如果你想在转储/恢复的过程中保留它们，那么要确信你手工转储了这个系统表。 |