ODP.NET连接池异常：OracleDataAdapter.Fill()触发ORA-01000游标耗尽

核心逻辑：连接池复用导致游标泄漏累积 #

ODP.NET连接池的本质是复用物理连接，而非每次创建新连接。你的代码虽按规范释放了顶层资源，但可能存在隐性的游标泄漏：

• 若OracleCommand、OracleDataReader等对象未通过using语句或显式Dispose()释放，这些对象绑定的游标会残留在连接池的物理连接上。当连接被复用后，游标持续累积，直到触及数据库open_cursors阈值。
• 连接阶段仅从池中取出连接，不会触发游标检查；而OracleDataAdapter.Fill()执行时，会触发ODP.NET内部的递归SQL（比如元数据查询、会话初始化逻辑），此时游标数已达上限，就会在Fill阶段抛出异常，而非连接阶段。

关联现象的深层原因 #

• 关闭连接池无错误：关闭连接池后，每次请求都会创建新物理连接，连接释放时Oracle会自动清理所有关联游标，无累积泄漏。
• 调大Min Pool Size仅延迟错误：更大的最小空闲连接数意味着初始阶段有更多未累积游标的连接可用，游标达到阈值的速度变慢，但只要复用的连接存在泄漏，最终仍会触发异常。
• 第9次后恢复正常：异常触发后，ODP.NET会将该故障连接标记为无效并移出连接池，后续请求会创建新的无泄漏连接，因此暂时恢复正常——但随着新连接被复用，游标会再次累积，未来仍可能复发。

验证与修复建议 #

• 强制用using语句包裹所有数据库对象，确保资源被彻底释放：

  using (var conn = new OracleConnection(connectionString))
  {
      conn.Open();
      using (var cmd = new OracleCommand(sqlText, conn))
      {
          using (var adapter = new OracleDataAdapter(cmd))
          {
              adapter.Fill(resultTable);
          }
      }
  }
  

• 查询数据库open_cursors参数值（执行SHOW PARAMETER open_cursors），确认是否符合业务需求，但这仅为临时缓解，核心是修复游标泄漏。
• 若启用了ODP.NET的Statement Cache Size，需确保命令对象已正确释放，否则缓存会加剧游标泄漏。

内容的提问来源于stack exchange，提问作者mxcolin