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 当作“负载逻辑封装器”，而非“并发控制器”：
- 封装标准事务体：写一个带完整 commit/rollback 的存储过程
proc_test_transaction，供 Swingbench 或 JDBC 调用，确保每次事务行为一致 - 构造测试数据：用
FORALL+ 批量绑定插入百万级测试记录，避免单条INSERT的网络开销干扰后续压测 - 清理与校验：压测前后调用
proc_cleanup_test_data清空临时表，或用SELECT COUNT(*)校验事务完整性，这类操作本身不参与并发施压
真正卡住性能的从来不是 PL/SQL 语法快慢，而是多会话同时访问相同数据块、索引叶节点、undo segment 时引发的争用。这些只有让几十上百个独立连接真实跑起来，才能暴露出来。
