oraclecommand.parameters.add()传入byte[]会触发隐式内存拷贝致oom，应改用oracledbtype.blob配合oracleblob分块读写，并配置validate connection=true、pooling=false、enlist=false，控制缓冲区大小防gc压力。
OracleCommand.Parameters.Add() 传入 byte[] 会触发隐式内存拷贝，大文件直接 OOM
直接把几百 MB 的 byte[] 塞进 OracleParameter.Value，Oracle Data Provider for .NET（ODP.NET）会在内部做完整复制，且不支持流式写入。这不是异步问题，是设计缺陷——参数值被当成“一次性载入内存”的标量处理。
正确做法是用 OracleParameter.OracleDbType 显式设为 OracleDbType.Blob，并配合 OracleBlob 对象或流操作：
- 写入时：先执行 INSERT 返回空 BLOB 定位器（
RETURNING blob_col INTO :blob_out），再用OracleBlob.Write()分块写入 - 读取时：用
OracleBlob.GetStream()拿到可异步读的Stream，再调用CopyToAsync()或ReadAsync() - 必须开启连接的
Enlist=false（避免与分布式事务冲突）和Pooling=false（BLOB 流依赖连接生命周期）
OracleBlob.Write() 不支持 async，但可以用 Task.Run() 包装规避 UI 线程阻塞
ODP.NET 的 OracleBlob 是同步 API，底层调用 Oracle OCI 的 OCILobWrite()。强行在 ASP.NET Core 控制器里同步写 2GB 文件，会吃光线程池资源。
实操建议：
- 对单次写入超过 1MB 的数据，用
Task.Run(() => blob.Write(buffer, offset, count))卸载到后台线程 - 分块大小建议设为 64KB–1MB（太小增加 OCI 调用开销，太大易触发 GC 压力）
- 别用
async void包装——异常无法捕获，改用async Task并 await - 注意：
OracleBlob对象必须在连接打开状态下使用，关闭连接后调用Write()抛InvalidOperationException
读取时用 GetStream() + CopyToAsync()，但要手动控制缓冲区大小防爆内存
OracleBlob.GetStream() 返回的是支持异步读的 Stream，但默认缓冲区是 0x10000（64KB）。如果直接 await stream.CopyToAsync(output)，.NET 会按需分配缓冲区，大文件下可能反复触发 Gen2 GC。
安全写法：
- 显式传入缓冲区数组：
await stream.CopyToAsync(output, bufferSize: 1024 * 1024)（1MB 缓冲） - 确保
output是支持异步写的流（如FileStream打开时带FileOptions.Asynchronous） - 别用
MemoryStream接收超 100MB 的 BLOB——它要求连续内存，容易引发OutOfMemoryException - 读取前检查
blob.Length，避免无限制读（有些 BLOB 实际为空但长度返回 -1）
连接字符串里漏掉 Validate Connection=true，BLOB 流中途断连不报错只卡死
Oracle 连接池复用连接时，若上次使用后数据库侧连接已断（如防火墙超时、DB 重启），ODP.NET 不会主动探测，OracleBlob.GetStream() 可能卡在 ReadAsync() 无限等待。
必须加的配置项：
-
Validate Connection=true：每次从池取连接时发SELECT 1 FROM DUAL探活 -
Connection Timeout=30：防止连接建立阶段挂起过久 -
Self Tuning=true（ODP.NET Core 21.1+）：自动适配高并发下的连接池行为 - 别信连接字符串里的
Pooling=false能解决一切——它只是禁用池，但没解决断连重试逻辑
BLOB 流操作的真正难点不在语法，而在于 OCI 层的连接状态、内存生命周期和分块策略三者耦合。一个没关的 OracleBlob 流就能让连接永远无法归还池子。
