问题标签 [vacuum]

假设我定期将数据插入 SQLite 数据库，然后清除前 50% 的数据，但我不清理。

我现在对文件的前 50% 有类似归零的页面吗？如果我添加另一批数据，我会填写那些归零的页面吗？

手册中提到了数据的碎片化：

频繁的插入、更新和删除会导致数据库文件变得碎片化——单个表或索引的数据分散在数据库文件周围。

VACUUM 确保每个表和索引在很大程度上连续存储在数据库文件中。在某些情况下，VACUUM 还可以减少数据库中部分填充的页数，从而进一步减小数据库文件的大小。

但这并不表明这必然会导致性能下降。它主要暗示可以从吸尘器中节省的浪费空间。

严格连续页面中的数据是否有明显的性能提升？我可以期待一个包含大量碎片数据的数据库的“糟糕”性能吗？

我最初认为n_dead_tup和dead_tuple_count在 PostgreSQL 中给出相同的计数。但他们似乎不是。我不太明白到底是什么区别。

以下是我的观察：

1. 创建了一个包含 10k 行的表。
2. 更新了所有 10k 行。现在我有 10k 个死元组。

3. 我确实在桌子上吸满了吸尘器。正如预期的那样， dead_tuple_count 为 0。

但从ie仍然是 10002 n_dead_tup：pg_stat_all_tablespg_stat_get_dead_tuples('18466')

我多次重复此过程，并观察到n_dead_tup每次更新后更新的元组数量都会添加到统计信息中。

那么这里到底在VACUUM做什么呢？n_dead_tup和和有什么区别dead_tuple_count？

删除一些行后，我需要按顺序重新排序 rowid。桌子上的真空似乎很适合这种情况，但由于某些原因，它不会重新排序 rowid。

怎么了 ？

我的生产 PostgreSQL 面临一个问题，这与环绕问题有关，主要是因为 XID 范围超出限制。

这个 PostgreSQL 生产运行了 1 年多，有大量的事务和批量插入。

我在谷歌搜索了很多，但对这个严重错误感到困惑和害怕。现在我在任何吸尘或自动吸尘过程中都会遇到这个错误。我有大约 250 GB 的 Postgres 生产数据库，并且我还为所有表设置了 auto-vacuum。

我还检查了当前打开的事务，但 Postgres 会话中没有任何长时间运行的事务。

以上结果我使用以下查询：

请尽快提供您的输入，因为很快，这会给我的生产数据库带来问题。

我正在构建一个由 sqlite3 数据库支持的缓存。为了限制使用的磁盘空间，我会定期检查 db 文件的大小。如果超过了我的最大限制，我会批量删除最旧的项目并清理，重复直到大小低于最大值的 80%。

但是，文件大小在清理后并没有立即改变，我通常会在大小下降之前删除整个表。所有调用都返回SQLITE_OK，在任何地方都看不到任何错误。

产生类似的东西：

我如何知道真空何时完成，并且我可以再次检查文件大小？

sqlite 可以告诉我还是被阻止？我需要使用inotify还是什么？

VACUUM;在亚马逊红移上，每个数据库或每个当前模式都没有运行其他参数吗？

我问这个的原因是因为当 VACUUM 在一个模式上完成并且我更改默认模式并再次运行它时，它需要一个小时才能完成。

我只是想检查一下我对这两件事的理解是否正确。如果相关，我使用的是 Postgres 9.4。

我相信在从文件系统中回收空间时应该清理数据库，例如在删除表或大量行之后定期清理。

我认为应该在创建新索引之后或（定期）在从表中添加或删除大量行之后分析数据库，以便查询规划器可以进行良好的调用。

听起来对吗？

我正在使用 Postgres 9.4。

我刚满真空。我阅读了真空和真空满真空之间的区别，并考虑了很多是否应该运行真空或真空满。据我所知，我需要完全真空，我的数据库大小从 48 GB 下降到 24 GB。

真空充满后旧索引是否会过时，我是否需要运行重新索引？

我运行了“vacuum full verbose analyze”，所以分析是与 Vacuum full 一起完成的。

我在几个地方读到，对于 Postgres > 9.0，我不需要在真空满后重新索引，但我想确定是这种情况。

最近作为娱乐，我决定开发一个小项目来测试 SQlite 与库System.Data.SQLite提供的 EntityFramework 的好处。

该应用程序有一个数据同步过程，随着时间的推移变得过时，所以我决定从数据库中删除它们。正如预期的那样，删除表行并不会减少数据库的大小，所以我决定在其中运行命令 VACUUM。

在阅读了这篇优秀的博客SQLite、VACUUM 和 auto_vacuum 之后，我对一切都变得更加清晰，尤其是命令不能在事务中执行的事实。

就像 Code First 还不可用一样，我必须使用脚本在数据库中创建表，所以我在同一个地方执行命令。

我很惊讶收到以下异常：

附加信息：SQL 逻辑错误或缺少数据库。不能从事务中 VACUUM。

它让我认为 ExecuteSqlCommand 方法执行的所有命令都是在事务中处理的。我将EntityFramework 6.1.3 和System.Data.Sqlite 1.0.97.0 与 .NET Framework 4.5 一起使用。

问题

我错了吗？如果是这样，有没有办法执行命令？

我有一个卡住的“真空重新索引”操作，我想知道它需要这么长时间的原因可能是什么。

我最近更改了我的一个 Redshift 表的模式，方法是使用修改后的模式创建一个新表并使用“选择进入”深度复制数据（请参阅执行深度复制）。我的基本理解是，深拷贝表后，数据应该按照表的sort-keys进行排序。该表有一个交错的 4 列排序键。只是为了确保，在深度复制之后，我运行了“交错倾斜”查询（请参阅决定何时重新索引），所有列的结果都是 1.0，这意味着没有倾斜。

然后我在表上运行了“vacuum reindex”，这应该非常快，因为数据已经排序。然而，真空在 30 小时后仍在运行。在真空期间，我定期检查 svv_vacuum_progress 以检查真空操作状态。“排序”阶段在约 6 小时后完成，但现在“合并”阶段停留在“增量 23”>12 小时。

鉴于数据应该已经通过深拷贝操作进行排序，长时间真空操作的原因可能是什么？我是否也希望这些时间用于未来的真空操作？该表包含约 35 亿行，其总大小为约 200 GB。