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 驱动层默认假定的数据库版本与实际 Oracle 环境不一致，导致分页语句语法不兼容。

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

只调用 UseOracle(connectionString) 还不够，因为它默认采用 12c 兼容模式。必须通过 UseOracleSQLCompatibility("11") 明确指定目标版本，EF Core 才会自动切换为使用 ROWNUM 嵌套子查询的方式生成 Oracle 11g 可执行的分页 SQL。

• 在 AddDbContextPool 中配置：options.UseOracle(conn, b => b.UseOracleSQLCompatibility("11"))
• 如果使用 OnConfiguring，写法为：optionsBuilder.UseOracle(connectionString, b => b.UseOracleSQLCompatibility("11"))
• 传入参数必须是字符串 "11"，不能写成数字 11，也不能写成 "11g"
• 如果是 Oracle 12c 环境，则传 "12"；当项目同时连接 11g 和 12c 实例时，需要根据实际数据库版本分别配置

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

即使已经设置了 UseOracleSQLCompatibility("11")，如果在 FromSqlRaw() 返回结果后继续链式调用 Skip()/Take()，EF Core 仍然可能在外层再次拼接 OFFSET。原因在于 FromSqlRaw 返回的是可组合的 IQueryable，EF Core 并不知道你是否已经在原生 SQL 中自行完成了分页处理。

• 正确做法：在 FromSqlRaw() 后立即调用 AsEnumerable() 或 AsAsyncEnumerable()，中断 IQueryable 链，让后续 Skip/Take 改为在内存中执行
• 更推荐的方式：直接把分页逻辑写进原生 SQL 中，例如使用 ROWNUM 套壳分页，避免原生 SQL 与 EF 分页机制混用
• 验证是否配置成功：开启 EF 日志，检查最终生成的 SQL 中是否包含 rownum，而不是 OFFSET

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

如果你启用了AddDbContextPool，那么同一个DbContext实例可能会在多个请求之间被重复复用。假如某次请求误走了未配置UseOracleSQLCompatibility的路径（例如某个条件分支漏掉了配置），那么后续请求即使进入正确路径，也仍可能因为状态残留或缓存影响而持续触发分页 SQL 报错。

• 确保所有注册入口（Startup、Program.cs、测试 fixture）都统一配置 UseOracleSQLCompatibility
• 不要在 OnConfiguring 中根据环境变量动态决定是否调用该方法——一旦某次跳过配置，就会彻底失效
• 升级 Oracle.EntityFrameworkCore 包时也要留意：新版本可能调整默认行为，但并不会自动兼容旧版 Oracle 数据库，因此仍需手动显式指定版本