TaoToken 配 DBMS_STATS：DBA 统计信息准备性脚本骨架与验证-平芜编程栈

1. 统计信息准备性为什么总在半夜翻车

统计信息准备性这件事，说白了就是让优化器在生成执行计划时，手里拿到的数据分布是"新鲜"的。我见过太多案例：白天业务跑得好好的，凌晨一批数据加载完，第二天早上核心查询突然走错执行计划，全表扫描替代了索引扫描，CPU 直接打满。排查半天，最后发现是DBA_TAB_STATISTICS里STALE_STATS = 'YES'，或者LAST_ANALYZED还停留在上周。

Oracle 的DBMS_STATS本身能力很全，问题从来不是"能不能收集"，而是"怎么保证该收集的都收集了、收集的粒度合理、收集完能验证效果"。手工敲GATHER_TABLE_STATS只能救急，真正要落地必须脚本化：先识别陈旧对象，再按对象大小决定采样比例和并行度，最后跑完做前后对比。

这篇面向 Oracle DBA，给出一套可复制的脚本骨架，同时演示怎么通过 TaoToken 的统一 Key/API 通道接入 AI 工具，让它帮你生成、审查、补全这些 PL/SQL 脚本，减少手写游标和参数拼装的出错概率。适合已经在维护 Oracle 库、需要把统计信息收集从"人肉运维"变成"可重复流程"的同学。

核心检索词先摆出来：统计信息、DBA、DBMS_STATS、脚本。这四个词贯穿全文，后面每一步都围绕它们展开。

2. TaoToken 前置：统一 Key 与 API 通道准备

TaoToken 在这里的角色是"统一入口"——你不需要为每个 AI 工具单独配一套鉴权和地址，而是拿一个 Key、走一个 API 通道，就能让脚本生成、代码审查、文档查询这些能力都接进来。对 DBA 来说，最实际的价值是：把"写一段识别陈旧表的游标"这种重复劳动交给 AI 起草，你只做审查和参数校准。

官网入口在这里：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api （这个不加 UTM）。注意 API 地址和官网地址是两个，配置时别混。

你需要先拿到 API Key。进入控制台的 API Keys 页面创建：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。创建后复制那串 Key，后面写进配置文件。如果你更想先在网页里对话验证模型输出质量，可以用模型对话页：https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。

注意：Key 只存在你自己的配置文件和本地环境变量里，不要写进要提交到 Git 的脚本目录。DBA 的脚本仓库往往多人可见，这点必须守住。

接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，遇到请求格式、字段名不确定时以文档为准。长期做编码和 Agent 类任务的话，Coding Plan 页 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 可以了解套餐形态，这里不展开价格，按自己用量评估即可。

3. 可复制配置：config.toml 与 settings.json 骨架

不同 AI 工具读的配置文件格式不一样，有的吃 TOML，有的吃 JSON。下面两份骨架你按工具要求二选一或都留一份。关键字段就三个：base_url、api_key、model。base_url 统一指向 TaoToken 的 API 通道。

先看config.toml：

# config.toml —— 供支持 TOML 配置的 AI 编码工具使用 # 作用：把脚本生成/审查请求统一走 TaoToken API 通道 [provider] name = "taotoken" base_url = "https://taotoken.net/api" api_key = "sk-你的Key粘贴到这里" # 也可用环境变量覆盖，避免明文：TAOTOKEN_API_KEY [model] # 按你实际可用的模型名填写，长上下文模型更适合整段 PL/SQL 审查 name = "your-model-name" max_tokens = 8192 temperature = 0.2 # 脚本生成场景调低，减少随意发挥 [request] timeout_seconds = 120 retry = 2

再看settings.json：

