企业官网建设流程全解析

最近我刚做完一期 Oracle 26ai 的内部培训，备课和答疑的过程中踩了不少坑，也沉淀了不少东西。以往提到 Oracle，大家第一反应是 19c、23ai 这些版本号，但 26ai 这个命名方式本身就表明了态度：AI 已经不再是数据库的一个插件，而是和存储引擎、优化器、事务处理并列的内核能力。这篇内容我会直接按“为什么学、学什么、怎么实操、踩了什么坑”来写，适合正在做传统 DBA 转型的工程师、Oracle EBS 相关系统的运维和二次开发人员，以及对 AI Agent 落地有需求的后端团队。你不需要是 AI 专家，只要懂 SQL 和基本的数据结构，就能从这里开始把 26ai 的能力接到自己的业务里。

1. 为什么说 26ai 是数据库的“分水岭”：整体设计思路与方案选型

1.1 AI 原生数据库和传统数据库的底层逻辑差异

传统数据库解决的核心问题是“如何高效存取数据”，所有的索引、执行计划、事务隔离机制，本质上都是在围绕数据文件的读写效率做文章。但 26ai 这个版本把问题的起点改了：数据库不再只是被动地存储数据，而是能主动理解数据的语义，并且把这种理解能力开放给 SQL 和业务应用。听起来很玄，但落地到架构上其实很清晰——Oracle 把向量检索能力做成了和 B-tree 索引、位图索引平级的基础能力，而不是挂一个外部中间件在外面搞集成。

这意味着什么呢？以前你想做一个“找相似”的功能，常规做法是把数据捞出来，放到外部向量库（比如专门的向量数据库），或者调用外部算法服务算相似度，再把结果存回来。整个过程涉及数据同步、格式转换、一致性维护，非常痛苦。在 26ai 里，向量类型和向量索引直接存在于数据库内核，SQL 语句可以直接把相似度查询作为一个普通谓词来写，优化器能参与向量索引的路径选择，事务能和普通表数据保持一致。这就像以前你想给房子加个储物间，得在院子里另搭一个铁皮房；现在开发商直接在户型图里设计了储藏室，你只需要按户型图来安排东西。

另一个底层变化是数据类型的融合。传统数据库里 JSON、文本、XML、空间数据基本是各玩各的，每个类型有自己专用的查询语法。26ai 在多模态数据支持上做了统一，文本、图像特征向量、JSON 文档可以混在同一个查询里处理。对大多数业务团队而言，这解决了两个问题：不需要为了不同类型数据维护多套存储系统；不用在应用层写一堆胶水代码做类型转换。

1.2 这门培训到底应该学什么，不同岗位怎么抓重点

题目叫“Oracle 26ai AI数据库培训”，但培训不等于把新特性挨个过一遍，更不是让所有人都去研究大模型训练。我梳理下来的知识地图有三层。

底层是数据库内核新特性，包括向量数据类型、向量索引构建、AI SQL 生成器、多模态数据支持。这一层是 DBA 和数据库内核开发者的主战场，核心是理解新索引结构在什么场景能快、什么场景会退化，以及新语法对执行计划的影响。

中间层是应用开发接口，包括 Python 连接 Oracle 的驱动选型、SQL 中调用向量函数的写法、AI Agent 怎么通过工具调用数据库能力。这一层是后端工程师最关心的，本质上是把“数据库能力”封装成业务代码可调用的服务。

顶层是业务场景融合，比如和 Oracle EBS 体系里的 WIP 工单管理、非标工单查询、成本核算（PAC 成本法相关）结合。很多人觉得 EBS 是传统 ERP，和 AI 搭不上边，但实际上非标工单的历史数据里藏着大量经验知识：工单描述怎么写、相似问题以前怎么处理、某个零件在哪些工单里被反复提到。把这些文本数据向量化之后，新工单一进来就可以直接检索历史相似工单，把老工程师的经验沉淀成可查询的知识资产。

不同岗位的学习重点差异很大：如果是 DBA，重点放在内核新特性和性能优化；如果是应用开发，重点放在 SQL 集成和 Agent 调用；如果做 ERP 运维，重点放在数据模型怎么和政策、工单、物料这些业务对象结合。我的建议是先选一个自己最熟悉的业务表，跑通一个向量化检索的闭环，再往外扩展。

1.3 从 11g 时代直接切到 26ai 思路，SQL 还管不管用

很多从 11g、12c 过来的老 DBA 最纠结的问题是：我花了十几年学的 SQL 在 26ai 里还管不管用？我的答案是：不但管用，而且表达边界反而扩大了。

举一个最直观的例子。以前想查“和某个工单描述类似的其他工单”，SQL 基本写不出来，只能写 like 模糊匹配，或者上全文索引，而且查出来的结果和“语义相似”差了十万八千里。在 26ai 里，这就是一条很自然的查询：

SELECT job_id, job_desc, vector_distance(problem_vector, :target_vector) AS distance FROM wip_non_standard_jobs ORDER BY distance FETCH FIRST 10 ROWS ONLY;

这条 SQL 放到 11g 里任何版本都跑不了，但在 26ai 里，问题向量列、向量距离函数、按距离排序、分页，全部走标准 SQL 语法。也就是说，你过去积累的 SQL 直觉、索引优化经验、执行计划分析能力，一样都没浪费，反而因为可以直接操控语义检索，能写出以前完全写不出来的业务逻辑。那些说“AI 数据库不需要学 SQL”的人，要么没真正用过，要么只是拿 demo 看了个过场。

2. 核心功能拆解：从数据存储到 AI 决策的完整链条

2.1 向量检索与语义搜索的落地姿势

向量检索是 26ai 最核心的新能力，但很多人的理解停留在“存一个数组，算个余弦相似度”的水平，这远远不够。实际落地时要考虑三个环节：数据向量化怎么完成、向量列怎么建、索引怎么选。

数据向量化本身不是数据库的工作，你需要用嵌入模型把文本变成浮点数组。培训里我用的是常见的 768 维和 1024 维两种模型，维度选择直接影响后续的索引大小和查询性能。维度越高，表达语义越精细，但存储开销和计算开销都上去了；维度太低，语义区分度不够。文本类数据我一般从 768 维起步，图像或混合特征再考虑更高的维度。

建表时直接声明向量列类型，Oracle 26ai 沿用了 23ai 时代的语法并做了增强：

CREATE TABLE wip_job_knowledge ( job_id NUMBER PRIMARY KEY, job_desc VARCHAR2(1000), problem_vector VECTOR(768), create_time DATE );

向量索引有两种主流选择：IVF（倒排文件索引）和 HNSW（层级小世界图索引）。HNSW 在查询精度和召回率上通常表现更好，适合在线检索场景；IVF 在构建速度上有优势，适合数据量特别大且离线批处理居多的场景。我的实测经验是：千万级以下的向量数据，HNSW 的响应时间更稳定，而且对内存的利用更充分；如果数据量上亿，IVF 的索引构建时间和内存占用会友好很多。很多没实际用过的朋友喜欢问“哪个索引最好”，这种问题我给不了答案，只能说先压一个和你线上数据量同量级的测试集，用 EXPLAIN PLAN 看实际执行路径。

2.2 SQL 生成与自然语言交互，AI 数据库的“嘴”和“手”

26ai 里有一个绕不开的能力：SQL 生成。官方叫法很多，但本质是一样的——把自然语言变成可执行的 SQL。这个能力的关键不是“生成”那一下，而是生成的 SQL 怎么和既有业务规则对接。

我在培训里反复强调一个观点：AI 生成的 SQL 不是用来替代 DBA 写复杂报表的，而是用来拉近业务人员和数据之间的距离。你可以让业务用户用自然语言问“这个月非标工单里返工次数最多的物料有哪些”，系统生成 SQL 后，由 DBA 或开发人员审核确认，再开放给更广的使用范围。这里的审核环节不能省，因为大模型生成 SQL 时经常忽略业务约束。举个例子，生成器可能写出不带 org_id 过滤的查询，而多组织架构下忽略这个条件会导致数据串组织；或者忘记加库存状态约束，把已取消的工单也统计进去了。

所以企业落地时，我建议做两层防护。第一层是 SQL 审核区，AI 生成的 SQL 先落到影子库执行计划检查，自动识别全表扫描、隐式转换、笛卡尔连接等高危特征；第二层是业务维度的白名单，针对每一类业务问题绑定允许查询的表和过滤条件。别嫌麻烦，这一步省了，后面出问题的时间成本会更贵。

2.3 多模态数据支持与 AI Agent 的接法

26ai 把 AI Agent 的落地往前推了一大步，原因是数据库能扮演 Agent 的“记忆库”和“工具库”两个角色。

记忆库很好理解，Agent 与用户交互的历史、检索到的文档片段、中间推理结果，都可以结构化存到数据库里。相比纯 KV 存储或文件存储，数据库能提供事务保证、权限控制和复杂的关联查询。工具库则体现在 Agent 调用数据库的方式上：Agent 可以不直接拼 SQL，而是通过数据库对外暴露的接口执行语义检索或调用分析函数，再结合业务上下文给出回答。

