8.3 自治数据库与AI特性

8.3 自治数据库与AI特性

本节摘要：自治不是营销词，是一组分层的自动化能力：运维型（补丁、备份、故障转移）已经可靠，优化型（自动索引、自动统计）可用但需观察期，语义型（AI 理解业务）仍在路上。23ai 的向量检索与 JSON 双面视图则是"数据库拥抱 AI 负载"的新战场。本节按成熟度把这张清单排一遍，给出"哪些今天开、哪些先看"的评估法。

一、自治是不是噱头

19c 发布时宣传页上写着"Self-Driving、Self-Securing、Self-Repairing"，工程师群里的反应是冷笑——被自动优化器坑过的谁没阴影。几年过去，值得给一个诚实的重估：自治能力要拆开看，不同层的成熟度天差地别。把"自治"当一个整体来接受或拒绝，都是懒人做法。正确的姿势是拿一张能力清单逐项评估：它替代的运维动作是否规则明确？它出错时的爆炸半径多大？出了错你能不能在观察期内发现并关掉它？

二、能力清单：按成熟度分三档

第一档：运维型自治，放心用。 自动补丁（滚动补丁配合多租户，窗口按租户排）、自动备份校验（RMAN 归档后的自动验证）、自动故障转移（Data Guard 快速启动故障转移、RAC 服务自动重定位）、自动诊断（ADR 自动打包问题证据）。这些动作的共同点：规则明确、成功可验证、失败可回退。第 5 章练过的演练动作，自治系统做的正是同一套——区别只是它做得更勤、从不请假。

第二档：优化型自治，开但要观察。 自动索引（识别候选索引、在影子环境验证、按真实收益创建或废弃）、自动统计收集优化、实时统计与自适应计划。它们动的是系统行为，误判的代价是性能回退而非停机——所以开启的正确姿势是"开着加观察期"：自动索引配了独立视图记录每个候选的验证过程与最终决策，DBA 的角色从"建索引"变成"审索引"，对可疑决策保留否决权。

第三档：语义型自治，持续跟踪。 用自然语言描述业务让系统自动建模、自动分区——宣传先行的成分居多，核心交易库短期别指望。倒是它背后的向量检索能力（23ai 正式内置）有实用价值：语义搜索、推荐、RAG（检索增强生成）场景里，文本向量化后直接存进库、用 SQL 做相似度检索，不必为 AI 场景再单养一套向量专用库。

-- 自动索引：开启与观察（第二档的正确姿势）
EXEC dbms_auto_index.configure('AUTO_INDEX_MODE', 'IMPLEMENT');  -- 或 REPORT_ONLY 先观察
-- 次日复核：它建议了什么、验证数据是什么
SELECT table_name, column_list, auto_index_action,  -- 创建或废弃
       execution_count, improvement
  FROM dba_auto_index_action_history ORDER BY last_executed DESC;
-- 23ai 向量检索：语义搜索进 SQL
CREATE TABLE doc_chunks (
  doc_id NUMBER, chunk_no NUMBER, chunk_text CLOB,
  embedding VECTOR(768, FLOAT32));              -- 向量列是原生类型
INSERT INTO doc_chunks VALUES (1, 1, :text, :vector);
-- 相似度检索：与提问向量最近的 5 个片段
SELECT chunk_text
  FROM doc_chunks
 ORDER BY VECTOR_DISTANCE(embedding, :q_vector, COSINE)
 FETCH FIRST 5 ROWS ONLY;
-- JSON 双面视图：同一份数据既是关系表又是 JSON 文档
CREATE JSON DUALITY VIEW customer_dv AS
  customer JOIN AT ROOT (c.cust_id) { c.cust_name,
    orders: orders JOIN (o.order_id) { o.order_date, o.total } };
​

三、案例：一次自动索引的观察期实录

背景。 某 B2B 平台订单库，慢查询工单每周七八张，DBA 人力吃紧，决定开自动索引但设 90 天观察期。

操作与结果。 第一个月用 REPORT_ONLY 模式：系统提出 14 个候选，复核发现 11 个合理（复合索引的列序都对），2 个冗余（已有对齐索引，它没识别到语义等价），1 个危险——要给一张亿级行的流水表加索引，验证报告显示"影子测试收益 40%"，但没评估该表月末批量装载的写入代价，DBA 否决。第二个月切 IMPLEMENT：自动创建的索引让慢查询工单降到每周两张。第 60 天的复核发现一个新现象：某索引被自动废弃了——系统检测到相关查询被应用改版消灭，随即回收索引、归还写入性能。

解读。 90 天观察期的结论：自动索引的真实价值不在"替代 DBA 建索引"，而在两件人力做不到的事——持续盯（应用改版后索引失去价值，人力从不回收，它会）与影子验证（每个候选先在影子环境跑真实流量再决定）。它的盲区也明确：只看查询收益、对写入侧代价的评估不够保守，批量装载重的表要人工圈入排除清单。变式。 若平台没有企业版许可，自动索引用不了，替代方案是把 6.2 的 TOP SQL 梳理做成月度例会——自动化买不到，流程纪律可以补一半。

四、DBA 的位置变了：从操作者到规则制定者

把三档自治与 AI 特性合起来看，DBA 的日常工作清单正在重新分工：补丁、备份校验、故障转移、基础索引交给内核；DBA 留下的是三件机器做不了的事——定规则（自治系统的排除清单、资源配额、审计策略）、断疑难（跨层关联的复杂故障，第 2 到 6 章的功夫）、管边界（哪些数据上云、哪些给 AI 用、密钥与合规怎么守）。这不是职业危机叙事，是工作内容的迁移：操作密集的部分被自动化抽走，判断密集的部分价值反而更高。全册第 2 章到第 7 章教的东西——架构、事务、诊断、容灾、安全——恰好全是"判断密集"的辖区。

⚠️ 常见坑：把自治云端的能力默认等价于本地版本。自治环境锁参数、限特性，第 6 章的系统级调优旋钮大半交给了内核——应用迁移评估时，把"DBA 自主权收缩"算进改造清单，别到上线才发现调不了参。

问题一：开启自动索引前要准备什么？ 三件事：确认许可包含该选件、圈定排除清单（批量装载重的表、写入敏感的中转表）、与开发团队约定复核节奏（按期出报告、争议索引有否决通道）。缺了第三件，自动索引会变成黑箱，团队对计划的信任反而下降。

问题二：向量列会让普通查询变慢吗？ 向量列与关系列同表共存时，不查询向量列的语句不受影响——向量索引是独立结构。但把海量向量与大表混存会让备份与空间管理变重，大向量场景建议独立表空间存放向量列，容量与备份策略单独算账。

本节要点回顾

• 自治分三档评估：运维型放心用、优化型开观察、语义型持续跟踪——整体接受或拒绝都是懒人做法。
• 自动索引的正确用法：REPORT_ONLY 起步、批量装载表圈入排除清单、按期复核行使否决权。
• 向量检索进内核：23ai 的原生向量类型让 RAG 场景不必再养一套专用库，SQL 直接做相似度检索。
• DBA 转型方向：操作被自动化抽走，定规则、断疑难、管边界三件事价值上升——本册前七章正是后者的训练场。

架构与趋势讲完，最后一章回到最具体的日常：装一套库、值好一个班、配齐一箱工具。