Delphi 11+UniDAC程序内存持续增长问题排查求助

关于UniQuery关闭与对象释放的内存回收问题 #

• 关闭UniQuery时，理论上会释放其内部缓存的数据集内存，但如果关联的UniConnection仍保持活跃、存在未提交事务，或是驱动层面的缓存未清理，可能不会完全释放内存。
• 手动调用Free释放UniQuery对象后，只要没有循环引用，Delphi内存管理器应回收其占用的内存。但DevArt组件可能存在Oracle客户端OCI缓存这类驱动级别的内存占用，这类内存Delphi本地内存检测工具（如Deleaker）无法捕获。

排查方向 #

1. UniDAC数据获取模式检查
   • 若当前使用fmAll模式（一次性拉取所有记录），700万条数据会直接加载到内存，必然导致内存暴涨。需改为fmOnDemand或其他非全量拉取模式，控制每次从Oracle读取的记录数。
   • 确认UniQuery.FetchRows属性值，建议设为1000~5000，限制单次拉取的记录数量。
2. 事务提交策略检查
   • 写入MSSQL时若长期不提交事务，MSSQL的事务日志、缓存会持续占用内存，同时UniDAC的写入缓存也无法释放。必须每处理固定数量的记录就执行一次Commit，避免将全量数据放入一个大事务。
3. 驱动级缓存清理
   • Oracle客户端OCI存在会话级缓存，即使关闭UniQuery也不会立刻释放。可在批次处理完成后，调用UniConnection.OracleSpecific.PurgeCache清理驱动缓存。
   • 检查UniConnection.ConnectionOptions，若不需要连接池，关闭Pooling选项，避免连接池保留会话导致内存占用。
4. 内存管理器行为验证
   • Delphi默认内存管理器释放小块内存后，可能不会立刻归还操作系统，而是保留在进程内存池供后续使用，这会让任务管理器显示的内存占用居高不下，但实际程序可用内存充足。可更换第三方内存管理器（如FastMM4）并开启调试模式，确认是否存在真的内存无法回收问题。
5. 字段处理细节优化
   • 频繁用+拼接字符串会产生大量临时对象，导致内存碎片，建议改用TStringBuilder处理字符串拼接。
   • 避免循环内频繁调用FieldByName，提前获取字段对象引用并重复使用，减少对象创建开销。

具体解决方案 #

• 分批读取+分批提交
  1. 对Oracle查询做分页处理，用ROWNUM（Oracle 11g及以下）或FETCH NEXT ... ROWS ONLY（Oracle 12c+）语法，每次读取固定数量的记录（如1万条），处理完成后再拉取下一批。
  2. 写入MSSQL后立即执行Commit，再调用UniQuery.Close; UniQuery.Free;（或至少Close+Clear），重新创建查询对象处理下一批数据。
• 调整UniDAC关键设置

  // 设置按需拉取数据，单次拉取1万条
  UniQuery1.FetchMode := fmOnDemand;
  UniQuery1.FetchRows := 10000;
  // 清理Oracle驱动缓存
  UniConnection1.OracleSpecific.PurgeCache;
  

• 批量写入替代单条插入
  不要循环执行单条INSERT，改用UniDAC的BatchMove组件，或构造批量INSERT语句（INSERT INTO ... VALUES (...), (...), ...），减少数据库交互次数，降低内存占用。
• 精准监控内存使用
  调用GetProcessMemoryInfo等API获取进程私有字节数，而非仅依赖任务管理器的工作集数据，确认内存是真的无法释放，还是内存管理器池化导致的表象。

内容的提问来源于stack exchange，提问作者G Bradley MacDonald