主页 / dba / 问题 / 323452
Accepted
EM0
Asked: 2023-02-14 01:25:48 +0800 CST

对于大多数表，pg_stat_user_tables 有 n_live_tup = 0 和 last_autonalyze = null - 为什么表没有得到分析？

  • 772

类似于PostgreSQL 中 autovacuum_count、last_autovacuum 和 autoanalyze_count 的 NULL 和零的可能含义是什么？除了在我的情况下它是 PostgreSQL 15.1 并且没有删除 - 仅插入数据。

我有一个包含一些分区表和一些非分区表的数据库。有些partition有上亿行，但是n_live_tup对他们来说是0，vacuum_count,autovacuum_count,analyze_count,autoanalyze_count都是0。

只有最近创建的 2 个表（两个分区）分别具有 autoanalyze_count = 1 和 4，并且 n_live_tup > 0。但是，还有一些 n_live_tup > 0 的其他表（尽管没有对它们运行分析）。

        select relname, n_live_tup, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze, vacuum_count, autovacuum_count, analyze_count, autoanalyze_count
        from pg_catalog.pg_stat_user_tables
        where schemaname = 'myschema'

结果

请注意，event_59 的 n_live_tup 在这里大错特错，该表实际上有 >11 亿行（这是最大的行）。

我尝试log_autovacuum_min_duration = 0按照链接问题中的建议进行设置，但到目前为止似乎没有记录任何内容。

为什么我的表没有得到分析？

编辑 1：现在连这些表的统计数据都被重置了：

更新的统计数据

服务器没有崩溃，因为 -pg_postmaster_start_time()返回2023-02-13 17:02:32.365095+00（那是我重新启动它的时候）。正如您在第一个屏幕截图中看到的那样，autoanalyze 很快就运行了。日志显示它在 20:10:18 再次运行，但尽管如此，所有分析/真空计数都为 0，并且 n_live_tup 已减少。

我手动运行analyze event_241并且 n_live_tup 变得准确。之后我重新启动了 PG，但没有重置计数，所以我不确定为什么它会在一夜之间重置。

编辑 2：当 pg_dump 备份运行时，服务器每晚都会崩溃，但显然没有重新启动 postmaster 进程，因为pg_postmaster_start_time()一直返回相同的值。我可以通过 pg_dumping 一个特定的数据库（不是这篇文章所讨论的数据库）轻松重现崩溃。

2023-02-17 09:04:16.607 UTC [27083] postgres@problematic_database LOG:  connection authorized: user=postgres database=problematic_database application_name=pg_dump
2023-02-17 09:04:16.609 UTC [27083] postgres@problematic_database PANIC:  could not open critical system index 2662
2023-02-17 09:04:16.610 UTC [11922] LOG:  server process (PID 27083) was terminated by signal 6: Aborted
2023-02-17 09:04:16.610 UTC [11922] LOG:  terminating any other active server processes
2023-02-17 09:04:16.645 UTC [11922] LOG:  all server processes terminated; reinitializing
2023-02-17 09:04:17.176 UTC [27945] LOG:  database system was interrupted; last known up at 2023-02-17 09:03:24 UTC

修复崩溃是一个单独的主题，但对于这个问题，我想知道：

  1. 监视这种情况发生的最佳方法是什么？我们可以扫描日志中的关键字，但最好直接检查正在重置的统计信息，因为这会捕获此错误以及其他错误。仅仅是在至少一张表上手动运行分析然后定期轮询analyze_count = 0还是有更好的方法？
  2. analyze如果我们确实检测到统计数据被重置（由于崩溃），那么手动重新填充统计数据似乎是个好主意，对吧？但是，为什么 PG 在从崩溃中恢复后不会自动执行此操作呢？
  3. 或者无论如何定期运行 ANALYZE 是个好主意，比如说，每周甚至每晚？（目前在这个数据库上需要大约 200 秒——比备份时间少得多！）
postgresql

1 个回答

  1. Best Answer

    有几种可能的解释：

    • 崩溃重置统计数据

    • 有人打电话pg_stat_reset()或相关功能重置统计信息

    • 数据库已升级，之后pg_upgrade没有人运行ANALYZE

    要检查上次为数据库重置统计信息的时间，请运行

    SELECT pg_stat_get_db_stat_reset_time(oid)
FROM pg_database
WHERE datname = current_database();

    如果为 NULL，则统计数据从未被显式重置。

    您的进一步调查表明您有目录数据损坏，这每天都会使数据库崩溃。如果您有良好的备份，请恢复它。否则，立即关闭数据库并对所有文件执行冷备份。您可以尝试通过使用选项启动 PostgreSQL 来解决问题-P，然后尝试以超级用户身份重建索引：

    REINDEX INDEX pg_catalog.pg_class_oid_index;

    目标是使数据库进入可以成功转储的状态。然后将其恢复到良好硬件上新创建的集群。不要继续使用这个集群，即使它看起来再次正常。

    • 1

相关问题