cx_Oracle 的 executemany() 插入变慢或无限等待，通常并非代码或网络问题，而是数据库行级锁导致——其他会话（如 SQL Developer）未提交事务，使目标行长期处于锁定状态，Python 进程被动阻塞等待。
cx_oracle 的 `executemany()` 插入变慢或无限等待，通常并非代码或网络问题，而是数据库行级锁导致——其他会话（如 sql developer）未提交事务，使目标行长期处于锁定状态，python 进程被动阻塞等待。
在使用 cx_Oracle 进行批量数据插入时，若原本运行正常的 cursor.executemany(query, data) 突然出现长时间无响应（甚至“卡死”），而同一 SQL 在 SQL Developer 中执行迅速，这极大概率是数据库锁竞争问题，而非 Python 代码逻辑或驱动配置错误。
? 根本原因：未提交的事务引发行锁阻塞
当另一个数据库会话（例如你正在使用的 SQL Developer、另一段未关闭的 Python 脚本，或后台应用连接）对目标表执行了 INSERT/UPDATE/DELETE，但尚未执行 COMMIT 或 ROLLBACK，该会话持有的行级锁将持续存在。此时你的 Python 程序尝试插入（尤其是主键/唯一键冲突或更新相同行时）会因等待锁释放而阻塞——executemany() 表现为“假死”，看似无报错、无输出，实则在后台无限期等待。
⚠️ 注意：cx_Oracle.DatabaseError 异常（如你看到的底部提示）往往在锁超时后才抛出（取决于 Oracle SQLNET.EXPIRE_TIME 或客户端 timeout 设置），而默认情况下 Oracle 不主动中断等待，因此你会观察到“一直转圈却无结果”。
✅ 快速诊断与解决步骤
-
立即检查活跃会话
在 SQL Developer 或其他有 DBA 权限的工具中运行以下查询，定位可能的阻塞源：SELECT s1.username || '@' || s1.machine AS blocking_session, s2.username || '@' || s2.machine AS blocked_session, s1.osuser, s1.sid, s1.serial#, s2.sid AS blocked_sid, s2.serial# AS blocked_serial, s1.sql_id, s2.sql_id AS blocked_sql_id FROM v$lock l1, v$session s1, v$lock l2, v$session s2 WHERE s1.sid = l1.sid AND s2.sid = l2.sid AND l1.BLOCK = 1 AND l2.request > 0 AND l1.id1 = l2.id1 AND l2.id2 = l2.id2;
若返回结果，说明存在明确阻塞关系；重点关注 blocking_session 对应的用户和机器。
-
优先尝试手动提交/回滚
- 切换到疑似阻塞的会话（如 SQL Developer 中仍在编辑并执行过 DML 的标签页），立即执行：
COMMIT; -- 或 ROLLBACK;（若确认无需保存变更）
- 再次运行你的 Python 脚本——若插入瞬间完成，即可确认是锁导致的阻塞。
- 切换到疑似阻塞的会话（如 SQL Developer 中仍在编辑并执行过 DML 的标签页），立即执行：
-
若无法定位会话：安全清理法
- 关闭所有非必要的数据库连接工具（SQL Developer、DBeaver、其他 Python 进程等）；
- 等待 1–2 分钟，让空闲连接因超时自动断开（触发隐式 ROLLBACK）；
- 重试 Python 脚本。
-
终极手段（需 DBA 权限且谨慎操作）
如问题持续且影响生产，可终止特定会话（务必提前沟通！）：ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
替换 sid 和 serial# 为上一步查出的阻塞会话 ID（来自 v$session 视图）。
? 预防建议：构建健壮的数据写入流程
- 始终显式管理事务：避免依赖连接关闭自动回滚；在 try...except 后添加 finally: connection.close()，并在关键路径确保 commit() 或 rollback() 明确调用。
-
设置合理的超时（推荐）：在创建连接时启用 timeout 参数，防止无限等待：
connection = cx_Oracle.connect( user="usr", password="pwd", dsn="db", timeout=30 # 单位：秒，超时抛出 cx_Oracle.OperationalError ) - 启用 DML 错误日志（大数据量场景）：使用 FORALL ... SAVE EXCEPTIONS（PL/SQL 层）或 executemany(..., batcherrors=True)（cx_Oracle 8.3+），避免单条失败导致全批中断。
- 监控锁表习惯：开发阶段定期执行锁查询，养成“执行 DML 后立即提交”的操作纪律。
通过以上方法，90% 以上的“cx_Oracle 插入变慢”问题可快速定位并根治——本质不是 Python 性能瓶颈，而是数据库并发控制机制的正常体现。
