我试图重新启动postgresql数据库已停止/已关闭并需要一个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'和数据目录是正确的.
在推荐时,问题中引用的"how-to-vacuum-postgresql"页面提供了一些非常糟糕的建议VACUUM FULL.所需要的只是一个完整的数据库真空,它只是VACUUM作为数据库超级用户对整个数据库的运行(即,您没有指定任何表名).
A VACUUM FULL基于版本的工作方式不同,但它消除了数据库保存的堆文件中的所有空间,以便快速重用,并将其发布到操作系统.这可能比恢复到可用数据库所需的最小数量要慢得多.并且由于在VACUUM FULL需要OS调用之后的任何插入或更新都会重新为数据库分配空间,因此除非您的数据库有很多膨胀,否则它会导致之后执行速度变慢.(虽然,如果你关闭autovacuum,它可能会形成一个可怕的形状,但你可能想先重新站起来,然后再解决这个问题.)
VACUUM FULL版本9.0之前的另一个问题是,虽然它消除了表的堆文件中的膨胀,但它往往会增加其索引文件中的膨胀,有时会显着增加.如果您发出a VACUUM FULL,通常应该使用a REINDEX来跟踪它以使索引恢复良好状态.
问题中引用的页面也没有注意到PostgreSQL文档中提供的建议,请访问http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND以使用单用户模式:
由于系统一旦进入安全关闭模式就不会执行命令,唯一的方法是停止服务器并使用单用户后端执行VACUUM.单用户后端不强制执行关闭模式.有关使用单用户后端的详细信息,请参阅postgres参考页面.
正如其他人所提到的 - 几乎没有用例关闭autovacuum是有益的.在大型表上使用显式真空吸附来补充 autovacuum活动可能很有用,或者您可能想要调整autovacuum配置,但实际上 - 不要将其关闭,否则您将看到使得性能下降的膨胀并且您将遇到事务ID周期性问题.当autovacuum执行维护时发现性能受损的人有时会有一种本能,使其在触发时不那么积极,但这通常会适得其反.通常最好调整autovacuum成本限制参数来调整工作速度,而不是忽略需要维护的表.
这似乎是PostgreSQL中的一个问题,因为根据9.0和8.3的文档,它应该适用于那些版本但不适用.
但是,使用--single开关可以使它工作:
postgres --single -D [path-to-data-dir] [db-name] < /tmp/fix.sql