简介SwingBench 2.6是面向Oracle数据库的负载生成与性能评测工具主要帮助数据库管理员、性能测试工程师以及架构师模拟真实业务压力从而验证分区、压缩等特性在具体场景下的效果或评估新购硬件的处理能力。2.6版本仅支持Java 8运行环境新增了JSON及TPC-DS类基准测试允许用户通过声明式方法创建自定义基准并提供SQL查询编辑器用于构建专属查询同时引入新的图表渲染引擎改进了统计信息采集可估算百分位指标并输出含TPS、CPU与IO读数的统计文件还支持在连接对话框中直接配置Oracle云远程连接。资源包共325个文件主要包含129个SQL脚本、78个Java源文件、35个文本说明、28个XML配置、15个JAR包和14个批处理脚本另有JSON、TPC-DS、OE、SH等各基准的向导入口以及结果转PDF实用工具压缩包整体约27.92MB。目前已有1258人学习/下载整个工具集目录清晰、开箱即用既适合快速开展数据库负载测试也方便深入学习基准构建原理可作为性能测试与数据库特性研究的重要参考资源。 我硬盘里存了不少压测工具但每次给 Oracle 库做上线前验证最常翻出来的还是这个swingbench2.6.1124.zip。它不像商业负载工具那样要装客户端、配 license一个免安装的 zip 包解开就能跑特别适合临时环境快速压一轮。这篇就把我从解压这个包到跑出第一份压测报告的完整流程写出来顺带把我踩过的一些坑和调参经验一并交代。如果你正准备接触 Oracle 压力测试或者手里已经下了这个 zip 包但不确定从哪一步开始这篇文章的思路基本可以照搬。下面我按实际操作顺序来写。1. 这个 zip 包里装的是什么为什么我留了它1.1 一个基于 Java 的数据库负载生成器swingbench2.6.1124.zip解压之后里面是 SwingBench 2.6.x 的完整程序。SwingBench 是 Oracle 生态里用得很多的开源负载生成工具作者是 Dominic Giles核心用途就是模拟大量并发用户对数据库执行不同类型的 SQL 事务从而压出数据库在真实业务负载下的响应时间、吞吐量和资源消耗。它内置了 Order Entry、Sales History、Call Center 等好几种业务模型。以 Order Entry 为例它会自动创建客户、订单、商品等表然后模拟客户下单、查询订单、更新库存这类操作。因为这些表结构和事务逻辑都接近真实系统压测结果比单纯用 shell 循环执行一条 SQL 有说服力得多。1.2 为什么 2.6.1124 这个版本值得保留我最早用的是 2.5 的老包后来换了 2.6 系列。直观感受是连接管理更稳定生成大 schema 时失败率低了不少。2.6.1124 是 2.6 系列里的一个具体构建号从文件名里的 1124 能看出大概的构建日期或修订版本这类包会在兼容现代 JDBC、处理大结果集、命令行参数解析等细节上持续修 bug。另外它是 zip 分发这本身就是个优点。整个工具是纯 Java 写的不依赖系统安装包只要机器上有对应版本的 JDK解压到任意目录就能运行。对于需要在多台测试机间拷贝工具的场景一个 zip 包比一堆安装脚本方便太多。1.3 谁适合用这个工具如果你是 DBA想在新库上线前做一轮容量验证它合适。如果你是运维想对比不同参数配置下数据库的吞吐差异它也合适。如果你是开发想在本地模拟几十个并发连接把应用接口压出瓶颈它同样可以做到。唯一要记住的是SwingBench 生成的是数据库负载不是 HTTP 接口压力别拿它来测 Web 应用。2. 解压之前先把这三件事准备好很多人拿到 zip 包直接双击解压然后运行脚本报一堆错才开始怀疑包有问题。按照我的习惯解压前要花五分钟确认三件事。2.1 检查 JDK 环境SwingBench 是 Java 程序启动必须要有 JRE/JDK。我建议直接装 JDK 1.8 或更高版本而不是只装一个精简 JRE因为后面如果要用它连接不同数据库版本可能还需要补充驱动类。先打开终端确认java -version如果提示 command not found要先把 JDK 的 bin 目录加到 PATH并确认JAVA_HOME指向正确目录。我这里见过一个坑装了 JDK 17但 PATH 里先匹配到了系统的旧 JRE导致 SwingBench 启动时直接报 UnsupportedClassVersionError排查半天才发现是版本混用。另外如果是 64 位操作系统尽量用 64 位 JDK。SwingBench 默认给 JVM 分配的内存可能不算大但压测过程中会产生不少缓存对象32 位 JVM 在大堆内存下容易出问题。2.2 验证 zip 包完整性这一步看似多余实际非常关键。网络下载中断、存储介质故障都会导致 zip 文件尾部数据缺失。解压时最典型的表现就是invalid zip archive: could not find eocdEOCD 是 zip 压缩包末尾的 End Of Central Directory 记录相当于整个压缩包的目录索引。如果这个块找不到了大部分解压工具会直接放弃少数工具能用暴力扫描重建索引但恢复出来的文件也可能有损坏。与其事后折腾不如下载完先做个校验。在没有官方校验值的情况下我会先看文件大小是否和网页标注一致再跑一个测试式解压unzip -t swingbench2.6.1124.zip这条命令会逐个检查压缩包内的文件 CRC 校验值只要输出里没有 error基本可以放心解压。Windows 上可以用 7-Zip 打开后选「测试」按钮效果一样。2.3 准备好数据库用户和连接串压测之前数据库端至少要有一个专门的用户。我习惯用独立用户不让压测事务和目标业务账号混在一起。最简单的授权方式create user sb identified by sb; grant connect, resource to sb; alter user sb default tablespace users quota unlimited on users;这里resource角色包含了建表、建存储过程等权限足够 SwingBench 建 schema 用。如果数据库版本是 12c 以上的 CDB要确认连接的是 PDB 还是 CDB通常建议连到 PDB 做压测避免影响整个实例的公共对象。连接串你也要提前想好。SwingBench 支持使用 Oracle Thin JDBC 连接串例如jdbc:oracle:thin:127.0.0.1:1521/ORCLPDB1这里的/ORCLPDB1是 service_name不是 SID。如果你从老的 tnsnames 里抄来一个ORCL当成 service_name 填进去后面大概率会碰到 ORA-12514。3. 解压之后先摸清目录和配置文件3.1 解压命令和目录布局Linux/macOS 下执行unzip swingbench2.6.1124.zipWindows 右键解压即可注意解压路径不要带中文和空格否则个别依赖脚本解析路径容易绕弯路。解压完成后会看到一个类似swingbench2.6的顶层目录里面常见的几个子目录bin存放可执行脚本包括主程序swingbench、schema 生成工具sso等。lib所有 Java 依赖库包括 Oracle JDBC 驱动。configs内置的测试场景 XML 配置OrderEntry.xml、SalesHistory.xml 等都在这里。docs版本说明和简单文档。samples示例脚本和报告模板。在 Linux 上运行之前给脚本加一下执行权限chmod x bin/*3.2 关键配置文件 OrderEntry.xmlconfigs/OrderEntry.xml是 Order Entry 场景的完整定义里面会写清楚要建哪些表、数据规模、事务混合比例、每个事务包含的 SQL 语句等等。第一次使用建议不要直接改原文件先复制一份cp configs/OrderEntry.xml configs/OE_my_test.xml需要调整数据量时重点关注里面和scale相关的参数或者在生成 schema 时用命令行参数传入。通常默认的 scale 就已经能在一个普通测试库上跑出比较明显的负载不需要一上来就把数据量拉到几十个 G压测不是装数据竞赛重点是观察资源曲线和延迟变化。4. 第一次跑通压测命令行完整实战4.1 用 sso 生成测试 Schema第一次使用先要生成场景对应的表结构和数据。SwingBench 里做这件事的是bin/sso。命令大致长这样bin/sso -c configs/OE_my_test.xml \ -u sb -p sb \ -cs jdbc:oracle:thin:127.0.0.1:1521/ORCLPDB1 \ -createschema这里-c指定配置文件-u和-p是数据库用户-cs是连接串-createschema表示创建用户对象和数据。如果一切正常终端会打印建表、创建索引、生成数据的过程耗时从几分钟到几十分钟不等取决于数据规模。如果之前已经建过 schema想重新建先加-drop相关参数把旧对象清掉具体参数以bin/sso -help输出为准。我吃过一次亏直接在已有 schema 上跑-createschema报了一堆对象已存在最后干脆 drop user 重建。4.2 启动负载并控制并发和时长Schema 准备好之后用主程序bin/swingbench跑负载。假设并发 25 个用户运行 5 分钟bin/swingbench -c configs/OE_my_test.xml \ -u sb -p sb \ -cs jdbc:oracle:thin:127.0.0.1:1521/ORCLPDB1 \ -uc 25 -rt 5常用参数里-uc是并发连接数-rt是运行分钟数-t控制用户思考时间-load表示直接进入负载模式-v打印详细输出。没有加-ui的情况下程序默认可以用简单文本界面展示实时指标。你也可以先看一眼bin/swingbench -help不同 2.6 小版本的参数略有差异以实际输出的帮助为准。跑起来之后终端会滚动显示每秒事务数、平均响应时间、错误率等。如果这些数值一直在稳定波动说明压测正在正常进行。4.3 如何判断这轮压测是否有效压测结束前一定要关注两件事错误率是否为零或极低资源使用是否已经达到预期。错误率如果一直升高多半是并发太高导致锁竞争、ORA-00060 死锁或者会话被 kill此时生成的 TPS 数字再漂亮也没有参考价值。我习惯同时开一个终端用top或sar看数据库服务器 CPU 使用率。如果 CPU 都打不满TPS 就遇到了瓶颈说明瓶颈可能在会话并发、锁等待或者应用的连接池而不是数据库本身。5. 我实际踩过的几个坑每个都能卡半天5.1 ORA-12514连接串里的服务名对不上这是一个非常常见的报错Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested原因就是连接串里的 service_name 和数据库实际注册的服务名不一致。排查方式很简单先在数据库服务器上执行lsnrctl status看输出里Service部分有哪些名字再从你本机用tnsping或最简单的 SQLPlus 连一下确认。如果确认是 PDB连接串必须是jdbc:oracle:thin:host:1521/pdb_service_name而不能用 SID 的写法:host:1521:SID。Thin 驱动对这两者的区分很严格。5.2 建 Schema 时报权限不足或表空间配额超限有时你会看到 ORA-01950no privileges on tablespace。grant connect, resource只给了权限但没有给表空间配额用户在默认表空间里没有写入权限。解决办法就是我在前面说的alter user sb quota unlimited on users;压测用的表空间最好是独立创建的大空间千万别往system表空间里写否则可能把系统表空间撑爆。生产环境压测尤其要检查这一点。5.3 zip 包解压报 invalid zip archive怎么处理如果解压时遇到这类报错第一反应不应该是去找修复工具而是删除本地文件重新下载。网络传输导致的位翻转不会只坏一个文件硬用压缩软件扫描恢复可能得到一堆能打开、但运行就报 class 加载错误的 Java 类文件。下载时可以换一个网络环境或者用支持断点续传的下载工具。下载完成后严格按照 2.2 的方法跑一遍完整性测试确认无错误再解压。这里还有个细节下载服务器如果开了 CDN不同节点拿到的文件可能哈希不一致所以同一个 zip 包最好从官方或镜像源下载不要把别人网盘转存的包直接拿来用。5.4 无图形界面的 Linux 环境跑不出图表SwingBench 自带一个图形监控界面在本地 Windows 上双击就能看到图表。但很多测试机器是无桌面环境的 CentOS直接运行图形界面会报java.awt.HeadlessException。解决办法有两个一是不用图形界面纯命令行模式跑最后保存结果文件分析二是给这台机器配置 X11 转发或者用 VNC 远程开桌面。我实际更推荐前者命令行模式输出稳定、资源开销小也方便后续自动化。6. 让压测结果更有参考价值的几条经验6.1 第一次跑的数据不要直接当结论任何 Java 应用都有 JVM 类加载、连接池初始化和数据文件冷热缓存的问题。SwingBench 也一样刚启动的前一两分钟TPS 通常比较低响应时间偏高后面才逐步稳定。所以我每次都会先跑一个短任务做预热5 分钟热完再正式跑 10 分钟拿数据。否则你会发现第一分钟的平均延迟高得离谱容易误判系统能力。6.2 并发从低到高慢慢加找拐点不要一上来就用 500 并发把库打挂。好的做法是一组一组试10、25、50、100、200每次运行固定时长记录 TPS 和平均延迟。你会发现 TPS 前期基本随并发线性增长到某个点后增长放缓再往后甚至下降。这个拐点就是当前配置下数据库的合理工作区间比单次暴力压测有意义得多。我自己的经验是SwingBench 自带的 OrderEntry 场景对资源消耗比较大如果只测连接能力和基础吞吐可以调整事务配置或减少并发先用小规模跑通链路再逐步提升。6.3 把每次压测的环境信息和结果归档跑完一轮测试除了屏幕上的滚动数字最好用参数生成一份输出文件。SwingBench 可以指定输出文件格式具体参数查阅命令帮助。我习惯把输出文件按「场景_并发_日期」命名和当时的数据库参数、服务器 CPU/内存信息放在同一个目录。这样做的好处是下次换个参数再压测时可以快速对比前后两轮的曲线差异而不是靠记忆里一个模糊的 TPS 数字下结论。压测这个活对比数据比单次数据重要得多。最后再分享一个我的小习惯每次拿到新的 SwingBench zip 包我都会先在本地解压并完整生成一次 OrderEntry schema确认 JDK、驱动、数据库连接全部正常再放上测试机。这样做看起来多花了几分钟但能在真正压测的时候省下大量排查时间。工具本身是免安装的但环境准备这个环节永远不值得省。本文还有配套的精品资源点击获取