Oracle连接池与SQL复用不当导致内存泄漏，需限制池大小、统一参数化查询、及时关闭DataReader、优化对象分配并禁用调试日志。
连接池配置不当导致内存持续增长
oracle.manageddataaccess 默认启用连接池，但池大小未限制时，高并发微服务容易积累大量空闲连接，每个连接背后都持有 pga 内存（如 sql 解析上下文、游标缓存）。现象是 oracleconnection 对象数稳定上升，v$session 中 pga_used_mem 持续增加，且 gc 无法回收。
- 在连接字符串中显式设置
Connection Lifetime=60; Min Pool Size=5; Max Pool Size=50;，避免默认无上限的池扩张 - 禁用不必要的特性：添加
Pooling=false仅在极低频调用场景使用（不推荐常规微服务） - 确认连接是否真正释放：必须调用
connection.Close()或用using块，仅Dispose()不足以归还连接到池 - 避免在 DI 容器中注册
OracleConnection为 Singleton——这会强制共享连接，引发线程安全与内存泄漏
参数化查询未复用导致共享池膨胀
即使用了 :param 占位符，若 SQL 文本因拼接逻辑不同而变化（比如动态 WHERE 字段、不同 LIMIT 值直接嵌入字符串），Oracle 会为每种文本生成独立执行计划，塞满 SHARED_POOL。表现为 v$sqlarea 中 PARSE_CALLS 高、EXECUTIONS 低，且 shared_pool 内存使用率缓慢爬升。
- 统一使用命名参数，禁止字符串插值构造 SQL，例如不要写
"WHERE status = '" + status + "'" - 对分页查询，固定用
OFFSET :offset ROWS FETCH NEXT :limit ROWS ONLY，而非拼接LIMIT 10这类硬编码 - 检查
v$sql视图：执行SELECT sql_text, parse_calls, executions FROM v$sql WHERE sql_text LIKE '%your_table%'，若同一逻辑出现多条相似但 hash 不同的语句，就是复用失败
DataReader 未及时关闭引发 PGA 滞留
OracleDataReader 持有服务器端游标（server-side cursor），只要没调用 Close() 或 Dispose()，对应 PGA 内存就不会释放。微服务中常因异常路径遗漏关闭，或异步操作中误用同步读取，导致游标长期驻留。
- 务必用
using包裹OracleCommand和OracleDataReader，双重保障 - 避免在
while (reader.Read())循环内抛出未捕获异常——这会跳过后续reader.Close() - 对流式处理大结果集，启用
FetchSize：设置command.FetchSize = 1000控制每次网络往返的数据量，减少单次 PGA 占用峰值 - 监控指标：查
v$open_cursor，若某会话OPEN_CURSORS_CURRENT持续 > 20，大概率存在 reader 泄漏
结果集映射过度分配托管内存
从 OracleDataReader 读取数据后，若用反射自动映射（如 Dapper 或 EF Core 默认行为）或创建大量临时对象（如 new List<string>[]</string>），会触发 .NET GC 频繁工作，间接加剧 Oracle 客户端内存压力——尤其当行数达万级时。
- 优先用
reader.GetInt32(0)等强类型方法，避免reader.GetValue(0)返回object引发装箱 - 批量读取时，复用对象实例（如预分配
Product[] items = new Product[batchSize]），而非循环new Product() - 对只读场景，考虑用
Span<byte></byte>或ReadOnlyMemory<char></char>直接解析字段，跳过字符串分配 - 禁用
OracleConfiguration.EnableSqlNetTrace = true——调试开启后会产生大量日志缓冲区，微服务中必须关闭
v$open_cursor 的联动关系：一个未关闭的 reader 不仅卡住当前连接，还会让整个连接池里的空闲连接无法被重用，最终触发新连接创建，形成恶性循环。调优必须同时看客户端配置和数据库端视图。
