OracleBulkCopy是Oracle官方提供的.NET批量写入工具，底层调用Direct Path机制绕过SQL解析和约束检查，百万级数据可10–30秒入库；但需满足四前提：ODP.NET≥19.10、无启用触发器、连接串含Direct Path=true、列名类型严格匹配。
OracleBulkCopy 是什么，它真能比普通 Insert 快？
不是所有“BulkCopy”都一样。OracleBulkCopy 是 Oracle 官方提供的 .NET 数据批量写入工具（属于 Oracle.ManagedDataAccess.Client），底层调用 Oracle 的 SQL*Loader 直接路径（Direct Path）机制，绕过 SQL 引擎解析和约束检查（部分可选），因此在无索引、无外键、无触发器的表上，百万级数据入库通常能压到 10–30 秒。但注意：它不支持 INSERT 触发器、不校验 CHECK 约束（除非显式启用）、也不走事务日志常规路径——这些既是性能来源，也是风险点。
必须满足的 4 个前提条件
缺一不可，否则会报 ORA-29532: Java call terminated by uncaught Java exception 或直接抛 NotSupportedException：
-
Oracle.ManagedDataAccess版本 ≥ 19.10（推荐 21.11+），旧版（如 12c 对应的 12.2.x）不支持OracleBulkCopy - 目标表不能有启用的
ON INSERT触发器；如有，必须先DISABLE TRIGGER - 连接字符串需显式开启 Direct Path：追加
Direct Path=true;（默认是false） - 目标列顺序、类型必须与
DataTable或IDataReader完全一致；列名不匹配不会报错，但数据会错位
最简可用代码 + 关键参数说明
别套用 SqlServer 的写法——OracleBulkCopy 没有 WriteToServer(DataTable) 的重载，必须用 WriteToServer(IDataReader) 或 WriteToServer(DbDataReader)：
using (var connection = new OracleConnection(connStr))
{
connection.Open();
using (var bulk = new OracleBulkCopy(connection))
{
bulk.DestinationTableName = "T_LOG";
bulk.BatchSize = 50000; // 每批提交行数，太大易 OOM，太小降低吞吐
bulk.BulkCopyTimeout = 300; // 超时秒数，大批次务必调高
bulk.ColumnMappings.Add("ID", "ID"); // 必须显式映射，即使名相同
bulk.ColumnMappings.Add("MSG", "MSG");
bulk.WriteToServer(dataTable.CreateDataReader()); // 注意：必须是 IDataReader
}
}
关键点：
-
BatchSize设为 5w 是经验值；实测 10w 在 16GB 内存机器上容易 GC 压力陡增 - 不设
ColumnMappings会静默失败（数据按序写入，但列对不上） -
CreateDataReader()返回的是只读前向游标，不能复用；若需多次写入，每次都要新建
为什么写了百万还慢？常见掉坑场景
速度卡在 1 分钟以上，大概率踩了下面某条：
- 目标表有唯一索引或主键：Direct Path 默认禁用索引维护，写完需手动
ALTER INDEX ... REBUILD；若想边写边建索引，得设bulk.EnableDirectPath = false（但这退化成普通 Insert，速度归零） - 连接字符串漏了
Direct Path=true;—— 此时OracleBulkCopy会降级为逐行 Insert，且不报错 - 源数据含
NULL值，但目标列定义为NOT NULL且无默认值：Direct Path 模式下会直接报ORA-01400并中断整个批次 - 用了
DataTable但没预设Columns.DataType（比如全设成typeof(string)）：Oracle 会把数字/日期当字符串转，触发隐式转换失败
真正要跑满带宽，得关索引、关日志（ALTER TABLE ... NOLOGGING）、关约束、用合适 BatchSize，并确认网络和磁盘 I/O 没瓶颈——这些操作本身就有业务风险，不能无脑套用。
