我需要支持收缩数据输入率为每秒 1 个条目（约 300KB）的数据库。数据库文件可以达到3GB。当前数据库没有自动清理功能。数据库文件空间超过一定限制（比如 3GB）是最坏的情况。

我目前的策略是删除最旧的数据（通过集群主键），然后到 CHECKPOINT DEFRAG。这似乎不可靠，VACUUM 或 DEFRAG 可能需要很长时间。我不想命名数据库名称，但我愿意接受建议。

我想知道还有哪些其他策略可以可靠地（几乎没有停机时间，O(1) 操作速度）保留磁盘空间。

编辑：需要关系数据库作为报告和 SQL 数据提取是必要的。

固定大小的循环缓冲区——确切地说——我需要在关系世界中复制它，使用占用空间小的数据库和快速的“循环”行为（即快速插入）

我们在 AWS RDS 平台上运行 PostgreSQL 9.3。每天凌晨 1 点，我们一直在执行一项全球性VACUUM ANALYZE工作。

昨天我们观察到性能严重下降，事实证明VACUUM ANALYZE，过去 5 天我们有 5 个进程卡住了。在同一时间段内，磁盘利用率增加了 45 GB。

我用它杀死了它，pg_terminate_backend但这并没有太大影响。这些进程看起来已经死了，但性能仍然严重下降。由于我们使用的是 AWS RDS，因此我们通过故障转移执行了重启，并且性能立即得到了显着提升。

今天早上我检查，发现VACUUM ANALYZE又卡了5个小时。我杀了它，但我怀疑它还在某个地方。

经过进一步调查，我确认auto_vacuum已正确启用，这意味着我们不需要手动运行，VACUUM但我们可能需要ANALYZE在部分或全部表上运行。

在我的研究中，我发现了这篇文章：http ://rhaas.blogspot.com/2011/03/troubleshooting-stuck-vacuums.html和http://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT。

最后，我有以下问题：

1. 在启用 auto_vacuum 的情况下不运行手动 VACUUM 是否正确？
2. 如何监控 auto_vacuum 的进度和性能？我怎么知道它没有和手动 VACUUM 卡在同一个地方？
3. 我还需要定期运行 ANALYZE 吗？
4. 有没有办法启用自动分析，类似于 auto_vacuum ？

你好 Slack Overflowvians。

所以我遇到了这个运行 8.3.11 的 PostgreSQL 服务器（是的，我知道），它处于锁定状态：

autovacuum=on通常自动清理守护进程（但是由于这些损坏的数据库对象，该数据库的 XID 从未被重置。

以下是使用管理员用户在单用户模式下运行服务器时的输出片段：

请注意，此服务器上的年龄远高于vacuum_freeze_min_age（成功 VACUUM 后设置的值），因此它发出上述原始错误的原因。以上是在运行之后VACUUM FULL；所有其他表都很好。

因此，当我们查看磁盘时（使用上面每个表的 pg_class.relfilenode 值），toast 表的文件丢失了：

当我们在磁盘上查看 toast 的索引时

然后我们试图找到与坏 toast 记录相关的表：

上面的每个表格都有 0 个结果！没有用于VACUUM重置这些关系的 XID 的命令的表。

当我们检查 pg_depend 表并发现这些 TOAST 表没有引用时：

问题

1. 你能从 pg_class 表中删除坏的 TOAST 表和 TOAST 表索引吗（例如DELETE FROM pg_class where oid=2421459）
2. 我们还需要从其他表中删除关系吗？
3. 我们可以只创建一个临时表并将其链接到 TOAST 的索引的 oid 吗？

上面 #3 的示例：

编辑：

select txid_current()是 3094769499，所以这些表很久以前就损坏了。我们不需要恢复数据。我们在 Linux 2.6.18-238.el5 上运行 ext4 文件系统。我们检查了相关lost+found/目录，文件不存在。

如何在 PostgreSQL 中启用 autovacuum？我了解目的，我只是找不到有关如何启用它的简单答案。

我有一个：

VACUUM 不能在事务块内运行

Redshift 中的 SQLWorkbenchJ 出错，但在此之前我已经提交了所有事务。

我有大约 1000 万行的表，id列是primary key.

然后我删除所有行where id > 10。表中只剩下 10 行。

现在，当我运行查询时SELECT id FROM tablename，执行时间大约为 1.2 - 1.5 秒。
但SELECT id FROM tablename where id = x只需要 10 - 11 毫秒。

为什么SELECT只有 10 行的第一个这么慢？

我最近一直收到警告消息：

警告：必须在 xxxx 事务中清理数据库“mydb”提示：为避免数据库关闭，请在“mydb”中执行完整数据库 VACUUM。

所以我尝试了 VACUUM、VACUUM FULL 和 VACUUM FULL FREEZE，但所有选项都以相同的错误结束：

错误：无法打开文件“base/19069/26252”：没有这样的文件或目录

那么……我该怎么办？我现在很绝望，我不希望数据库关闭！

在 PostgreSQL 中，有必要定期进行清理，以防止由于事务 ID 环绕而导致非常旧的数据丢失。我担心如果不定期清理 SQLite3 数据库，数据丢失也可能是一个问题。

此外，SQLite3 数据库所经历的工作负载是否重要？我目前正在考虑在几个场景中使用 SQLite3，包括：

• 作为程序的文件格式，人们可以在其中共享文件并在不同的机器上使用它们
• 存储应用程序设置
• 为可能每秒记录多次的应用程序存储日志（可能每小时执行一次对最近数据的查询）

更新和删除的频率也很重要吗？

我正在将 Amazon Product Api 集成到我的 rails 应用程序中。我正在使用真空宝石进行这种集成。有两个主要页面。我正在通过此代码获取产品。

它提供了十种具有匹配要求的产品。但是，当我想转到我的应用程序中产品的详细信息页面并在我的应用程序中显示其各自的详细信息时，我需要 vaccum 文档中给出的该产品的 ItemId。

但我无法获取此 ID。当我写ItemId或ItemIds在响应组中时，我不明白这一点，尽管这是可以根据 Amazon Docs 写入 ResponseGroup 的属性。我需要该 ItemId 来执行项目循环操作，以便分别获得与该产品相关的评论和其他详细信息。

Android Auto Backup目前的限制为 25 MB。

在备份管理器运行备份作业之前，有什么方法可以对数据库执行 SQLite真空操作？

这样做的原因是为了让尽可能多的用户保持在配额内。