问题标签 [vacuum]

我分别从 SAMSUNG Glaxy 和 Huawei C8812 获得了两个 mmssms.db 文件。运行“PRAGMA auto_vacuum;” 在这些文件上都会给出结果“1”。但是当我用十六进制编辑器打开这些文件时，我发现这些文件中的ptrmap页面有freelist页面记录。然后我再次从设备中提取这些文件，经过一些短信删除操作。我仍然可以在 ptrmap 页面中找到 freelist 页面记录。该文档说，当 auto-vacuum 模式为 1 或“full”时，freelist 页面被移动到数据库文件的末尾，并且数据库文件被截断以在每次事务提交时删除 freelist 页面。这些freelist页面记录和freelist页面是怎么保留的？

尝试优化我的应用程序数据库工作。

在数据库同步期间，我的应用程序在一个事务中运行一大包“删除”和“插入”命令。在事务“COMMIT”应用程序运行“VACUUM”命令之后。VACUUM 工作正常，但有时需要很多时间。所以我决定在并行线程中移动'VACUUM'执行。这里出了点问题。在其他线程中，我得到“数据库已锁定”。

我所做的：

1.COMMIT成功后关闭数据库。

2.使用“VACUUM”再次启动单独的打开和关闭数据库的方法。

在“COMMIT”的同一线程中，“VACUUM”工作正常，但在单独的线程中，相同的方法会出现“数据库已锁定”错误。我可以肯定地说，没有其他进程适用于封闭数据库，因为数据库同步是一个逻辑上独立的应用程序进程。

我做错了什么？

我的数据库中有一个非常大的表，我正在尝试为它创建一个序列列。我认为在创建此序列时该表正在被复制的问题，没有空间。首先，我的假设是否正确？其次，有没有一种方法可以创建一个序列并连续保持真空，或者有没有一种方法可以创建不会这样做的列？

在创建/删除/更新查询时出现错误：

错误：数据库不接受命令以避免数据库“mydb”中的环绕数据丢失提示：停止 postmaster 并使用独立后端清理该数据库。您可能还需要提交或回滚旧的准备好的事务。

因此，数据库被阻塞，只能执行 SELECT 查询。

数据库大小 350 GB。1 个表（my_table）有约 10 亿行。

系统：“x86_64-unknown-linux-gnu 上的 PostgreSQL 9.3.4，由 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4) 编译，64 位”

postgresq.conf 一些设置：

我不使用准备好的交易。但是每天使用基本存储过程（这意味着自动交易，对吗？）5000 万次。

目前，“autovacuum: VACUUM ANALYZE public.my_table ( to prevent wraparound)”正在执行，该查询活动几乎持续了 12 个小时。

据我了解，未抽空的死人的问题，对吧？

如何解决这个问题并在未来防止这种情况发生？请帮忙 ：）

故事结束（~一个月后） 现在我的大桌子被数千张桌子隔开。每个小桌子的吸尘速度都要快得多。Autovacuum 配置设置为更接近默认值。如果需要，我可以再次设置为更具侵略性，但到目前为止，拥有数十亿行的数据库运行良好。

所以，题目的问题应该不会再出现了。

ps 现在我将 Postgres-XL 视为数据可扩展性的下一步。

We have a very large table that was partitioned into monthly tables. We have no autovacuum parameters set in the postgresql.conf file, so it's on by default with default parameters.

The past months tables table_201404, table_201403 do not get written to or updated/deleted once they are passed, they are only read from for historical data. Why is it that we are noticing autovacuum processes running on these tables? Is it because they are part of a main partition and PostgreSQL is seeing those tables as one?

We are toying with the idea of setting autovacuum_enabled to off for these past tables, but I wanted to consult the wisdom of Stackoverflow first.

Thanks all...

我找到了一个查询来查看真空吸尘器何时运行，但不是当前正在运行的。（http://heatware.net/databases/postgres-tables-auto-vacuum-analyze/）

是否有查询来完成此操作？我知道我可以点击 pg_stat_activity，但有些真空吸尘器没有表名，而是有 pg_toast.pg_toast_3621837，所以这不会 100% 起作用。

Reading the Amazon Redshift documentatoin I ran a VACUUM on a certain 400GB table which has never been vacuumed before, in attempt to improve query performance. Unfortunately, the VACUUM has caused the table to grow to 1.7TB (!!) and has brought the Redshift's disk usage to 100%. I then tried to stop the VACUUM by running a CANCEL query in the super user queue (you enter it by running "set query_group='superuser';") but although the query didn't raise an error, this had no effect on the vaccum query which keeps running.

What can I do?

我对 PostgreSQL 比对 MySQL 更熟悉。曾经在 PostgreSQL 数据库中遇到过环绕 ID 失败，然后了解了在数据库中进行清理的重要性。实际上，这是一项需要处理的大量开销工作（而且它是使用旧版本 7.4.3 进行的，几个月前更新了 autovacuum）。在比较 MySQL 和 PostgreSQL 时，假设 MySQL 不必处理像 PostgreSQL 中的真空这样的开销。这个假设正确吗？

另外，与 PostgreSQL 相比，为什么 MySQL Dbs 不需要真空？MySQL dbs 是否存在其他类似于 Vacuum 的优化替代方案？

使用postgresql-9.2，此时我正在使用以下查询查找表：dead_tuples

这将返回表名，然后我将运行：

这是一个好方法还是我需要改变它，如果是，请给我一些方法

谢谢

当我VACUUM在桌子上运行时，它会给出如下输出：

是什么CPU 35.06s/175.00u sec意思？
VACUUM在我的数据库中的单个表上需要很长时间，理解这一点对我来说很重要。