{ "provider": { "name": "taotoken", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的Key粘贴到这里" }, "model": { "name": "your-model-name", "maxTokens": 8192, "temperature": 0.2 }, "request": { "timeoutSeconds": 120, "retry": 2 } }

两个文件里的your-model-name都要换成你账号下实际可用的模型标识，别照抄占位符。temperature设 0.2 是刻意的：生成 SQL/PLSQL 时我们要的是稳定、可复现，不是创意。max_tokens给到 8192 是因为一段带游标和异常处理的统计信息脚本很容易超过 2000 token，留足空间避免被截断。

如果你用环境变量管理密钥，把配置文件里的 api_key 留空，运行时注入：

export TAOTOKEN_API_KEY="sk-你的Key"

这样配置文件可以安全地放进版本库，密钥走环境。DBA 团队协作时推荐这种。

4. 脚本骨架：识别陈旧对象并按大小分级收集

现在进入正题。统计信息准备性的核心逻辑分三步：刷新监控信息、找出陈旧或从未分析过的对象、按对象大小决定采样比例和并行度。下面这段 PL/SQL 骨架可以直接改 schema 名后使用。

-- 统计信息准备性收集骨架 -- 用途：识别 STALE 或未分析的表，按大小分级采样后收集 -- 执行前请把 :SCHEMA_NAME 替换为实际 schema DECLARE -- 游标：找出需要收集统计信息的表，并计算采样比例 CURSOR stale_table IS SELECT owner, segment_name, CASE WHEN size_gb < 0.5 THEN 30 WHEN size_gb >= 0.5 AND size_gb < 1 THEN 20 WHEN size_gb >= 1 AND size_gb < 5 THEN 10 WHEN size_gb >= 5 AND size_gb < 10 THEN 5 ELSE 1 END AS percent, 8 AS degree FROM ( SELECT s.owner, s.segment_name, SUM(s.bytes / 1024 / 1024 / 1024) AS size_gb FROM dba_segments s WHERE s.owner = :SCHEMA_NAME AND s.segment_name IN ( SELECT DISTINCT t.table_name FROM dba_tab_statistics t WHERE t.owner = :SCHEMA_NAME AND (t.last_analyzed IS NULL OR t.stale_stats = 'YES') ) GROUP BY s.owner, s.segment_name ); BEGIN -- 第一步：把内存中的监控信息刷到数据字典，否则 stale_stats 判断不准 DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO; -- 第二步：逐表收集，采样比例和并行度来自游标计算 FOR rec IN stale_table LOOP DBMS_STATS.GATHER_TABLE_STATS( ownname => rec.owner, tabname => rec.segment_name, estimate_percent => rec.percent, method_opt => 'for all columns size repeat', degree => rec.degree, granularity => 'ALL', cascade => TRUE ); END LOOP; COMMIT; END; /

几个参数值得单独说清楚，这也是 AI 生成脚本时最容易写错的地方：

FLUSH_DATABASE_MONITORING_INFO必须放在游标打开之前。Oracle 的STALE_STATS依赖 SMON 周期性刷新，默认有延迟。不手动 flush，你查到的陈旧状态可能是几十分钟前的，会漏掉刚变脏的表。

estimate_percent按大小分级是经验做法：小表全采（30% 对小于 0.5G 的表基本够），大表降采样省时间。但要注意，如果某张大表数据分布极度倾斜，1% 可能采不到关键值，这时候需要单独对该表提高比例或加method_opt的直方图设置。

method_opt => 'for all columns size repeat'表示沿用已有的直方图设置，不新增也不删除。这比size auto更可控，避免优化器自动给一堆列建直方图拖慢收集。

cascade => TRUE会连带收集索引统计信息。如果你的库索引很多，这一步耗时明显，但跳过它索引统计信息就会陈旧，执行计划照样出错。

degree => 8是并行度。生产库上别盲目调高，并行收集会吃 CPU 和 IO，建议在业务低峰执行，或者用DBMS_SCHEDULER挂到凌晨窗口。

5. 验证请求与成功结果：执行前后对比

脚本跑完不等于万事大吉，必须验证。验证分两层：一是确认收集动作真的生效，二是确认统计信息质量达标。

先看执行前的基线，把陈旧对象数量记下来：

-- 执行前：统计陈旧/未分析对象数量 SELECT COUNT(*) AS stale_count FROM dba_tab_statistics WHERE owner = :SCHEMA_NAME AND (last_analyzed IS NULL OR stale_stats = 'YES');

执行脚本后，再跑一次同样的查询，stale_count应该显著下降甚至归零。如果还有残留，说明游标没覆盖到——常见原因是这些对象不是 TABLE 类型（比如分区表要查dba_tab_statistics的partition_name维度），或者 segment 不在dba_segments里。

再看具体表的分析时间是否更新：

-- 执行后：抽查若干表的最后分析时间 SELECT table_name, last_analyzed, num_rows, sample_size, stale_stats FROM dba_tab_statistics WHERE owner = :SCHEMA_NAME AND table_name IN ('T_ORDER', 'T_USER', 'T_LOG') ORDER BY last_analyzed DESC;

last_analyzed应该是刚才的时间，sample_size反映实际采样行数，stale_stats应变为NO。如果num_rows和实际差距很大，说明采样比例偏低，需要针对性调整。

还可以对比收集前后的执行计划，确认优化器行为改善：

-- 收集后重新解析，观察计划是否变化 EXPLAIN PLAN FOR SELECT /*+ 你的业务查询 */ COUNT(*) FROM t_order WHERE create_time > SYSDATE - 1; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

这一步是最终目的：统计信息准备性做得好不好，不看脚本跑没跑，看执行计划稳不稳。

6. 本篇常见错排查

报错 ORA-20001 / 权限不足：GATHER_TABLE_STATS需要ANALYZE ANY或对象属主权限。用 DBA 账号跑没问题，普通账号要显式授权。AI 生成的脚本常忽略权限前提，执行前先确认。

游标查不到任何表：先单独跑游标里的 SELECT，看dba_tab_statistics是否有数据。如果stale_stats全是 NULL，多半是没执行FLUSH_DATABASE_MONITORING_INFO，或者表的监控没开（ALTER TABLE ... MONITORING）。

收集后 stale_stats 仍是 YES：检查是否有 DML 在收集过程中继续写入。统计信息收集不是事务隔离的，边写边收会导致状态回退。建议在低峰执行，或对关键表加短暂锁定。

采样比例导致 num_rows 偏差大：小表用 30% 一般够，但如果表只有几百行，直接estimate_percent => 100更准。大表 1% 采样在数据倾斜时风险高，可对特定表单独指定。

并行度太高拖垮库：degree => 8在多表循环时会叠加。如果一次要收集几百张表，考虑把 degree 降到 4，或者分批执行。用DBMS_SCHEDULER控制并发窗口更稳。

AI 生成的脚本参数名拼错：ownname、tabname、estimate_percent这些是固定参数名，AI 偶尔会写成owner_name之类。审查时重点核对参数名和DBMS_STATS官方签名是否一致。

7. 把 AI 工具接进日常统计信息运维

回到工具链。上面这套脚本骨架，你可以让 AI 帮你做三件事：一是根据你的 schema 和表清单生成定制版游标；二是审查已有脚本的参数合理性；三是把验证 SQL 补全成定时任务。

接入方式就是前面配好的 Key 和 API 通道。如果你主要做脚本生成和审查这类编码任务，走 Coding Plan 更合适：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。如果只是想快速验证某段 PL/SQL 逻辑对不对，用模型对话页更轻：https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。Key 管理和接入细节看 API Keys 页和文档：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 、https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。

一个实际用法：把dba_tab_statistics的查询结果导出成 CSV，连同你的收集脚本一起丢给 AI，让它对比哪些表被漏掉、哪些采样比例不合理。这比人眼扫几百行结果快得多。但记住，AI 给的是建议，最终参数要你在测试库验证过再上生产。

统计信息准备性这件事没有一劳永逸的脚本，表在长、数据在变、业务查询在调整。脚本骨架给你的是可重复的流程，AI 工具给你的是起草和审查的效率，两者结合，DBA 的凌晨电话会少很多。