JMeter正确调用Oracle存储过程需严格配置：Query Type选Callable Statement，Query用{call proc(?,?)}格式，Parameter Values与Types须一一对应，Variable Name of Pool必须与JDBC Connection Configuration完全一致。
oracle存储过程压测不是“跑一次看快不快”，而是要控制变量、隔离干扰、看清瓶颈在哪。直接用 jdbc request 调用存储过程，但不配对 callable statement 类型或漏写参数类型，90% 的失败都卡在这一步。
怎么在 JMeter 里正确调用 Oracle 存储过程
关键不在“能不能调通”，而在“调得准不准”——参数绑定、类型声明、连接池复用缺一不可。
-
Query Type必须选Callable Statement，不能选SELECT Statement或Update Statement，否则 Oracle 会报ORA-00900: invalid SQL statement -
Query格式必须是标准的 JDBC Callable 语法：{call schema.package_name.procedure_name(?, ?, ?)}，不能带;，也不能写成EXEC或BEGIN ... END -
Parameter Values和Parameter Types必须严格一一对应，比如VARCHAR2对应java.sql.Types.VARCHAR，NUMBER对应java.sql.Types.NUMERIC；填错类型会导致隐式转换或ORA-01008: not all variables bound -
Variable Name of Pool必须和JDBC Connection Configuration中的Variable Name for created pool完全一致（大小写敏感），否则连接池找不到，报Cannot get connection from pool
为什么并发上不去？重点查这三处
压到 50 线程就卡住，TPS 不涨，大概率不是数据库慢，而是客户端配置或 Oracle 侧资源限制没放开。
- Oracle 侧检查
processes和sessions参数是否足够：比如压测设了 200 并发，processes至少要 ≥ 250（留出后台进程余量） - JMeter 端确认线程组的
Number of Threads是真正生效的——别被“Ramp-Up Period”误导，如果设成 100 秒，实际并发是缓慢爬升的，想看稳态表现，Ramp-Up 应 ≤ 1 秒 - 驱动版本别踩坑：
ojdbc8.jar支持 Oracle 12c+ 的隐式结果集和异步调用，但若压测 Oracle 11g，得用ojdbc6.jar；混用会触发AbstractMethodError或连接静默中断
DBMS_RESOURCE_MANAGER.CALIBRATE_IO 能测存储过程吗
不能。这个存储过程只测底层存储 I/O 能力（IOPS、MBPS、延迟），和 PL/SQL 执行逻辑完全无关。它跑的是裸盘读写，不经过 buffer cache，也不走 SQL 引擎，更不调你的业务 SP。
- 它返回的
max_iops是磁盘阵列理论极限，不是你pkg_order.submit()的 QPS - 想测存储过程真实吞吐，必须走应用层压测（如 JMeter + JDBC）或数据库内建负载工具（如
orastress或HammerDB的 TPC-C 模式） - 如果 CALIBRATE_IO 测出来 IOPS 很低，但你的 SP 压测 TPS 却很高，说明瓶颈根本不在磁盘——可能在锁、解析、PGA 内存或网络往返
最易被忽略的一点：存储过程里如果有 DBMS_OUTPUT.PUT_LINE 或未关闭的游标，在高并发下会迅速耗尽 user_dump_dest 空间或引发 latch 争用。压测前务必清理所有调试输出、显式关闭游标、避免自治事务嵌套过深。