我在演示里做过一个很典型的最小闭环：用 Python 连接 26ai，加载一个工单知识表，通过向量相似度召回历史相似工单，再调用一个通用大模型对召回结果做总结，最后返回给前端。整个过程里数据库承担了“找出最相关的历史经验”这一步，而不是把所有数据一股脑塞给大模型去理解。这样做的好处非常明显：大模型不需要处理全部数据，幻觉空间大幅降低，而且响应速度更快。至少我自己的感受是，别把大模型当数据库，要把数据库当大模型的记忆索引。

3. 实操过程与核心环节实现：从零搭一个 AI 数据库实验台

3.1 环境准备：虚拟机配置、安装与连接

实操部分先从搭建实验环境开始。我这一轮培训用的是 Oracle VM VirtualBox 装的 Oracle 26ai 单机实例。很多人问我为什么不用云数据库，原因很实际：本地虚拟机能随时快照回滚，培训时各种破坏性操作（例如损坏数据文件、误删表空间）都能恢复，这是云环境很难提供的便利。

虚拟机的资源配置我建议最少 8GB 内存、4 核 CPU、100GB 可用磁盘，磁盘建议用固态硬盘。Oracle 的数据库安装对 IO 非常敏感，固态盘能把安装时间和后续向量索引构建的时间缩短三分之一以上。操作系统建议用 Oracle Linux 8 或兼容版本，避免因为 glibc 版本问题导致的安装报错。

安装过程有个细节容易被忽略：在 DBCA 建库阶段，字符集建议选 AL32UTF8。这个字符集对中文支持最友好，特别是后面要存工单描述这类中文文本做向量化时，能避免很多由于字符集转换带来的乱码和语义偏差。密码策略方面，如果只是本地实验，可以关掉密码复杂度校验，否则测试时写脚本连库会被复杂的密码规则折腾疯。

安装完成后的连接验证，我习惯先用命令行工具跑一条最简单的语句：

sqlplus system/password@//127.0.0.1:1521/FREEPDB1

能进去说明监听器和实例服务都正常。如果连接报错，优先排查监听服务是否启动、端口 1521 是否被占用，这两项占了连接问题的一半以上。网络层面再简单用 tnsping 验证连通性，基本就能快速定位。

3.2 建库与核心对象创建：向量列带来的建模变化

数据库建好之后，先别急着灌数据，建模这一关要想清楚。传统表结构设计我们只需要考虑字段类型、主外键、索引约束。有了向量列之后，你要额外回答一个问题：哪些字段值得被向量化？

我的判断标准是三个“看”：看这个字段是不是承载了业务语义，看它是不是会被用来做相似性检索，看它是否同时存在于历史数据和增量数据中。比如工单表里的问题描述字段，完全符合这三个条件，值得向量化；而工单号这种整型编码，本身已经是结构化语义，不需要向量化。

培训的演示表我们做了一张简化版的非标工单知识表：

CREATE TABLE wip_non_standard_jobs ( job_id NUMBER PRIMARY KEY, job_no VARCHAR2(30), line_desc VARCHAR2(500), problem_desc VARCHAR2(2000), problem_vector VECTOR(768), status VARCHAR2(20), created_date DATE ); CREATE INDEX idx_wip_job_hnsw ON wip_non_standard_jobs (problem_vector) INDEXTYPE IS VECTOR DISTANCE COSINE;

索引语句里有意思的是 DISTANCE COSINE 这个参数。Oracle 支持多种距离算法，欧氏距离、余弦相似度、曼哈顿距离等。文本语义向量一般选余弦相似度，因为它更关注方向一致性而不是模长差异；如果向量做过归一化处理，欧氏距离和余弦相似度在结果排序上等价。这里我一般会多提一句，别盲目照抄参数，先搞清楚自己的嵌入模型输出的是归一化向量还是原始向量，再选距离算法。

3.3 数据增删改查的 AI 增强写法：从普通 DML 到向量写入

普通的数据增删改查在 26ai 里没有任何变化，INSERT、UPDATE、DELETE、SELECT 的标准语法照用不误。但二维的是，当你引入向量列之后，数据写入就不再只是“insert 一条记录”，而是“插入记录+生成向量+维护索引”的组合动作。

实际演示中我用存储过程来封装这个流程。存储过程在 Oracle 里的地位一直很特殊，它不只是批量操作的工具，更是把业务规则固化在数据层的手段。在这里，我把“生成向量”和“插入记录”做了绑定：

