如何高效分块读写.NET中的Oracle BLOB大对象？
- 内容介绍
- 文章标签
- 相关推荐
本文共计807个文字，预计阅读时间需要4分钟。
相关专题：
Oracle BLOB太大，直接GetBytes()抛OutOfMemoryException怎么办
oracle的blob字段存gb级文件时，.net的oraclecommand.executescalar()或oracledatareader.getbytes()会尝试一次性加载全部字节到内存，极易触发outofmemoryexception。这不是连接问题，是设计使然——getbytes()底层仍走内存缓冲。
必须改用流式分块读写，绕过内存峰值。核心是：不用byte[]承载全文，改用Stream逐段搬运。
- 读取时，调用
OracleBlob.GetStream()获取可读流（注意：需保持OracleConnection打开） - 写入时，先插入空BLOB（
EMPTY_BLOB()），再用OracleBlob.SetStream()写入 - 务必手动控制
Buffer大小，推荐8192~65536字节；太小IO频繁，太大仍占内存
用OracleBlob.GetStream()读BLOB时连接被意外关闭
OracleBlob.GetStream()返回的流强依赖底层OracleConnection状态。一旦连接Dispose、Close或超时断开，再读流就会抛InvalidOperationException：“The connection is closed.”
- 不能在
using (var conn = new OracleConnection(...))块内获取流后离开作用域 - 正确做法：连接保持打开，流读完再关；或用
OracleBlob.CopyTo()配合MemoryStream做中转（仅限中小文件） - 生产环境建议封装为异步方法，用
await stream.ReadAsync(buffer, 0, buffer.Length)并配合CancellationToken防卡死
写入大BLOB时用SetStream()失败，报ORA-22288: file or LOB operation failed
这个错误常出现在未正确初始化BLOB字段就调用SetStream()。Oracle要求BLOB列必须先有非NULL值（哪怕是空BLOB），否则OracleBlob对象无法定位物理位置。
- 插入前必须用
EMPTY_BLOB()占位：INSERT INTO t (id, blob_col) VALUES (:id, EMPTY_BLOB()) RETURNING blob_col INTO :blob_out -
RETURNING子句必不可少，用于获取刚生成的OracleBlob引用 - 写入前检查
oracleBlob.IsOpen是否为true；若为false，需调用oracleBlob.Open(OracleBlobOpenMode.ReadWrite) - 写入完成后必须调用
oracleBlob.Close()，否则事务提交可能失败
.NET 6+ 中Oracle.ManagedDataAccess的ChunkSize配置陷阱
新版驱动支持OracleConnection.ConnectionString里加ChunkSize=32768，但该参数**仅影响内部LOB传输批次，不改变GetStream()行为**。很多人误以为设了它就能自动分块读，结果还是OOM。
-
ChunkSize只对OracleParameter.Value直接赋byte[]时生效，对流式操作无效 - 真正可控的分块逻辑必须自己实现：循环
stream.Read(buffer, 0, buffer.Length)，每次处理buffer实际读取长度 - 注意
OracleBlob的Length属性可能不准（尤其未提交事务时），优先用stream.Length或外部已知大小
分块读写的本质不是“怎么切”，而是“谁来管生命周期”。OracleBlob对象、Connection、Stream三者生命周期必须对齐，漏掉任何一个Close()或提前Dispose()，都会在看似无关的位置崩掉。
本文共计807个文字，预计阅读时间需要4分钟。
相关专题：
Oracle BLOB太大，直接GetBytes()抛OutOfMemoryException怎么办
oracle的blob字段存gb级文件时，.net的oraclecommand.executescalar()或oracledatareader.getbytes()会尝试一次性加载全部字节到内存，极易触发outofmemoryexception。这不是连接问题，是设计使然——getbytes()底层仍走内存缓冲。
必须改用流式分块读写，绕过内存峰值。核心是：不用byte[]承载全文，改用Stream逐段搬运。
- 读取时，调用
OracleBlob.GetStream()获取可读流（注意：需保持OracleConnection打开） - 写入时，先插入空BLOB（
EMPTY_BLOB()），再用OracleBlob.SetStream()写入 - 务必手动控制
Buffer大小，推荐8192~65536字节；太小IO频繁，太大仍占内存
用OracleBlob.GetStream()读BLOB时连接被意外关闭
OracleBlob.GetStream()返回的流强依赖底层OracleConnection状态。一旦连接Dispose、Close或超时断开，再读流就会抛InvalidOperationException：“The connection is closed.”
- 不能在
using (var conn = new OracleConnection(...))块内获取流后离开作用域 - 正确做法：连接保持打开，流读完再关；或用
OracleBlob.CopyTo()配合MemoryStream做中转（仅限中小文件） - 生产环境建议封装为异步方法，用
await stream.ReadAsync(buffer, 0, buffer.Length)并配合CancellationToken防卡死
写入大BLOB时用SetStream()失败，报ORA-22288: file or LOB operation failed
这个错误常出现在未正确初始化BLOB字段就调用SetStream()。Oracle要求BLOB列必须先有非NULL值（哪怕是空BLOB），否则OracleBlob对象无法定位物理位置。
- 插入前必须用
EMPTY_BLOB()占位：INSERT INTO t (id, blob_col) VALUES (:id, EMPTY_BLOB()) RETURNING blob_col INTO :blob_out -
RETURNING子句必不可少，用于获取刚生成的OracleBlob引用 - 写入前检查
oracleBlob.IsOpen是否为true；若为false，需调用oracleBlob.Open(OracleBlobOpenMode.ReadWrite) - 写入完成后必须调用
oracleBlob.Close()，否则事务提交可能失败
.NET 6+ 中Oracle.ManagedDataAccess的ChunkSize配置陷阱
新版驱动支持OracleConnection.ConnectionString里加ChunkSize=32768，但该参数**仅影响内部LOB传输批次，不改变GetStream()行为**。很多人误以为设了它就能自动分块读，结果还是OOM。
-
ChunkSize只对OracleParameter.Value直接赋byte[]时生效，对流式操作无效 - 真正可控的分块逻辑必须自己实现：循环
stream.Read(buffer, 0, buffer.Length)，每次处理buffer实际读取长度 - 注意
OracleBlob的Length属性可能不准（尤其未提交事务时），优先用stream.Length或外部已知大小
分块读写的本质不是“怎么切”，而是“谁来管生命周期”。OracleBlob对象、Connection、Stream三者生命周期必须对齐，漏掉任何一个Close()或提前Dispose()，都会在看似无关的位置崩掉。