为什么EF Core生成的Oracle分页SQL报错

ORA-00933错误本质是EF Core默认按Oracle 12c+语法生成OFFSET/FETCH分页SQL，而Oracle 11g不支持该语法；必须显式调用UseOracleSQLCompatibility("11")使EF Core回退生成ROWNUM嵌套查询。

ORA-00933 错误本质是语法不兼容

EF Core 默认按 Oracle 12c+ 语法生成分页 SQL（OFFSET ... FETCH NEXT），但 Oracle 11g 不支持该语法，直接执行就会报 ORA-00933: SQL命令未正确结束。这不是连接问题或 Linq 写法错误，而是 EF Core 驱动层对数据库版本的默认假设与实际环境错配。

UseOracleSQLCompatibility("11") 必须显式设置

仅调用 UseOracle(connectionString) 不够——它默认走 12c 兼容模式。必须通过 UseOracleSQLCompatibility("11") 显式声明目标版本，EF Core 才会回退到 ROWNUM 嵌套子查询方式生成分页语句。

1. 在 AddDbContextPool 中配置：options.UseOracle(conn, b => b.UseOracleSQLCompatibility("11"))
2. 若用 OnConfiguring，写法为：optionsBuilder.UseOracle(connectionString, b => b.UseOracleSQLCompatibility("11"))
3. 传参必须是字符串 "11"，不是数字 11 或 "11g"
4. Oracle 12c 环境则传 "12"；混用 11g/12c 实例时，需按实际数据库版本分别配置

原生 SQL + Skip/Take 组合会二次出错

即使设置了 UseOracleSQLCompatibility("11")，若对 FromSqlRaw() 结果再链式调用 Skip()/Take()，EF Core 仍可能尝试在外层包装 OFFSET——因为 FromSqlRaw 返回的是可组合 IQueryable，EF 不知道你已手动写了分页逻辑。

1. 正确做法：在 FromSqlRaw() 后立刻调用 AsEnumerable() 或 AsAsyncEnumerable()，切断 IQueryable 链，让 Skip/Take 在内存中执行
2. 更推荐：把分页逻辑直接写进原生 SQL 里（如用 ROWNUM 套壳），避免混合使用
3. 验证是否生效：开启 EF 日志，检查生成的 SQL 是否含 rownum 而非 OFFSET

别忽略 DbContext 生命周期和连接复用场景

如果你用 AddDbContextPool，同一个 DbContext 实例可能被多个请求复用。如果某次请求意外触发了未带 UseOracleSQLCompatibility 的配置路径（比如条件分支漏配），后续请求哪怕走正确路径，也可能因缓存或状态残留继续报错。

1. 确保所有注册入口（Startup、Program.cs、测试 fixture）都统一配置 UseOracleSQLCompatibility
2. 避免在 OnConfiguring 中根据环境变量动态决定是否调用该方法——一旦跳过，就彻底失效
3. 升级 Oracle.EntityFrameworkCore 包时注意：新版可能更改默认行为，但不会自动适配旧版数据库，仍需显式指定

实际项目里最容易被绕过的点，是以为“连得上库就万事大吉”，结果分页一跑就崩——其实从第一行 UseOracle 开始，版本兼容性就已经锁死了。