2

我正在尝试重新启动一个已停止/已关闭并需要VACUUM.

http://suwala.eu/blog/2010/10/09/how-to-vacuum-postgresql/

按照上述命令序列，我似乎无法正确执行最后一行。

$ postgres -D /var/lib/pgsql/data YOUR_DATABASE_NAME < /tmp/fix.sql

这给了我一个错误，上面写着

postgres: invalid argument: "YOUR_DATABASE_NAME"
Try "postgres --help" for more information.

知道为什么吗？

澄清

我在服务器上使用的“YOUR_DATABASE_NAME”和数据目录是正确的。

4

2 回答 2

7

问题中引用的“how-to-vacuum-postgresql”页面在推荐时给出了一些非常糟糕的建议VACUUM FULL。所需要的只是一个完整的数据库真空，它只是VACUUM作为数据库超级用户对整个数据库运行（即，您不指定任何表名）。

A 的VACUUM FULL工作方式因版本而异，但它消除了数据库为快速重用而保存的堆文件中的所有空间，并将其释放到操作系统。这可能比返回可用数据库所需的最小值要慢几个数量级。VACUUM FULL并且由于在需要操作系统调用以重新分配数据库空间之后的任何插入或更新，它可能会导致之后的执行速度变慢，除非您的数据库有很多膨胀。（虽然，如果你关闭了 autovacuum，它的状态可能很糟糕，但你可能想先重新站起来，然后再解决。）

9.0 之前版本的另一个问题VACUUM FULL是，虽然它消除了表的堆文件中的膨胀，但它往往会增加其索引文件中的膨胀，有时甚至是显着的。如果您发出 a VACUUM FULL，您通常应该在它后面加上 aREINDEX以使索引恢复良好状态。

问题中引用的页面也没有注意 PostgreSQL 文档中给出的建议，网址为http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPROUND使用单用户模式：

由于系统一旦进入安全关闭模式就不会执行命令，唯一的方法是停止服务器并使用单用户后端执行 VACUUM。单用户后端不强制执行关闭模式。有关使用单用户后端的详细信息，请参阅 postgres 参考页面。

正如其他人所提到的 - 几乎没有关闭 autovacuum 有益的用例。在大型表上通过显式清理来补充自动清理活动可能很有用，或者您可能想要调整自动清理配置，但实际上 - 不要关闭它，否则您会看到膨胀，这会降低性能并且您会遇到事务定期出现 ID 环绕问题。在 autovacuum 执行维护时注意到性能下降的人有时会本能地降低触发时的积极性，但这通常会适得其反。通常最好调整 autovacuum 成本限制参数以加快工作速度，而不是让它忽略需要维护的表。

于 2012-04-08T12:35:58.547 回答
6

这似乎是 PostgreSQL 中的一个问题，根据9.0和8.3的文档，它应该适用于这些版本，但不能。

但是，使用 --single 开关使其工作：

postgres --single -D [path-to-data-dir] [db-name] < /tmp/fix.sql
于 2012-04-08T05:44:52.337 回答