Oracle AI Database 26ai 初探：DBA 和开发者真正需要关注什么

Oracle 这两年把数据库产品线的名字从 23c、23ai 一路推进到 Oracle AI Database 26ai。乍一看像是一次品牌命名变化，但如果只把它理解成“数据库加了 AI 标签”，就容易低估这次版本的重点。

从官方 New Features Guide 的描述看，Oracle AI Database 26ai 是 Oracle Database 的下一个长期支持版本，包含 300 多项新特性，重点集中在 AI 和开发者生产力。也就是说，26ai 不是单独为了某一个 AI Demo 做的功能补丁，而是 Oracle 正在把 AI 能力放进数据库主线能力里。

这篇文章不追求把所有新特性列全，而是从 DBA 和应用开发的角度，整理几个我认为更值得关注的方向。

1. 26ai 的核心变化：向量不再只是外部系统的事情

过去做 RAG 或语义检索时，常见架构是：

• 业务数据放在 Oracle、MySQL、PostgreSQL 等关系型数据库里；
• 文档切片和向量放在独立向量库里；
• 应用层再把两边的数据拼起来；
• 权限、审计、备份、数据一致性都需要额外处理。

这个架构能跑，但对企业系统来说会带来不少治理成本。Oracle AI Vector Search 的思路是把向量数据类型、向量索引、向量距离计算、SQL 查询能力放到数据库内部，让语义检索可以和原有关系数据、JSON、Text、Graph、Spatial 等能力一起使用。

官方文档里对 AI Vector Search 的定位很直接：它让你基于语义而不是关键词查询数据。更关键的是，内置 VECTOR 数据类型以后，业务数据不必为了做相似度搜索再搬到一个单独的向量数据库里。减少数据移动，意味着安全边界、事务一致性、备份恢复和权限模型都更容易继承原有数据库体系。

一个典型查询大概会变成这样：

SELECT doc_id,
       title,
       VECTOR_DISTANCE(embedding, :query_vector, COSINE) AS distance
FROM   doc_chunks
WHERE  tenant_id = :tenant_id
ORDER  BY distance
FETCH  FIRST 5 ROWS ONLY;

这段 SQL 的意义不只是“能查向量”，而是可以同时保留传统数据库很擅长的能力：租户隔离、时间范围过滤、状态过滤、权限过滤、审计和执行计划分析。

2. AI Vector Search 更像数据库能力，而不是外挂能力

26ai 里的向量能力值得 DBA 注意的地方有几个。

首先是向量数据类型。VECTOR 可以作为表字段存在，向量可以和普通业务字段放在同一行中。这样做的好处是数据生命周期更容易管理，例如文档删除、租户清理、归档、备份恢复，不需要额外维护一套同步逻辑。

其次是向量索引。Oracle 支持面向近似最近邻搜索的向量索引，例如 HNSW、IVF 等方向。对于小数据量，全表精确搜索可能可以接受；但一旦进入百万、千万级向量，索引、内存、准确率和查询延迟之间就需要认真权衡。

再次是混合查询。实际企业搜索很少只是“找语义最接近的 5 条”。更常见的是：

• 只能查当前用户有权限的数据；
• 只能查某个租户、某个项目、某个时间范围；
• 需要关键词和语义相关性一起排序；
• 需要把结构化条件和向量相似度组合起来。

这正是 Oracle 把向量能力放进 SQL 体系的价值。DBA 不应该只问“能不能做 RAG”，更应该问“RAG 查询能不能被治理、能不能被解释、能不能被审计、能不能稳定运行”。

3. Select AI：自然语言进数据库，但不能跳过治理

另一个容易吸引眼球的能力是 Select AI。官方 Select AI User's Guide 里提到，它支持通过自然语言和数据库、LLM 交互，包括自然语言转 SQL、RAG、生成合成数据、解释 SQL 等能力。

从使用体验看，这类能力很像：

SELECT AI '查询本月销售额最高的前十个客户';

然后由模型结合数据库元数据生成 SQL、执行或解释结果。

这对开发者和分析人员很有吸引力，但 DBA 视角一定不能只看到“方便”。自然语言到 SQL 的风险也很明显：

• 模型可能生成低效 SQL；
• 模型可能理解错业务语义；
• 用户可能通过提示词绕开预期边界；
• 如果权限设计太粗，可能查到不该看的数据；
• 如果允许自动执行 DML 或 DDL，风险会被放大。

所以 Select AI 更适合先从只读场景开始：查询解释、报表辅助、SQL 生成建议、运维知识库问答、元数据检索。真正要接入生产系统时，建议把 AI Profile、对象白名单、最小权限、SQL 审计、人工确认流程一起设计进去。

我的理解是：Select AI 的价值不是让所有人都不写 SQL，而是降低人与数据库交互的门槛；但数据库仍然要守住权限、审计和稳定性的底线。

4. DBMS_VECTOR / DBMS_VECTOR_CHAIN：RAG 工作流开始贴近数据库

如果只把 26ai 看成“多了一个 VECTOR 字段”，就还是看浅了。围绕向量，Oracle 还提供了 DBMS_VECTOR、DBMS_VECTOR_CHAIN 等包，用来处理嵌入生成、文本切分、摘要、生成式回答等工作流。

