OracleBulkCopy 性能瓶颈主要在 Oracle 服务端配置而非 .NET 或驱动版本；需禁用索引与约束、设 NOLOGGING、避免 schema 前缀，并合理设置 BatchSize（推荐 5000～10000）及 BulkCopyTimeout（非每批超时）。
OracleBulkCopy 写不快，基本不是 Oracle.ManagedDataAccess 版本或 .NET 6 本身的问题，而是默认配置 + Oracle 服务端状态没动——光调 BatchSize 和 BulkCopyTimeout 只能缓解表象，真正卡点在数据库侧。
BatchSize 设多少才不崩也不慢
它不是“越大越快”，而是在内存、网络往返、Oracle PGA 消耗之间找平衡点：
- 设太小（如
100）：每百行一次 round-trip，事务开销堆高，实测吞吐可能压不到 500 行/秒 - 设太大（如
50000）：.NET 进程内存飙升，Oracle 端容易报ORA-04030: out of process memory，尤其含CLOB或长文本列时 - 推荐起点：
5000～10000；若单行平均超 2KB（比如含大字段），先降到1000～2000 - 别猜，要试：用相同数据跑三轮（
2000/5000/8000），观察耗时和 GC 压力变化，优先保稳
BulkCopyTimeout 是总超时，不是每批超时
BulkCopyTimeout 控制整个 WriteToServer 调用的生命周期，不是每批提交的等待时间：
- 默认
30秒，百万级数据基本必超时 - 超时抛
OracleException，错误信息里常含ORA-01013: user requested cancel of current operation（注意这不是连接断开） - 设为
0表示无限等待，生产环境禁用；稳妥做法是预估时间 + 缓冲，比如实测 10 万行需 90 秒，就设BulkCopyTimeout = 120 - 中途失败时，已成功提交的批次仍会保留（前提是
BatchSize > 0）
不关索引、不关约束，再调参数也没用
OracleBulkCopy 的瓶颈常在 Oracle 实例上，.NET 侧优化收益有限：
- 必须提前执行
ALTER INDEX idx_name UNUSABLE，导入完再REBUILD；否则每行都触发索引维护，速度降 3～5 倍 - 外键约束要临时禁用：
ALTER TABLE t DISABLE CONSTRAINT fk_name，否则 bulkcopy 会隐式做参照检查 -
DestinationTableName别带 schema，例如用"EMPLOYEES"而非"SCOTT.EMPLOYEES"，避免权限校验延迟 - 确认表是
NOLOGGING模式（建表时指定或运行时ALTER TABLE t NOLOGGING），否则重做日志写满会卡住
空值、类型错配导致静默失败或报错难定位
写入中断但没明显异常？大概率是数据层校验被忽略：
- 目标列为
NOT NULL且无默认值，但DataTable对应列允许DBNull.Value→ 报错"source DataTable中该列为DBNull.Value, but target column is NOT NULL" - 字符串往数字列写（如
"1"后面带不可见字符），或精度溢出（NUMBER(5,2)插入1234.567）→ 报ORA-12899或ORA-01401，但错误只指向第一行，实际坏数据可能在第 999999 行 - 快速定位法：临时把
BatchSize = 1000，配合try/catch捕获OracleException，就能准确定位坏数据所在批次 - 预检建议：导入前用
dt.AsEnumerable().All(r => decimal.TryParse(r["col"].ToString(), out _))检查数值列，别信Convert.ToDecimal的静默截断
真正影响性能的从来不是 .NET 代码怎么写，而是 Oracle 表是否处于“可批量写入”状态——索引、约束、日志模式、schema 前缀、甚至连接字符串里的 Statement Cache Size=0，漏掉任意一项，OracleBulkCopy 就只是个看起来快、跑起来慢的幻觉。
