OracleBulkCopy不能直接套用SQL Server逻辑，因其非.NET官方类库、不支持自动列映射、不识别DataTable列顺序、对NULL和DATE更敏感，必须显式设置BatchSize=50000、全大写DestinationTableName、ColumnMappings及保持连接独占。
OracleBulkCopy 为什么不能直接用 SQL Server 那套逻辑？
因为 OracleBulkCopy 不是 .NET 官方类库，而是 Oracle 官方提供的 Oracle.ManagedDataAccess.Client 中的类型，且行为和 SqlBulkCopy 差异极大——它不支持自动列映射、不识别 DataTable 的列顺序、默认不启用批量提交，甚至对空值和日期格式更敏感。直接照搬 SQL Server 示例会卡在 ORA-01843: not a valid month 或整批超时。
必须设置的 4 个关键参数
实测百万级导入（如 120 万行）稳定控制在 3~6 秒，前提是以下配置全部到位：
-
BatchSize = 50000：太小（如 1000）导致网络往返过多；太大（如 200000）易触发 Oracle PGA 内存不足，报ORA-04030 -
DestinationTableName必须是全大写（即使表名建模为小写），Oracle 对象名默认大写，否则报ORA-00942: table or view does not exist -
ColumnMappings必须显式添加，且SourceColumn名要和DataTable的ColumnName完全一致（区分大小写），DestinationColumn同样需大写 -
WriteToServer前必须确保连接处于Open状态，且该连接**不能复用**在其他查询中——OracleBulkCopy 会隐式开启 Direct Path 模式，与普通 DML 冲突
DataTable 构造的隐藏陷阱
常见错误是用 DataRow 逐行 Insert 后调用 AcceptChanges()，这会导致 DataTable 内部状态标记为 Unchanged，OracleBulkCopy 读不到数据。正确做法是：
- 创建
DataTable后，用Rows.Add(object[])批量添加，不调用AcceptChanges() - 所有列类型严格匹配目标表：比如 Oracle 的
DATE字段，C# 中必须用DateTime，不能用string或Nullable（null 值需传DBNull.Value） - 避免使用
AutoIncrement列——OracleBulkCopy 不跳过它，会尝试插入 null 导致失败
性能瓶颈常出在 Oracle 服务端配置
客户端调优只是半程，服务端没配好，再快的代码也卡住：
- 确认目标表无非空约束外的触发器（
BEFORE INSERT会强制走常规路径，BulkCopy 失效） - 临时关闭索引（
ALTER INDEX xxx UNUSABLE），导入完成后再重建，比带索引导入快 3~5 倍 - 确保数据库参数
direct_path_lock_wait为FALSE，否则高并发 BulkCopy 可能因锁等待降速 - 如果表有 LOB 字段，必须额外设置
EnableDirectPath = true（默认 false），否则自动回退到慢速模式
真正卡住的往往不是 C# 代码，而是没关触发器、忘了禁用索引，或者用 DataTable 时悄悄把 DateTime 转成了字符串再塞进去。