一个企业内部知识库的 RAG 流程，通常会包含：

1. 文档进入数据库；

2. 文档按段落或 token 切分；

3. 调用 embedding 模型生成向量；

4. 存入向量字段；

5. 创建向量索引；

6. 用户提问时生成 query embedding；

7. 用向量检索召回相关片段；

8. 把片段和问题交给 LLM 生成答案；

9. 记录引用来源、用户反馈和审计日志。

这些步骤过去往往分散在 Python 服务、任务队列、向量库、对象存储、关系数据库之间。26ai 的方向是让更多步骤可以靠近数据库执行。这样不一定意味着所有逻辑都必须写进数据库，但它给了架构师一个新选择：把数据、向量、检索、权限、审计放在更统一的位置管理。

5. 对 DBA 来说，26ai 不是“少干活”，而是工作重点变化

有些人看到 AI Database，会误以为 DBA 的工作会减少。我的判断正好相反：简单重复的操作可能会减少，但治理和架构判断会变得更重要。

DBA 需要关注的新问题包括：

• 向量字段是否应该和业务表放在一起，还是单独建 chunk 表；
• embedding 维度、格式、模型版本如何记录；
• 向量索引的准确率、内存、构建时间如何平衡；
• RAG 召回结果如何做权限过滤；
• LLM 调用凭据如何存储、轮换和审计；
• Select AI 能访问哪些 schema、table、view；
• 是否允许 AI 生成的 SQL 自动执行；
• 生产环境是否要设置只读代理库或 sidecar 模式；
• 升级到 26ai 后 COMPATIBLE 参数对新特性的影响。

尤其要注意 COMPATIBLE。官方 New Features Guide 提到，一些新的 AI Vector Search 能力需要数据库版本和 COMPATIBLE 参数达到对应要求；从旧版本升级到 26ai 时，参数不会自动替你提升到最新能力级别。这个点在升级规划里很容易被忽略。

6. 对开发者来说，26ai 的价值是少搬数据、少造轮子

开发者最直接的收益，是可以在熟悉的 SQL 和 PL/SQL 体系里做更多 AI 应用。

例如一个客服知识库，不一定非要额外引入一整套向量数据库和同步链路。可以把业务文档切片放在 Oracle 表里，向量字段用于语义召回，普通字段用于租户、产品线、版本、权限、发布时间等过滤，再用 Select AI 或应用层 LLM 完成回答。

这样做并不是说外部向量数据库没有价值，而是当你的核心业务数据已经在 Oracle 里，并且你非常重视一致性、安全、审计和权限时，把向量能力放进 Oracle 可能会让系统简单很多。

对于企业系统，我更看重这种“少搬数据”的价值。AI 应用最怕回答脱离真实业务数据，也怕为了接 AI 又复制出一堆难治理的数据副本。26ai 给出的方向是：让 AI 更靠近可信数据源。

7. 适合先落地的几个小场景

如果现在要在测试环境尝试 26ai，我建议不要一开始就做一个“万能数据库 Agent”。可以先从几个边界清晰的小场景入手。

第一个场景是内部文档语义搜索。比如把运维手册、故障处理记录、标准变更流程切片入库，用向量检索做“相似问题召回”。

第二个场景是 SQL 辅助生成。让 Select AI 或类似流程生成 SQL 草稿，但默认只展示，不自动执行。DBA 或开发人员确认后再运行。

第三个场景是故障知识库问答。把历史故障、告警说明、处理步骤做成 RAG，用于辅助定位，但答案必须带引用来源，不能只给一句模型总结。

第四个场景是测试数据生成。Select AI 支持 Synthetic Data Generation 方向，可以用于开发测试环境构造样例数据，但生产数据脱敏和合规要求仍然要单独设计。

8. 我的结论

Oracle AI Database 26ai 最值得关注的地方，不是“数据库会不会聊天”，而是 Oracle 正在把数据库变成 AI 应用的数据执行层。

对 DBA 来说，重点不只是会不会建向量索引，而是要把 AI 查询纳入权限、审计、资源、变更和升级治理。

对开发者来说，重点也不只是能不能调用大模型，而是能不能在更少数据搬运、更少中间件、更强一致性的基础上构建 AI 应用。

如果说 19c 是很多企业当前最稳的生产主力版本，那么 26ai 更像是下一阶段需要提前理解和验证的方向。真正落地时，不建议一上来就把生产库开放给自然语言 Agent，而应该从只读、可审计、可回滚、可解释的小场景开始。

AI 会让数据库的入口变得更自然，但数据库该有的边界感不能丢。

参考资料

• Oracle AI Database 26ai New Features Guide

https://docs.oracle.com/en/database/oracle/oracle-database/26/nfcoa/all-nfg.html

• Oracle AI Vector Search User's Guide

https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/index.html

• Oracle AI Database Select AI User's Guide

https://docs.oracle.com/en/database/oracle/oracle-database/26/selai/index.html

• Select AI capability matrix

https://docs.oracle.com/en/database/oracle/oracle-database/26/saicm/index.html