简介面向 Oracle 数据库负载生成与性能压测场景swingbench 2.6 是可直接部署的完整发行包适合 DBA、架构师及性能测试人员可模拟真实业务压力验证分区、压缩等特性也可用于评估新硬件或存储系统的极限能力。压缩包共含 325 个文件体积约 27.92MB以 129 个 SQL 基准脚本、78 个 Java 核心类、28 个 XML 配置和 14 个 Windows 启动脚本为主另有 jar 依赖库、CSV 样例数据与 TXT 说明文档覆盖配置、启动到结果导出的完整流程SQL 脚本定义负载模型Java 类执行基准逻辑bat 向导脚本则负责快速拉起测试。2.6 新增 JSON 与 TPC-DS 类基准测试提供声明式自定义基准、SQL 查询编辑器、新版图表渲染引擎并加入 SBUtil 与 results2pdf 工具支持连接 Oracle Cloud 做远程压测。所有向导脚本与工具均已打包齐备拿到后可按需选用基准场景快速搭建测试环境并输出可视化报告。目前已有 1260 人学习下载适合深度评测 Oracle 性能或硬件表现的开发与运维人员。1. swingbench2.6.1124.zip 到底是什么为什么压测数据库需要它拿到 swingbench2.6.1124.zip 的人多半是同一个诉求数据库准备上线或扩容想知道这套库到底能扛多少并发、在多高的压力下开始崩溃。SwingBench 就是干这个的一个面向 Oracle 数据库的负载生成与基准测试工具通过模拟订单录入、销售查询这类事务往目标库灌入可控压力把吞吐量、响应时间、连接数等指标量化出来。这个 zip 是 SwingBench 2.6.1 构建版的完整发行包解压即用自带负载定义文件与启动脚本不用自己从零搭一套压测框架。适合 DBA、后端开发、测试工程师和做容量评估的技术同学。下面按我实际跑这套包的经验从环境准备到参数调优讲一遍最后把最常翻车的地方单独列出来。2. 先别急着解压Java 版本、数据库账号和服务名三个前置条件2.1 检查 Java 运行时版本SwingBench 是 Java 应用版本不匹配会在启动前就失败SwingBench 的图形界面、压测引擎、数据生成向导都是 Java 写的zip 解压后没有传统软件的安装过程能不能跑起来完全取决于本机 Java 运行时。常见做法是先打开终端确认默认 Java 版本java -version echo JAVA_HOME$JAVA_HOME输出里看到1.8.0_xx是 Java 8跑 SwingBench 2.6 系列最稳看到11.0.x也可以。但如果机器上装了多个 JDK建议在启动脚本前先手动固定环境变量避免 PATH 里混入旧版本export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH java -version把 Java 版本放在第一步是因为我见过太多现场解压后双击启动脚本没反应或者在终端报UnsupportedClassVersionError最后都定位到 Java 版本不匹配。这个报错说明编译 class 文件的 JDK 比当前 JRE 新升级本机 Java 或换用匹配版本即可。反过来用太新的 JRE 跑老构建偶尔会蹦出NoSuchMethodError这类版本错位的典型问题。给 SwingBench 2.6.1 配 Java 8 或 Java 11是风险最低的选择。2.2 创建一个专用测试账号数据生成需要建表权限别拿管理账号直接跑用 SwingBench 生成测试数据时工具会自动建表、索引、序列涉及一批对象。我习惯先用一个低权限账号做日常连接把管理账号留在数据生成阶段用。创建测试账号的 SQL 大概是这样-- 多租户环境下先切到目标 PDB再创建用户 ALTER SESSION SET CONTAINER ORCLPDB1; CREATE USER sb_demo IDENTIFIED BY Swing#2025; GRANT CONNECT, RESOURCE TO sb_demo; GRANT UNLIMITED TABLESPACE TO sb_demo;为什么要单独建账号而不是用现有账号一是隔离压测结束执行DROP USER sb_demo CASCADE就能把测试表清干净二是权限可控CONNECT解决登录RESOURCE覆盖建表和序列的基础权限UNLIMITED TABLESPACE避免默认表空间配额限制。有些环境不授这个权限数据生成中途会报 ORA-01950。有一点需要特别留意Oracle 12c 之后的多租户架构里如果连接的是 CDB 根库普通用户建对象会报 ORA-65096提示公共用户需要带 C## 前缀。SwingBench 向导在 CDB 里建不了测试 schema必须先通过ALTER SESSION SET CONTAINER切到 PDB或者直接用能连上 PDB 服务名的连接串。如果你的环境是单实例非多租户这段可以忽略。2.3 确认服务名而不是 SID用 tnsping 和一条 sqlplus 先打通连接SwingBench 通过 JDBC 连数据库连接串里填的是服务名service_name而不是 SID。很多“在数据库客户端里能连在 SwingBench 里连不上”的坑都是把两者搞混了。验证连接最简单的方式在命令行先把链路跑通tnsping ORCLPDB1 sqlplus sb_demo/Swing#2025//localhost:1521/ORCLPDB1tnsping能过说明网络和监听端口没问题sqlplus能登录说明账号、密码和服务名都对。到这里SwingBench 需要的三要素——主机名、端口、服务名——就齐了。如果tnsping报 ORA-12541是监听没起来报 ORA-12514是监听在但不知道这个服务名多半是服务名拼错或该服务尚未注册。把这两条命令跑通再碰 SwingBench后面配置连接时就不会反复试错。2.4 解压前先校验 zip 完整性一条命令避开“解压到一半报错”标题既然是个 zip 包完整性的问题就很现实。压缩包从网络下载或从共享目录拷贝过来可能出现文件缺失解压时就会报类似invalid zip archive: could not find eocd的错误。eocd是 zip 格式结尾的目录记录找不到它说明文件被截断或损坏。解压前先校验一遍unzip -t swingbench2.6.1124.zip | tail -5输出No errors detected in compressed data才能放心解压。如果提示某个文件 CRC 校验失败别犹豫重新下载。压缩包校验看似多此一举实际能避免“启动脚本明明在却缺了某个类文件”这种离奇问题。有条件的话再和发布页给出的校验值做个比对双保险。3. 解压、连接配置与数据生成按这个顺序把测试环境立起来3.1 解压后先看目录启动脚本、负载 XML 和配置文件怎么对应解压路径不要带空格和中文这是我在 Windows 上踩过的坑。压缩包里的脚本在拼接路径时对空格很敏感放桌面某个带中文的目录下启动时经常报找不到文件。常见做法是放到纯英文路径mkdir -p ~/swingbench cd ~/swingbench unzip ../swingbench2.6.1124.zip ls -la这套压缩包的目录结构有固定的逻辑bin存放启动脚本包括图形界面和数据生成向导config存放各负载的 XML 定义文件里面描述事务类型、表名和执行权重。启动压测时通过参数指定某个 XML工具就会按照这个文件里定义的事务模型去跑。不同构建版本的目录命名略有差异但整体功能划分一致。这里多提一句zip 这种发行方式和安装包不同解压后不写注册表、不改系统环境变量换机器就是重新拷一份。好处是绿色便携坏处是没人帮你检查 Java 依赖。所以解压完第一件事不是双击图标而是把第 2 章的 Java 和连接校验再做一遍。3.2 用 oewizard 生成 Order Entry 测试表命令、参数和它们的行为SwingBench 自带数据生成向导可以在图形界面点也可以命令行跑。推荐命令行因为可重复执行参数一目了然。Order Entry 负载的数据生成命令大概是cd bin ./oewizard.sh \ -cs //localhost:1521/ORCLPDB1 \ -u system \ -p your_pwd \ -dba \ -tc 4 \ -scale 2 \ -nopart \ -create -drop参数逐个说-cs是连接串格式为//主机:端口/服务名-u和-p是具备管理权限的账号向导要用它创建表空间和 schema一般用 system-dba告诉向导当前账号有 DBA 权限-tc 4把测试表分散到 4 个表空间-scale 2控制数据规模数值越大记录越多生成时间越长-nopart不建分区表适合快速得到一个简化模型-create -drop表示如果存在同名 schema 就先删掉再重建保证可重复执行。-tc的参数选择有个逻辑表空间个数本质上是并行写数据的通道数如果数据库跑在普通云盘上建 4 个表空间未必比 1 个快因为底层就是一张磁盘。我一般先查机器上有几块物理盘再决定-tc设多少。单盘环境直接-tc 2或-tc 1。-scale同理不要一上来就追求大数据量先在 1 或 2 跑通流程再按实际容量评估需求放大。提示不同小版本的工具参数别名可能有差异跑之前可以执行./oewizard.sh -help看一下当前版本支持的写法。3.3 数据生成慢或中途失败先查表空间容量和并行通道数据生成是一个相对漫长的过程尤其订单类大表几百万行数据写下去要等一段时间。中途失败最常见的报错是 ORA-01658无法创建初始区或者 ORA-01653无法在表空间中扩展。两个都是空间问题处理方式一样ALTER TABLESPACE users ADD DATAFILE /u01/oradata/ORCLCDB/sb02.dbf SIZE 8G AUTOEXTEND ON NEXT 512M MAXSIZE 32G;给表空间加一个自动扩展的数据文件是常规操作。但要注意物理磁盘的剩余空间AUTOEXTEND 设了 MAXSIZE 也大不过磁盘容量。另一个常见问题是并行通道开太多-tc 4在 IOPS 一般的磁盘上反而把队列打满。判断方法很简单如果数据库侧磁盘 IO 利用率接近 100%而 CPU 还有富余就是 IO 瓶颈降表空间数量或换更高 IOPS 的存储。失败时的日志也要会看。oewizard 运行时会打印每张表的处理时间如果卡在客户表或订单明细表这种大表上基本就是 IO 问题。先缩-scale到 1 把流程跑通再逐步放大是最稳的节奏。3.4 数据生成后做个快速验证数一下行数再开始压测数据生成完成后别急着开压测先做一次行数抽查确认表和数据的实际状态。用刚才创建的测试账号连接数据库执行SELECT COUNT(*) FROM sb_demo.CUSTOMER; SELECT COUNT(*) FROM sb_demo.ORDER_ITEMS;如果行数为 0 且日志里没有任何报错多半是连接串指向了错误的库或 PDB把数据生成到了别的 schema。行数正常后可以顺便看一眼表的索引是否已经建立SwingBench 的负载脚本会依赖索引来模拟真实查询。确认无误测试库就绪可以进入压测阶段。4. 运行压测图形界面快速看效果命令行进自动化4.1 图形界面适合第一次跑通流程但不适合反复调参图形界面是 Spark 客户端的外壳适合第一次体验。启动方式和刚才一样cd bin ./swingbench.sh界面里要填的就是第 2 章验证过的三要素主机名、端口、服务名再加上测试账号和密码。选择负载类型设置并发用户数点运行界面会实时显示每秒事务数、平均响应时间以及事务提交总量。图形界面能直观建立“压力”的感受但每次改参数都要手动操作不利于做多组对比和回归测试。我一般只在确认环境连通时用它一旦验证能跑通立刻转命令行。4.2 命令行压测的最小命令charbench 的参数与一份可复用脚本命令行压测是 SwingBench 的核心用法通过 charbench 程序执行可以直接放进 CI 流程或定时任务。一个最小可用的命令长这样cd bin ./charbench \ -cs //localhost:1521/ORCLPDB1 \ -u sb_demo -p Swing#2025 \ -uc 20 \ -rt 00:05:00 \ -load ../config/Order_Entry.xml \ -thinktime min \ -a ../output/run_oe_$(date %Y%m%d_%H%M).xml主要参数如下表参数作用说明-cs连接串与 oewizard 格式一致-u -p测试账号用第 2 章创建的 sb_demo-uc并发用户数指同时保持的会话数不是线程数-rt运行时长格式 HH:MM:SS至少 5 分钟起步-load负载定义文件指定跑哪种业务场景 XML-thinktime思考时间策略min 表示连续发压不加随机等待-a输出报告路径XML 格式便于后续解析归档-thinktime值得单独说。不加或设置成 value脚本会在部分请求之间插入随机等待模拟真实用户操作间隙压极限容量时改成 min让事务以最短间隔持续发出。还可以指定每秒钟目标事务数让 charbench 自动调节并发来逼近这个目标。刚开始压测不建议直接拉满先把基本参数跑出基线。4.3 并发、时长和思考时间怎么定三个参数的调参顺序调参要有顺序混在一起乱调出了问题不知道是哪个变量导致的。第一个调-uc从 20 开始逐步到 50、100每档跑 5 分钟观察 TPS。当并发继续增加 TPS 不再上升或者平均响应时间明显恶化这个点就是当前配置下的压力拐点。第二个调-rt。短跑只能看到瞬时吞吐跑 15 分钟以上才能暴露日志切换、回滚段扩展、索引碎片这类长期问题。容量评估场景我习惯至少跑 15 分钟取稳定段的数据作为基线丢弃前几分钟的热身段。第三个调-thinktime。如果目的是摸上限设 min如果目的是观察真实业务形态就设一个合理的随机等待。要注意的是压测对象如果是生产库或共享环境先确认压力会不会误伤其他业务最好错开业务高峰再跑。4.4 一台机器不够时把负载生成器分散到多机单台压测机压大型库时压测端本身会成为瓶颈。SwingBench 支持多个负载生成器注册到同一个控制端把压力摊到多台机器上。操作上先在其他机器启动生成器进程再在图形界面或命令行中把这些节点加入连接池。判断是否需要多机的标准很简单压测过程中压力机 CPU 已经 100%而数据库 CPU 才 20%这时候并发再高也压不到数据库先扩容压力端。5. 避坑与排查解压、连接、数据生成和压测中最常见的五个翻车点5.1 压缩包解压报invalid zip archive: could not find eocd现象执行unzip直接报错或者解压到一半中止解出来的文件缺失。报错里的eocd是 zip 格式的结尾目录记录找不到它说明文件不完整。原因下载被中断或者文件在传输过程中被截断。比如从共享目录拷贝时网络闪断或者浏览器下载到临时文件时就出了问题。解决删除本地文件重新下载下载完先用unzip -t做完整性测试。如果是从另一台机器拷贝建议用二进制模式传输避免换行符被转换后破坏二进制流这是跨平台拷贝压缩包时要提防的旧问题。5.2 启动脚本没反应或报UnsupportedClassVersionError现象执行启动脚本后控制台无输出或者直接抛版本不兼容错误。原因本机 Java 版本缺失或不匹配。SwingBench 2.6 系列要求 Java 8 及以上但有些老构建在过高版本上会出隐藏问题。解决先执行java -version确认实际生效的 Java如果机器有多套 JDK手动修改环境变量把 Java 8 或 Java 11 放到 PATH 最前面。不要凭“系统装了 IDE”就想当然IDE 自带的 JRE 和命令行用的是两套环境。5.3 连接时报 ORA-12514 或 ORA-12541或登录缓慢现象图形界面或命令行填好主机、端口、服务名后连接报“监听器无法识别服务”或“监听器未启动”。原因服务名拼写错误或者填了 SID 而不是 service_name。在多租户环境下也可能是连接到了 CDB 而不是 PDB目标服务名根本没有注册。解决用第 2 章的tnsping和sqlplus先做验证。sqlplus 能连的前提下仔细对比 SwingBench 里填的服务名特别注意大小写和下划线。PDB 环境务必使用可用的 PDB 服务名连接。5.4 数据生成中途报 ORA-01658 或 ORA-01653写不进去数据现象oewizard 跑到一半报无法创建初始区或无法扩展表空间生成进程中断。原因表空间容量不够数据文件已达到上限或者自动扩展被关闭。有时候问题不只在数据库层物理磁盘写入满也会触发类似报错。解决先给账号确认 UNLIMITED TABLESPACE 授权再利用加数据文件的方式扩容。叠加场景下不管 AUTOEXTEND 设多大磁盘物理空间耗尽一样写不进去扩容前先看服务器磁盘余量。数据生成策略上先小 scale 跑通确认空间足够再放大。5.5 压测时数据库不忙压测机 CPU 先打满现象数据库侧的 CPU 使用率不高TPS 也上不去但压测机的 CPU 已经 100%。原因压测机和数据库在同一台机器上或者压测机配置太低Java 压测线程先把资源吃完了。个别情况是并发数设置过高大量线程在争抢连接池。解决把负载生成器挪到独立机器或者启用多个负载节点分摊。压测机 CPU 占用率降到 50% 以下才能认为当前压力真正作用在了数据库上。否则调出来的指标没有参考意义。6. 比 TPS 更值得看的三张表把报告读进等待事件继续调优6.1 从压测报告里记录三个基线值而不只看最终数字一次压测跑完charbench 会生成 XML 报告打开能看到整个过程的吞吐量曲线。我习惯从中提取三个值事务每秒的峰值、稳定段平均值、以及最后 10% 时段与最开始的对比。如果尾段吞吐明显低于头段优先怀疑是不是数据量增长后索引不再适用或临时段出现大量扩展。只记住一个最终数字会掩盖压测过程中的性能退化。6.2 用 v$system_event 把瓶颈从“不确定”变成“看得见”数据库侧有一个视图专门记录等待事件压测结束后查询它能定位瓶颈到底在 IO、日志还是锁上SELECT event, total_waits, ROUND(time_waited / 100 / 60, 2) AS wait_minutes FROM v$system_event WHERE wait_class Idle AND event NOT LIKE DFS% ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY;这块查询里wait_class Idle把空闲等待过滤掉time_waited单位是厘秒除以 100 才是秒再除以 60 转成分钟。看到db file sequential read排在前列说明随机单块读是瓶颈重点看索引设计和存储 IOPSlog file sync高则说明提交路径慢检查日志文件所在磁盘的写延迟出现enq: TX - row lock contention要回看压测并发设计是否存在锁冲突。有了等待事件下一轮压测目标就具体了把某个等待项的耗时压下去再看 TPS 是否同步提升。我早期跑 SwingBench 只盯最后的 TPS 数字拉高并发把库压垮也说不清瓶颈在哪。后来把压测报告和等待事件放在一起看才真正形成“跑测、定位、调参、再跑”的闭环。这个习惯建议你也留一份多轮跑下来你对自己数据库的容量边界会越来越有把握。希望帮到你。本文还有配套的精品资源点击获取