Question

你好，

我发现实际数据库大小（在硬盘上并通过pg_database_size()调用显示）和大小（通过总计pg_total_relation_size()检索的总关系大小计算得出）之间存在很大差异。

第一个是62G，最后一个是16G（右边是最大表中已删除数据的差异）

这是一个简化的查询，可以显示我的系统上的差异：

select current_database(),
       pg_size_pretty( sum(total_relation_raw_size)::bigint ) as calculated_database_size,
       pg_size_pretty( pg_database_size(current_database()) ) as database_size   
  from (select pg_total_relation_size(relid) as total_relation_raw_size
          from pg_stat_all_tables -- this includes also system tables shared between databases
         where schemaname != 'pg_toast' 
       ) as stats;

似乎有一些悬空数据。出现这种情况后，我们将数据库中的大量未使用数据转储并完全抽空。

P.S。：我想，这是某种类型的数据库损坏......从这种情况中恢复的唯一方法是切换到热备数据库......

Answer 1

当BobG写道时，LOB是一个非常有效的问题，因为当应用程序表（包含OID）的行被删除时，它们不会被删除。

VACUUM进程不会自动删除它们，只有您已经在它们上运行VACUUMLO。

Vacuumlo将从数据库中删除所有未引用的LOB。

示例电话：

vacuumlo -U postgres -W -v <database_name>

（我只包含-v使easlo更加冗长，以便你看到它删除了多少LOB）

在vacuumlo删除LOB后，您可以运行VACUUM FULL（或让自动真空过程运行）。

Answer 2

你有未使用过的LOB吗？

如果你有这样的事情：

CREATE TABLE bigobjects (
    id BIGINT NOT NULL PRIMARY KEY,
    filename VARCHAR(255) NOT NULL,
    filecontents OID NOT NULL
);

接下来是：

\lo_import '/tmp/bigfile'
11357
INSERT INTO bigobjects VALUES (1, 'bigfile', 11357);
TRUNCATE TABLE bigobjects;

你仍然会在数据库中拥有LOB（id 11357）。

您可以检查数据库中所有大对象的pg_catalog.pg_largeobject系统目录表（推荐SELECT DISTINCT loid FROM pg_catalog.pg_largeobject，除非您希望将所有LOB数据视为八进制。）

如果清理掉所有未使用的LOB并完成VACUUM，您应该会看到存储量大幅减少。我刚刚在我一直使用的个人开发数据库上尝试了这个，并且看到大小从200MB减少到10MB（由pg_database_size（current_database（））报告。）

Answer 3

出现这种情况后，我们将数据库中的大量未使用数据转储并完全抽真空。

我有类似的经验：3GB数据库有大量动态数据，一个月左右达到20GB。手动删除/清除有问题的表格不会生效。然后我们做了最后的决定

VACUUM FULL ANALYZE

在整个数据库中...它的大小减少了一半。

耗时4小时，所以要小心。

Answer 4

您的查询专门筛选出pg_toast表，这些表可能很大。看看是否摆脱schemaname != 'pg_toast'让你得到更准确答案的地方。

PostgreSQL数据库大小（表空间大小）远大于计算的关系总和

4 个答案: