ODP.NET执行DDL报ORA-01031是因用户缺少显式系统权限（如CREATE TABLE），角色授予无效；DDL自动提交不可回滚；标识符需校验转义防注入；低版本驱动可能存在语法兼容性问题。
ODP.NET执行DDL报ORA-01031：权限不足的典型表现
直接执行 create table 或 create index 时抛出 ora-01031: insufficient privileges，不是连接没配对，而是当前数据库用户缺对应系统权限。odp.net本身不拦截ddl，它只是把语句原样发给oracle，权限校验完全在服务端发生。
常见错误现象包括：
- 用
conn.ExecuteNonQuery("CREATE TABLE t1 (id NUMBER)")报错，但同个用户在SQL*Plus里能成功 - 建表成功了，建索引却失败，提示同样错误
- 用
ALTER SESSION SET CURRENT_SCHEMA = xxx切换模式后仍失败
关键点：Oracle中DDL权限不能通过角色（如 DBA）间接授予——必须显式赋予用户。即使用户是 CONNECT + RESOURCE 角色成员，也不具备建表权限。
实操建议：
- 确认用户是否被直接授予
CREATE TABLE、CREATE INDEX等权限（不是通过角色）：SELECT privilege FROM dba_sys_privs WHERE grantee = 'YOUR_USER';
- 若需跨schema建对象，还需
CREATE ANY TABLE或CREATE ANY INDEX（慎用，属高危权限） - 避免依赖
RESOURCE角色——它只含存储相关权限（如 unlimited tablespace），不含 DDL 权限
ExecuteNonQuery执行DDL时的事务与自动提交行为
Oracle中DDL语句自带隐式提交（implicit commit），无论是否包裹在 Transaction 中，执行完 ExecuteNonQuery 后都会立即生效且无法回滚。这点和DML完全不同，也是很多开发者踩坑的根源。
使用场景举例：在部署脚本中动态建表+初始化数据，误以为能整体回滚，结果表建好了、插入失败，留下脏状态。
实操建议：
- 不要在
OracleTransaction内调用ExecuteNonQuery执行DDL——事务对象会失效，后续DML可能报ORA-02089: COMMIT not allowed in subordinate session - 如果需要“原子化”部署，拆成两步：先用DDL建结构（自动提交），再用独立事务插入初始数据
- 注意
OracleConnection.AutoCommit属性对DDL无影响——它只控制DML的默认提交行为
动态拼接DDL字符串时的SQL注入与标识符转义
用变量拼接表名、列名时，ExecuteNonQuery 不做任何参数化处理，所有内容原样发送。Oracle不支持像DML那样用绑定变量传标识符（identifier），所以 CREATE TABLE :table_name 是语法错误。
常见错误现象：
-
string sql = $"CREATE TABLE {tableName} (...)";—— 用户输入tableName = "users; DROP TABLE admins;"导致注入 - 表名含特殊字符（如短横线、空格）时直接报
ORA-00903: invalid table name
实操建议：
- 严格校验标识符：只允许字母、数字、下划线，且必须以字母或下划线开头（正则
^[a-zA-Z_][a-zA-Z0-9_]*$） - 必须用双引号包裹标识符才能支持大小写敏感或特殊字符：
"My-Table"，但双引号本身需转义（C#中写成"\"My-Table\""） - 避免从不可信来源读取表名/列名；如必须，优先走白名单映射（如配置项键 → 实际表名）
ODP.NET版本与Oracle服务端兼容性对DDL的影响
低版本ODP.NET（如11.2.x）在连接高版本Oracle（如19c/21c）时，某些DDL语法可能被拒绝，不是权限问题，而是驱动解析能力不足。例如，CREATE TABLE ... ENABLE ROW MOVEMENT 在旧驱动下可能报 ORA-00922: missing or invalid option。
性能影响不大，但兼容性问题会导致部署卡在第一步。
实操建议：
- 检查
OracleConnection.ServerVersion是否与目标库主版本一致（如都为19.x） - 升级到对应 Oracle 客户端版本的 ODP.NET（推荐使用 Oracle.ManagedDataAccess，免安装客户端）
- 若必须用旧驱动，避开新语法特性：不用
IDENTITY列，改用序列+触发器；不用INVISIBLE列；索引建在普通字段上而非函数索引（除非确认驱动支持）
最麻烦的其实是权限链路——Oracle里建索引还要额外检查基表是否在当前用户schema下，或者是否有 SELECT 权限。这个细节很容易漏，等建到第五个索引才爆出来。
