Oracle EF Core Provider 支持 .NET 6+ 迁移，但需严格匹配 Oracle.ManagedDataAccess.Core v3.21.130+、显式配置迁移表在 SYS schema、补全 schema 前缀、关闭连接池与语句缓存、设置 DDL 锁超时及正确映射时间类型。
Oracle EF Core Provider 不支持 .NET 6+ 的默认迁移生成？
不是不支持，而是 oracle 提供的 oracle.entityframeworkcore（v7.21.0+）对 dotnet ef migrations add 的兼容性有硬性限制：它**必须配合 oracle 官方的 oracle.manageddataaccess.core v3.21.130+**，且不能混用 microsoft 的 microsoft.data.sqlclient 或其他厂商驱动。常见错误是执行迁移命令时抛出 system.typeloadexception: could not load type 'oracle.entityframeworkcore.infrastructure.oracleoptionsextension'——这基本等于驱动版本或依赖链断裂。
- 确认项目中只引用了
Oracle.EntityFrameworkCore和配套的Oracle.ManagedDataAccess.Core，删掉所有System.Data.OracleClient、Oracle.DataAccess等旧包 -
DbContext的OnConfiguring中必须显式调用options.UseOracle(connectionString, o => o.MigrationsHistoryTable("__EFMigrationsHistory", "SYS"))；Oracle 要求迁移表必须在SYSschema 下，否则dotnet ef migrations list会查不到已应用记录 - 迁移脚本生成后，
Up(MigrationBuilder)方法里所有CREATE TABLE语句默认不含 schema 前缀，但 Oracle 要求显式指定用户（如"HR"."EMPLOYEES"），所以得手动在MigrationBuilder操作中补全schema参数，比如migrationBuilder.CreateTable("EMPLOYEES", ... , "HR")
连接字符串里哪些参数实际影响 EF Core 迁移行为？
Oracle 连接字符串不是“能连上就行”，EF Core 迁移阶段会读取其中多个键来决定 SQL 生成策略。最常被忽略的是 Connection Timeout 和 Pooling ——超时太短会导致 dotnet ef database update 在建索引时中断；连接池开启（默认 true）则可能让迁移过程中残留未提交事务，卡住 DDL 执行。
- 强制关闭池化：
Pooling=false，尤其在 CI/CD 自动迁移场景下避免连接状态污染 - 显式设置字符集：
Unicode=true;Charset=UTF8;，否则中文列注释或COMMENT ON COLUMN语句会乱码，且 EF 不报错，只静默丢弃 -
Statement Cache Size=0推荐设为 0：Oracle EF Provider 的迁移 SQL 是动态拼的，开启语句缓存反而导致ORA-01008: not all variables bound
执行 dotnet ef database update 卡在 “Applying migration” 无日志？
这不是网络延迟，而是 Oracle 默认把 DDL 操作（如 CREATE INDEX）当作隐式事务处理，而 EF Core 的迁移执行器在等待一个它收不到的“完成信号”。典型现象是命令行光标停住、数据库会话里能看到 ALTER SESSION SET CURRENT_SCHEMA 之后就再无动作。
- 在
DbContext配置中加.UseOracle(..., options => options.EnableRetryOnFailure())并配重试策略——这不是为网络抖动，而是绕过 Oracle 对 DDL 的锁等待阻塞 - 迁移前手动执行
ALTER SESSION SET DDL_LOCK_TIMEOUT = 30（单位秒），否则大表加索引可能直接 hang 住整个迁移流程 - 别依赖
dotnet ef database update --verbose查问题：Oracle Provider 的 verbose 日志不输出实际执行的 SQL，得开 Oracle 侧的 SQL trace（ALTER SESSION SET SQL_TRACE = TRUE）才能定位卡在哪条语句
从 SQL Server 迁移过来的模型，为什么 [Column(TypeName = "datetime2")] 在 Oracle 里失效？
因为 Oracle 没有 datetime2 类型，EF Core Provider 会直接忽略这个 TypeName 设置，转而用默认的 DATE（精度只到秒），导致 DateTime.Now.Millisecond 信息丢失。这不是 Bug，是 Provider 主动降级适配。
- 改用
[Column(TypeName = "timestamp")]才能映射到 Oracle 的TIMESTAMP(6)，支持毫秒 - 如果字段需时区支持，必须写成
[Column(TypeName = "timestamp with time zone")]，且数据库端对应列类型也得是TIMESTAMP WITH TIME ZONE，否则 EF 插入时抛ORA-01878: found a date/time field that is not in the correct format -
HasDefaultValueSql("SYSDATE")可用，但HasDefaultValueSql("CURRENT_TIMESTAMP")在 Oracle 里无效——得换"SYSTIMESTAMP"，否则迁移生成的 SQL 会编译失败
UNLIMITED TABLESPACE 权限和 CREATE ANY INDEX 权限——缺一个，update 就静默失败，连错误都不吐给你。 
