Oracle自动统计信息不更新原因排查：深入GATHER_STATS_JOB工作原理

引言：数据库的“自动化保健医生”

在上一篇文章中，我们认识到统计信息是Oracle CBO做出明智决策的“生命线”。如果把数据库比作一个持续运转的复杂有机体，那么统计信息就是它的各项“健康指标”。一个关键问题随之而来：我们总不能每天手动“体检”吧？更重要的是，当这套自动化系统“罢工”，导致Oracle自动统计信息不更新时，我们该如何排查原因？

幸运的是，Oracle内置了一套强大的自动化“保健系统”。这个系统会定期巡检，找出那些“健康指标”已经过时的对象，并为它们进行更新。这个系统的核心就是 GATHER_STATS_JOB——一个在后台默默守护着数据库性能的英雄。

本篇，我们将扮演侦探，深入探索这位“自动化保健医生”的工作日常，并为您提供一份详细的Oracle自动统计信息不更新原因排查指南：

1. 它的工作时间表：维护窗口与AutoTask框架。
2. 它的诊断标准：10%变化阈值与DBA_TAB_MODIFICATIONS视图。
3. 它的工作日志：如何监控和查询任务的执行历史。
4. 核心排查点：为何它有时看起来“罢工”了？

（一）工作时间表：维护窗口 (Maintenance Windows)

这位“保健医生”并不会24小时不间断工作，以免影响数据库的正常业务（即“打扰病人休息”）。它的工作被严格限制在预设的“维护窗口”内。

Oracle数据库预定义了多个维护窗口，最常见的是：

• WEEKNIGHT_WINDOW：每个工作日晚上（通常是22:00到次日02:00）。
• WEEKEND_WINDOW：整个周末。

这些窗口由Oracle的自动任务框架 (AutoTask) 管理，GATHER_STATS_JOB 只是其中的一个任务。其他任务还包括段空间顾问 (Segment Advisor)、SQL优化顾问 (SQL Tuning Advisor) 等。

graph TD
    subgraph Oracle数据库
        A[预定义维护窗口<br/>(如: WEEKNIGHT_WINDOW)]
        A -- 在此时间段内触发 --> B{AutoTask 调度器}
        B -- 启动 --> C[自动SQL优化任务]
        B -- 启动 --> D[<b>自动统计信息收集<br/>(GATHER_STATS_JOB)</b>]
        B -- 启动 --> E[自动空间管理任务]
    end

如何检查“医生”是否在岗？

我们可以通过查询DBA_AUTOTASK_WINDOW_CLIENTS视图来确认统计信息收集任务在各个窗口是否处于开启状态。这是排查Oracle自动统计信息不更新问题的第一步。

SELECT 
    WINDOW_NAME, 
    AUTOTASK_STATUS, 
    OPTIMIZER_STATS 
FROM 
    DBA_AUTOTASK_WINDOW_CLIENTS;

查询结果解读：

• AUTOTASK_STATUS: ENABLED 表示整个窗口是开启的。
• OPTIMIZER_STATS: ENABLED 表示统计信息收集这个特定任务在该窗口是开启的。

如果OPTIMIZER_STATS显示为DISABLED，那么即使数据变化再大，GATHER_STATS_JOB 在那个窗口期也不会运行。

（二）诊断标准：10%变化阈值与DBA_TAB_MODIFICATIONS

“医生”在维护窗口开始工作后，如何判断哪个表的统计信息需要更新呢？它遵循一个简单而有效的核心规则，我们称之为“10%规则”。

Oracle会认为一个表的统计信息“失效 (Stale)”了，如果满足以下任一条件：

1. 自上次收集以来，表的数据变化量超过总行数的10%。
2. 表被执行过 TRUNCATE 操作。

这个“变化量”从何而来？Oracle使用了一个专门的监控视图：DBA_TAB_MODIFICATIONS。当你的表发生 INSERT, UPDATE, DELETE 操作时，Oracle并不会立即更新这个视图，而是先将变更计数记录在内存(SGA)中，然后由后台进程（如MMON）定期（默认每15分钟）将这些计数“刷新”到DBA_TAB_MODIFICATIONS表中。

工作流程图：

graph TD
    A[1. 对表 T_ORDERS 执行DML操作<br/>(INSERT, UPDATE, DELETE)] --> B{2. 变更计数记录在内存(SGA)};
    B --> C{3. 后台进程<br/>定期刷新};
    C --> D[4. 写入监控视图<br/>DBA_TAB_MODIFICATIONS];
    D --> E{5. GATHER_STATS_JOB<br/>在维护窗口运行};
    E -- 读取 --> D;
    E --> F{6. 计算变化率<br/>(INSERTS+UPDATES+DELETES)/NUM_ROWS};
    F --> G{7. > 10% ?};
    G -- YES --> H[8. 将该表加入<br/>待处理列表，收集统计信息];
    G -- NO --> I[9. 跳过该表];

