oracle 23ai向量能力非独立服务，而是通过dbms_vector和dbms_data_mining包在关系表中叠加实现；配置失败主因是onnx模型路径、权限或格式不合规，需满足opset≤17、无控制流、文件置于models_dir一级目录且由oracle用户拥有，加载须用sys等具execute_catalog_role权限用户执行。
Oracle 23ai 的向量能力不是开箱即用的独立“向量数据库”，而是通过内置的 DBMS_VECTOR 和 DBMS_DATA_MINING 包，在已有关系表基础上叠加向量化能力。配置失败，90% 是卡在模型加载路径、权限或 ONNX 格式兼容性上。
加载 ONNX 嵌入模型前必须确认三件事
Oracle 不接受任意 PyTorch/TensorFlow 模型，只认标准 ONNX（Opset ≤ 17）、无控制流、无自定义算子的精简版本。
-
MODELS_DIR目录必须由 Oracle 用户（如oracle）拥有，且 SELinux 或 AppArmor 不能拦截文件读取（Linux 上常见报错：ORA-20000: Failed to load model file） - ONNX 文件需放在
MODELS_DIR下一级，不能嵌套子目录；文件名中不能含空格或中文，例如bge-base-zh-v1.5.onnx合法，my model.onnx会静默失败 - 执行
DBMS_VECTOR.LOAD_ONNX_MODEL必须以具有EXECUTE_CATALOG_ROLE和CREATE ANY DIRECTORY权限的用户（如SYS）运行，普通 PDB 用户即使有DBA角色也不行
建向量列时别直接用 VARCHAR2 原始文本
Oracle 对文本向量化有隐式长度限制和编码要求：超过 4000 字符的 VARCHAR2 或含非 UTF-8 字节的字段，调用 VECTOR_EMBEDDINGS 会抛出 ORA-40652: invalid input for vector embedding。
- 先用
UTL_RAW.CAST_TO_NVARCHAR2清洗二进制脏数据，再截断到 3999 字符以内（SUBSTR(text_col, 1, 3999)） - 若原始字段是
CLOB，必须显式转为NVARCHAR2：TO_NCHAR(DBMS_LOB.SUBSTR(clob_col, 3999))，否则VECTOR_EMBEDDINGS函数不识别 - 中文场景强烈建议用
text2vec-large-chinese类模型，而非英文模型——后者对中文分词失效，向量余弦相似度接近 0
查询向量时 VECTOR_DISTANCE 的性能陷阱
直接在 WHERE 中写 VECTOR_DISTANCE(embedding_col, :vec, 'cosine') 会全表扫描，哪怕该列已建了 <code>VECTOR INDEX。
- 必须配合
ORDER BY VECTOR_DISTANCE(...)+FETCH FIRST N ROWS ONLY才能触发索引下推 - 距离函数参数顺序不能颠倒：
VECTOR_DISTANCE(col, bind_var, 'cosine')正确，VECTOR_DISTANCE(bind_var, col, 'cosine')会导致 ORA-40655 错误 - 如果用绑定变量传入向量（如 Python 的
oracledb），确保变量类型为oracledb.DB_TYPE_VECTOR，而非普通bytes或list，否则会降级为 CPU 计算
最易被忽略的是：向量索引（VECTOR INDEX）和传统 B-Tree 索引互斥——同一列上不能既有 VECTOR INDEX 又有普通索引，否则 DML 会变慢且 DBMS_STATS.GATHER_TABLE_STATS 可能报错。实际部署时，要么纯向量检索，要么把向量列和业务过滤字段拆到不同列上做组合查询。
