Oracle 11g 连接失败主因是驱动版本不兼容：新版 Oracle.ManagedDataAccess（21.x+）移除对11g元数据支持，导致查询 USER_TABLES 等视图时报 ORA-00942；应锁定使用 19.15.0/19.16.0 版本，精简连接字符串，禁用 Enable Extended Data Types 和 Unicode=True，并通过 UseOracleSQLCompatibility("11") 显式指定兼容模式。
不是 oracle 11g 不被支持，而是你用的驱动版本或连接方式不匹配。
Oracle.ManagedDataAccess.dll 版本太新，不兼容 11g
EF Core 或 Dapper 默认拉取的 Oracle.ManagedDataAccess NuGet 包（比如 23.x 或 24.x）在内部已移除对 Oracle 11g 的元数据支持——它能连上，但执行 SELECT * FROM USER_TABLES 这类依赖数据字典视图的查询时，会抛出“不受支持的对象”或 ORA-00942: table or view does not exist。这不是权限问题，是驱动主动跳过了 11g 特有的系统视图别名。
- Oracle 11g 的
USER_TABLES实际映射到sys.user$+sys.obj$等底层表，而新版驱动默认只查all_tables视图，该视图在 11g 中字段结构与 12c+ 不一致 - 推荐锁定使用
Oracle.ManagedDataAccess 19.15.0或19.16.0：这是最后一个完整保留 11g 兼容路径的官方版本 - 不要用
21.x及以上，哪怕它们宣称“支持 11g”，实际运行时会静默降级失败
连接字符串里启用了不兼容的特性开关
某些连接字符串参数在 11g 上无意义甚至触发解析异常，比如 Connection Timeout=30; Pooling=true; Statement Cache Size=10; 看似无害，但 Statement Cache Size 在 11g 驱动中未实现，驱动会尝试调用不存在的 JNI 方法，最终表现为对象不可用。
- 删掉所有非必要参数，最小化连接字符串：
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)));User Id=scott;Password=tiger; - 确认没启用
Enable Extended Data Types=true—— 该选项要求 Oracle 12c+，11g 下直接报错 - 避免使用
Unicode=True（旧版 11g 字符集处理逻辑不同），改用数据库实际字符集（如AL32UTF8）并在应用层做编码转换
EF Core 拦截器或迁移脚本误判数据库版本
EF Core 6+ 的 OracleMigrationSqlGenerator 在生成建表语句时，会通过 connection.ServerVersion 判断是否启用 IDENTITY 列语法。如果返回的是 "11.2.0.4.0"，但驱动内部截断为 "11.2" 后又错误归类为 “12c+”，就会生成 GENERATED ALWAYS AS IDENTITY，而 11g 不识别该语法，报错“不受支持的对象”。
- 检查
OracleConnection.ServerVersion的原始值，别信MajorVersion属性——它可能被四舍五入 - 手动指定版本策略：
optionsBuilder.UseOracle(connectionString, o => o.UseOracleSQLCompatibility("11")); - 禁用自动迁移，用纯 SQL 脚本建库建表，绕过 EF Core 的版本推测逻辑
真正麻烦的不是连不上，而是连上了却在第一次查询元数据时崩——这种延迟报错最容易漏检。务必在连接后立即执行 SELECT 1 FROM DUAL 和 SELECT COUNT(*) FROM USER_TABLES 双验证。