举个例子：
假设我们有一个CUSTOMER表，上次收集统计信息时，它有 1,000,000 行。

• 上午：新增了 50,000 个客户 (50,000 INSERTS)。
• 下午：通过一个批处理更新了 60,000 个客户的地址 (60,000 UPDATES)。

在下次维护窗口到来时：

1. GATHER_STATS_JOB 检查 DBA_TAB_MODIFICATIONS，发现CUSTOMER表的总变化量是 50,000 + 60,000 = 110,000。
2. 它再查询表的总行数 NUM_ROWS 是 1,000,000。
3. 计算变化率：110,000 / 1,000,000 = 11%。
4. 因为 11% > 10%，所以GATHER_STATS_JOB 判定CUSTOMER表的统计信息已失效，并对其进行重新收集。

（三）排查起点：如何通过工作日志监控任务

作为DBA，我们不能只相信自动化。当怀疑Oracle自动统计信息不更新时，第一步就是检查它的工作日志。DBA_OPTSTAT_OPERATIONS视图就是GATHER_STATS_JOB的“工作日志”，记录了每一次任务的详细信息。

查询最近的自动统计信息收集任务：

SELECT 
    OPERATION, 
    TARGET, 
    START_TIME, 
    END_TIME, 
    STATUS, 
    NOTES
FROM 
    DBA_OPTSTAT_OPERATIONS
WHERE 
    OPERATION = 'gather_database_stats (auto)'
ORDER BY 
    START_TIME DESC
FETCH FIRST 10 ROWS ONLY;

查询某个特定表的收集历史：

SELECT 
    START_TIME, 
    END_TIME, 
    STATUS 
FROM 
    DBA_OPTSTAT_OPERATIONS
WHERE 
    TARGET = 'YOUR_SCHEMA.YOUR_TABLE_NAME'
ORDER BY 
    START_TIME DESC;

通过这个视图，你可以清晰地看到：

• 任务的起止时间 (START_TIME, END_TIME)。
• 任务是否成功完成 (STATUS = COMPLETED)。
• 处理了哪些对象 (TARGET)。

（四）核心环节：Oracle自动统计信息不更新的四大常见原因排查

理论上这套自动化机制非常完美，但在实际工作中，我们经常遇到某些表的统计信息很久没更新的情况。这正是进行Oracle自动统计信息不更新原因排查的关键所在。

1. “诊所”关门了 (任务被禁用)

   • 现象：整个数据库的统计信息都不再自动更新。
   • 排查：再次查询DBA_AUTOTASK_WINDOW_CLIENTS，确认OPTIMIZER_STATS是否被DISABLED。这是导致Oracle自动统计信息不更新最直接的原因。在某些高性能系统中，DBA可能会为避免额外负载而手动禁用它。

2. “病人”太多，时间不够 (维护窗口不足)

   • 现象：一些表的统计信息更新了，但另一些同样变化很大的表却没有。
   • 原因：维护窗口的时间是有限的。如果数据库中失效的对象非常多，或者某些大表收集起来非常耗时，GATHER_STATS_JOB可能在窗口关闭时还没来得及处理完所有任务。

3. 病历上写着“请勿打扰” (统计信息被锁定)

   • 现象：某个特定的表，无论数据怎么变，统计信息就是纹丝不动。
   • 原因：这正是本系列教程开篇案例中遇到的情况。DBA可以手动“锁定”一个表的统计信息，这相当于给这个表挂上了一个“请勿打扰”的牌子。一旦被锁定，自动收集任务会直接跳过它。这是最隐蔽也最常见的原因之一。

4. “护士”还没来得及更新病历 (监控数据未刷新)

   • 现象：你刚刚完成了一个巨大的数据加载，变化量远超10%，但GATHER_STATS_JOB在随后的窗口期并没有理会这张表。
   • 原因：如前所述，DBA_TAB_MODIFICATIONS的更新是异步的。可能你的数据加载完成了，但内存中的变更计数还没来得及刷新到磁盘上的监控表里，导致“医生”来检查时，看到的是一份“风平浪静”的旧报告。
   • 专业技巧：在这种情况下，可以在数据加载后手动执行EXEC DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;来强制刷新监控数据。