PL/SQL匿名块不能用于压力测试，因其仅支持单会话串行执行，无法模拟多连接、多事务并发场景，无法触发锁等待、latch竞争、buffer busy waits等真实并发瓶颈。

直接用 pl/sql 匿名块做压力测试，本质是“单会话串行执行”，根本压不出并发效果——它连 dbms_scheduler 或操作系统级进程都调不动，更没法模拟真实用户连接数激增的场景。

为什么匿名块不能当压力测试工具用

PL/SQL 匿名块在 SQL*Plus 或 SQL Developer 里运行时，始终绑定在当前数据库会话中。哪怕你写个循环跑 1000 次 INSERT，它也只是单线程、单事务上下文、共享同一套游标和 PGA 内存，完全绕不开 Oracle 的会话隔离机制。

• 看不到锁等待、latch 竞争、library cache pin 这类典型并发瓶颈
• DBMS_LOCK.SLEEP 延时只能阻塞当前会话，无法制造跨会话资源争用
• 所有语句走的是硬解析/软解析路径，但不会触发 shared pool fragmentation 或 cursor_sharing 相关问题
• 执行计划缓存、buffer busy waits、read by other session 等指标全无参考价值

真要压并发，必须脱离 PL/SQL 单一会话模型

Oracle 压力测试的核心是“多连接 + 多事务 + 可控节奏”。PL/SQL 自身不提供并发控制能力，得靠外部工具驱动多个独立会话：

• Swingbench：Java 写的开源工具，支持 OLTP、Order Entry、PCB 等多种负载模型，能配置用户数、思考时间、事务混合比，结果带响应时间分布和吞吐量图表
• orabm：轻量级命令行工具，专注 CPU/内存压力，通过 orabmload 启动多进程加载数据，再用 orabm 本身发起并发事务，要求 db_cache_size > 200M 避免 I/O 干扰
• 自建脚本：用 Python + cx_Oracle 或 Java + JDBC 启多个线程，每个线程建立独立连接，执行预编译的 PL/SQL 存储过程（比如 pkg_order.submit），再统一收集 v$session_event 和 AWR 快照

如果非要用 PL/SQL 辅助压测，只适合这三类场景

把 PL/SQL 当作“负载逻辑封装器”，而非“并发控制器”：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

• 封装标准事务体：写一个带完整 commit/rollback 的存储过程 proc_test_transaction，供 Swingbench 或 JDBC 调用，确保每次事务行为一致
• 构造测试数据：用 FORALL + 批量绑定插入百万级测试记录，避免单条 INSERT 的网络开销干扰后续压测
• 清理与校验：压测前后调用 proc_cleanup_test_data 清空临时表，或用 SELECT COUNT(*) 校验事务完整性，这类操作本身不参与并发施压

真正卡住性能的从来不是 PL/SQL 语法快慢，而是多会话同时访问相同数据块、索引叶节点、undo segment 时引发的争用。这些只有让几十上百个独立连接真实跑起来，才能暴露出来。