CREATE OR REPLACE PROCEDURE add_knowledge_job ( p_job_no VARCHAR2, p_line_desc VARCHAR2, p_problem_desc VARCHAR2, p_embedding VECTOR ) AS BEGIN INSERT INTO wip_non_standard_jobs ( job_id, job_no, line_desc, problem_desc, problem_vector, status, created_date ) VALUES ( seq_job_id.NEXTVAL, p_job_no, p_line_desc, p_problem_desc, p_embedding, 'NEW', SYSDATE ); COMMIT; END add_knowledge_job;

这里有人会问，向量在应用层生成好传进来，还是数据库里生成？我的答案是分阶段：第一阶段先在应用层或者 Python 脚本里批量生成向量，因为这阶段你还在调整嵌入模型，频繁换模型也容易，直接把向量作为参数传入；等到模型稳定了，再考虑用数据库外部表加载或封装成内部任务。不要一开始就把向量生成逻辑写死在数据库里，否则每次模型调优都要动存储过程，版本控制会很痛苦。

3.4 用 Python 连接 Oracle，跑通一个 AI 工单相似度检索闭环

接下来是培训里最受关注的部分：Python 连接 Oracle 26ai 跑一个真实场景。我选择 python-oracldb 作为连接驱动，这个驱动是官方大力推广的新一代驱动，纯 Python 实现，部署不需要安装 Oracle Instant Client，对开发环境极其友好。

import oracledb connection = oracledb.connect( user="scott", password="tiger", dsn="127.0.0.1:1521/FREEPDB1" ) target_vector = [0.01, -0.05, ...] # 这里放由嵌入模型生成的 768 维向量 with connection.cursor() as cursor: sql = """ SELECT job_no, problem_desc, vector_distance(problem_vector, :tv, COSINE) AS distance FROM wip_non_standard_jobs ORDER BY distance FETCH FIRST 5 ROWS ONLY """ cursor.execute(sql, {"tv": oracledb.Vector(target_vector)}) for row in cursor: print(row) connection.close()

有几个细节必须注意。第一，向量参数需要用 oracledb.Vector 显式包装，纯 Python 列表直接传入会因为类型不识别报错。第二，用 FETCH FIRST 而不是 ROWNUM 做分页，可读性更好，也在 12c 以上的版本更符合标准写法；ROWNUM 在复杂排序里容易写出逻辑错误，新手尤其容易踩坑。第三，向量距离计算在大表上走索引和全表扫描的性能差异可以达到两个数量级，所以生产环境一定要通过执行计划验证索引被正确命中了。

这串代码跑通之后，你就有了一个最原始的 RAG 原型：从数据库里检索最相似的历史工单，后续再接大模型做摘要和推断，就是完整的 AI Agent 场景。

3.5 分页查询的 26ai 写法和高阶清理逻辑

分页查询是老生常谈，但在 26ai 里建议统一用标准写法，尤其是和向量检索配合时。很多 10g 时代的老项目里还留着三层嵌套的 ROWNUM 分页，现在完全没有必要了：

SELECT job_no, problem_desc FROM wip_non_standard_jobs ORDER BY created_date DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

OFFSET FETCH 的可读性和可维护性远好于 ROWNUM 嵌套，并且优化器对 FETCH FIRST 的识别也更成熟。配合向量距离排序时，这种写法格外顺手，不会因为分页嵌套导致执行计划走偏。

4. 常见问题与排查技巧实录

4.1 监听服务无法启动与日志清理的实战解决思路

每次培训，Oracle 监听服务相关的问题永远是最多的。我总结下来，监听服务无法启动无非三类原因：端口被占用、监听配置文件写错、实例服务注册失败。排查第一步先看端口：

netstat -tlnp | grep 1521

如果有其他进程占用，要么杀掉占用进程，要么修改 listener.ora 里的端口号。没占用的话，用 lsnrctl status 查看监听状态，再手动执行 lsnrctl start 看具体报错。很多时候报错信息里直接写了配置文件哪一行有问题，按行修就行。

日志清理是另一个高频话题，尤其是老版本遗留的监听日志增长过快问题。现代版本的 Oracle 提供了 ADR 自动诊断库，日志保留策略可以通过参数控制。实用做法是把诊断信息保留时间缩短，并设置定期清理：

ALTER SYSTEM SET diag_adr_enabled=TRUE;

再结合 ADRCI 工具设置清理策略。这里给一个个人建议：别手动删日志文件，数据库进程持有文件句柄，日常删文件容易导致空间不释放甚至句柄异常。所有清理操作都应该通过官方工具或参数控制，这才是正确姿势。

