oraclebulkcopy比普通insert快得多，因其绕过sql解析、约束检查、触发器和逐行日志写入，直接通过direct path api将内存数据流写入数据文件，避免参数绑定与往返开销。
OracleBulkCopy 为什么比普通 Insert 快得多
OracleBulkCopy 是 Oracle 官方提供的批量导入工具，底层绕过 SQL 解析和事务日志逐行记录，直接将内存数据流写入数据文件（类似 Oracle 的 SQL*Loader）。它不走常规 ADO.NET 命令执行路径，因此避免了参数绑定、语句编译、约束逐行检查等开销。实际测试中，10 万行数据插入，通常比 INSERT INTO ... VALUES 循环快 5–20 倍，前提是表结构简单、无触发器、无外键级联。
但注意：OracleBulkCopy 不是万能加速器——它只支持“追加写入”，不支持 UPDATE/UPSERT；也不校验主键/唯一约束（失败时整批报错）；且要求目标表必须已存在。
用 OracleBulkCopy 的最小可行代码长什么样
核心步骤就三步：准备 DataTable 或 IDataReader，创建 OracleBulkCopy 实例，调用 WriteToServer。以下是最简可用示例：
using (var conn = new OracleConnection(connectionString))
{
conn.Open();
using (var bulk = new OracleBulkCopy(conn))
{
bulk.DestinationTableName = "MY_TABLE";
bulk.BatchSize = 10000;
bulk.WriteToServer(dataTable); // dataTable 列名/顺序需与目标表严格一致
}
}
关键点：
-
DestinationTableName必须是真实存在的表名（区分大小写，若建表时用了双引号，则此处也得带引号，如"MyTable"） -
BatchSize设为 5000–20000 较稳妥；设太小会增加批次开销，太大可能触发内存或 ORA-04030 错误 -
dataTable的列顺序必须和目标表物理列序一致（不是按列名匹配！），否则值会错位——这是最常踩的坑 - 如果源数据来自查询，优先用
OracleCommand.ExecuteReader()直接传IDataReader，避免把全部数据先加载进内存
ORA-01403 / ORA-00942 等常见错误怎么定位
批量失败时，OracleBulkCopy 默认只抛出顶层异常，不告诉你哪一行、哪一列出问题。典型错误及对策：
-
ORA-00942: table or view does not exist→ 检查DestinationTableName是否拼错，是否漏了 schema（如应写"SCOTT"."EMP"而非仅"EMP"） -
ORA-01403: no data found→ 多半是DataTable为空，或DataReader已被读完（调用过Read()到末尾） -
ORA-01722: invalid number→ 某列数据类型不匹配，比如目标列为NUMBER，但传了空字符串或含逗号的数字字符串（如"1,234"） -
ORA-01438: value larger than specified precision allowed for this column→ 字符串长度超VARCHAR2定义，或数值精度超NUMBER(5,2)范围
调试建议：先用极小数据集（3 行）测试；开启 bulk.EnableStreaming = true 可减少内存占用；对可疑列，提前用 DataTable.Columns[i].DataType 和目标表 ALL_TAB_COLUMNS 对比类型。
性能还能再压榨吗：几个硬核配置项
默认配置够用，但高吞吐场景下这几个属性值得细调：
-
bulk.BatchSize：控制每次提交行数，影响 redo 日志压力和锁持有时间；生产环境建议从 5000 起调，观察 AWR 中 “log file sync” 等待事件 -
bulk.BulkCopyTimeout：默认 30 秒，大批量时务必加大（如 600），否则超时直接中断整个批次 -
bulk.ColumnMappings：当源列名/顺序与目标表不一致时必须显式映射，例如bulk.ColumnMappings.Add("SrcName", "TGT_NAME")；不设则按位置严格一一对应 -
bulk.NotifyAfter+SqlRowsCopied事件：用于进度反馈，但事件回调本身有开销，高频触发（如每 10 行）反而拖慢速度，建议设为 1000 或更高
真正容易被忽略的是字符集处理：如果数据库是 AL32UTF8，而你的 C# 字符串含 emoji 或生僻汉字，确保连接字符串里明确指定 Unicode=true，否则可能静默截断或乱码入库。
