你好,
我发现实际数据库大小(在硬盘上并通过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。:我想,这是某种类型的数据库损坏......从这种情况中恢复的唯一方法是切换到热备数据库......
答案 0 :(得分:2)
当BobG写道时,LOB是一个非常有效的问题,因为当应用程序表(包含OID)的行被删除时,它们不会被删除。
VACUUM进程不会自动删除它们,只有您已经在它们上运行VACUUMLO。
Vacuumlo将从数据库中删除所有未引用的LOB。
示例电话:
vacuumlo -U postgres -W -v <database_name>
(我只包含-v使easlo更加冗长,以便你看到它删除了多少LOB)
在vacuumlo删除LOB后,您可以运行VACUUM FULL(或让自动真空过程运行)。
答案 1 :(得分:1)
你有未使用过的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())报告。)
答案 2 :(得分:1)
出现这种情况后,我们将数据库中的大量未使用数据转储并完全抽真空。
我有类似的经验:3GB数据库有大量动态数据,一个月左右达到20GB。 手动删除/清除有问题的表格不会生效。 然后我们做了最后的决定
VACUUM FULL ANALYZE
在整个数据库中...它的大小减少了一半。
耗时4小时,所以要小心。
答案 3 :(得分:0)
您的查询专门筛选出pg_toast表,这些表可能很大。看看是否摆脱schemaname != 'pg_toast'
让你得到更准确答案的地方。