4.2 数据库同步、结构变更与常用工具选择

做 26ai 实操时，很多人会纠结怎么同步数据过来，或者怎么从 MySQL 迁移到 Oracle。数据库同步软件的选择要看业务容忍度：如果允许分钟级延迟，逻辑复制类工具就够了；如果需要秒级甚至实时一致，物理复制或基于日志解析的方案更可靠。不要听厂商吹得天花乱坠，先在测试环境测定延迟和吞吐量，再决定是否采用。

结构变更方面，MySQL 和 Oracle 的行为差异很大。在 MySQL 里修改表结构经常要考虑锁表和主从延迟，但在 Oracle 26ai 里，很多结构变更可以联机执行，其中加字段基本不影响业务。不过向量列和向量索引的变更还是要谨慎，因为重建索引涉及全表扫描和向量计算，建议在业务低峰期操作。

常用工具方面，很多学员会问 dbx 这类数据库管理工具能不能开发环境使用。我个人的经验是：工具的本质是减少重复劳动，但不要依赖工具去理解 SQL。连接、浏览、执行计划可视化这些功能都可以用，真正调优时还是要自己读执行计划。工具选择标准我只看三点：是否支持 Oracle 26ai 的向量类型、是否支持 SSH 隧道连接、是否能在低内存机器上流畅运行。

4.3 AI 生成 SQL 的校验与性能陷阱

AI 生成 SQL 最大的风险不是语法错，而是逻辑对但性能崩。几个典型的性能陷阱我在培训里逐一演示过：第一个是隐式转换，比如字符串字段和数字参数比较，导致索引失效；第二个是 SELECT 出多余的列，把全表的数据都捞回应用层；第三个是缺少分页条件，AI 模型经常忘记这个约束；第四个是忽略索引提示和物化视图的存在，生成的 SQL 走得动但不代表走得好。

我自己用下来的经验是把表结构、索引、数据量统计信息都描述清楚再让模型生成 SQL，同时明确要求必须包含过滤条件、分页条件和绑定变量。如果生成结果走了全表扫描，直接用 executor 反馈执行计划让模型重新生成，这个反馈闭环非常有效。别指望一次生成就能上线，AI SQL 的调优过程和人工调优一样，都是查执行计划、修改语句、再验证的循环。

4.4 AI 提示词在数据库运维中的使用技巧

最后聊聊提示词。也就是怎么把 AI 变成你的数据库专家助理。我自己常用的几个提示词模板很固定，比如：

你是 Oracle 数据库优化专家。以下是表结构和当前执行计划： （粘贴 DDL 或 DESCRIBE 结果） 现有 SQL： （粘贴 SQL） 请分析执行计划中耗时最高的步骤，并给出改写建议。 要求： 1. 保留原业务语义 2. 优先使用已有索引 3. 避免隐式转换 4. 用简洁中文输出

这类提示词的关键是把上下文信息给足，让模型做“判断题”而不是“猜想题”。另外，涉及企业核心数据时，本地私有化模型优先，敏感数据不要随便往公网接口上传。网上流传的一些所谓“无限制 AI”工具或来路不明的站点，看起来方便，但数据安全风险极高，用企业数据去蹭这种免费接口，本质上等于把核心数据白送出去，这笔账怎么算都不划算。

关于 AI 聊天工具还有一个提示：安全的本地模型部署并不难，现在市面上有很多开源可商用的对话模型，配合向量数据库和 26ai 完全可以在内网搭建一套合规的问答系统。数据不出内网这一点，在做数据库培训时尤其值得强调。

5. 一些让我印象深刻的细节

这次培训做下来，我最大的感受是：传统 DBA 的很多经验在 26ai 时代并不是负担，反而是稀缺资产。能看懂执行计划、能判断索引是否命中、能理解业务约束的人，才能真正把 AI 生成 SQL 用起来。而最容易被忽略的，却是“向量化之前先做数据清洗”这一步。工单描述里大量存在大小写不统一、中英文混杂、特殊符号干扰，如果原样向量化，检索结果会被噪声严重影响。我在演示前特意加了数据预处理步骤，清洗后再生成向量，Top 5 的准确率明显提升。

最后再分享一个小技巧：培训时不要一上来就铺开讲所有新特性。挑一张学员最熟悉的业务表，带大家把表结构建好、数据向量化、跑通一个相似检索，这个成就感比听完一百页幻灯片有用得多。我自己带课时，第一个动手实验永远都是“把最近三个月的历史工单变成可查询的知识库”，十分钟跑通，剩下的内容大家自然愿意继续听。这个思路你拿到自己的团队里同样适用。