简介：SwingBench 2.6.1124 是一款简单易用的 Oracle 数据库负载生成工具，面向 DBA、开发人员与架构师，可用于压力测试、功能验证（如分区、压缩特性）及新硬件性能评估，是数据库性能调优与容量规划的有力助手。整包共含 325 个文件，大小约 27.92MB，其中 SQL 脚本多达 129 个，用于基准测试数据集生成与查询；78 个 Java 文件便于二次开发与源码学习；另有 bat 启动脚本、jar 依赖库、XML 配置等，可快速运行各向导。2.6 版本亮点包括新增 JSON 和 TPC-DS 基准测试、用户自定义基准的声明式配置、SQL 查询编辑器、新图表渲染引擎，并附带结果转 PDF 工具与集群监控等功能。目前已有 1258 人学习下载，适合需要模拟真实负载、评估数据库特性或验证硬件性能的 Oracle 技术人员，可帮助读者快速搭建测试环境并产出规范的压力测试报告。 干数据库压测这行的人，迟早会碰上一个叫 SwingBench 的工具。我最近在给一套 Oracle 19c 环境做上线前的容量评估，翻出 swingbench2.6.1124.zip 这个压缩包时，发现很多朋友对它还是停留在“听说过、没跑过”的阶段，甚至有人下载完解压就卡住了。今天把这套工具的安装、配置、跑压测、看结果完整梳理一遍，希望能帮到正准备做数据库基准测试的 DBA 和性能测试工程师。
SwingBench 是一个专门针对 Oracle 数据库的开源负载生成工具，可以用来模拟 OLTP、OLAP、Data Warehouse 等不同类型的工作负载，最典型的场景就是数据库迁移前的评估、POC 验证、版本升级后的回归对比，以及上线前的容量规划。它提供图形界面、命令行和无头三种模式，2.6.1 是目前比较稳定的版本，整个工具通过 ZIP 包分发，跨平台、免安装，解压就能用。
1. SwingBench 2.6.1 是个什么工具，为什么用 ZIP 分发
1.1 项目背景与定位：一个“免费但专业”的 Oracle 压测工具
SwingBench 最初由 Oracle 性能工程团队的高级架构师 Dominic Giles 开发，后来开源在 SourceForge 上持续维护。它的定位非常精准：只做 Oracle 数据库的负载模拟，不贪多不图全。所以跟 JMeter、Sysbench 这类通用压测工具相比，它在本土化场景上做得极其细致，比如对 RAC 多节点服务分发、绑定变量、事务权重、连接数控制这些 Oracle 特有机制都有原生支持。
2.6.1 版本里内置了多个标准场景，最常见的是 OrderEntry（订单录入，模拟 OLTP 交易）、SalesHistory（销售历史分析，偏 OLAP）、CallCenter（呼叫中心混合负载）以及数据库内部基准测试用的 TPC-C like 和 TPC-DS like 场景。压测时它会按配置生成大量虚拟用户，每个用户独立发起 SQL 事务，然后统一收集响应时间和吞吐数据。
在实际项目中，我通常拿它做两类事情：一类是在新硬件上给 Oracle 做基准摸底，看这台服务器能扛住多少并发和 TPS；另一类是在 Oracle 迁移（比如从旧版升到 19c、或者换存储）前后各跑一轮同样的负载，通过对比曲线判断改动是否带来性能回退。
1.2 为什么下载下来是一个 ZIP 而不是安装包
这个问题很多人没细想过。SwingBench 是纯 Java 编写的，不需要往系统目录里写驱动、不需要注册 Windows 服务、不需要在 Linux 下建立 systemd unit，所以作者选择了最朴素的 ZIP 打包方式。这么做有几个很实际的好处：
- 跨平台一致：Linux 解压出来的目录结构和 Windows 完全一样，换机器、换系统没有任何差异，脚本路径也不会出现兼容问题。
- 免 root 权限：在服务器上放进任意用户目录就能跑，不需要 sudo，这在很多安全管控严格的生产环境里非常有用。
- 离线部署友好：整个包自带所有运行库和第三方依赖，只要目标机器有 JDK，就能离线运行，适合内网隔离环境。
- 透明可审查：解压后所有 jar、脚本、配置都摆在明面上，安全团队检查起来方便，不像安装包那样有“黑盒”嫌疑。
不过 ZIP 分发也带来一个问题：下载不完整时根本没有提示。你拿到 swingbench2.6.1124.zip，双击解压到一半报错，或者解压完了启动脚本直接提示找不到类，十有八九是包坏了。这里先给一个通用检查命令，后面第 5 章还会详细展开。
unzip -t swingbench2.6.1124.zip出现 OK 字样才说明压缩包完整可用。如果系统没有 unzip，用jar tf swingbench2.6.1124.zip也能起到同样的校验作用。
2. 安装前准备：JDK、数据库账号与目录规划
2.1 版本号里的信息：2.6.1 和 1124 分别代表什么
文件名叫 swingbench2.6.1124.zip，拆开看：2.6.1 是主版本号，1124 更接近构建号或日期编号，类似于“2024 年第 11 周第 24 次构建”这类标记，不是功能上的特别含义。重点还是关注主版本，因为 SwingBench 2.x 是基于 Java 11+ 重写的架构，跟老版本 1.x 在场景文件格式、命令行参数上有不少差异。
很多网络教程还在写 1.x 时代的操作方式，比如用swingbench脚本直接加-u参数，其实 2.6.1 的参数体系已经重构过一次。看官方文档时一定要确认对应的版本区间，否则照着旧教程配置 2.6.1 很容易踩坑。
我建议下载后先在本地虚拟机里把压缩包解压验证一下，确认能启动 GUI 或命令行，再拿到生产服务器上去，避免白跑一趟机房。
2.2 运行环境准备：JDK 版本和数据库端权限
SwingBench 2.6.1 需要 JDK 11 或更高版本，用 JDK 17 实测也没有问题。安装 JDK 这里不赘述，但要确认一点：如果机器的默认 Java 版本低于 11，光解压 ZIP 是不够的，还必须设置好 JAVA_HOME 环境变量，让 SwingBench 启动脚本能指向正确的 JDK。
数据库端需要准备一个有足够权限的账号。如果压测目标是单实例，用 SYSTEM 账号最省事；如果是 Oracle 19c 的多租户架构，建议直接在 PDB 里创建专用账号，并授予DBA角色或至少CONNECT, RESOURCE权限，因为 OrderEntry 场景需要建表、建索引、写入大量数据。SwingBench 使用 JDBC Thin 驱动连接数据库，不需要在数据库服务器上安装 Oracle Client，这在异构环境里尤其方便。
还有个容易被忽略的点：压测机和数据库最好不要放在同一台物理机上。如果数据库和应用各占一半 CPU，压测曲线会出现“资源互抢”的假瓶颈，你很难判断到底是数据库慢还是压测机拖后腿。真实项目中至少保证数据库服务器独占 CPU 核心。
2.3 解压后的目录结构
解压 swingbench2.6.1124.zip 后，关键目录如下：
| 目录/文件 | 作用 |
|---|---|
| bin/ | 可执行脚本目录，包含 swingbench、charbench、minibench、runbench 等 |
| lib/ | Java 依赖库，包括 SwingBench 核心 jar 和第三方类库 |
| config/ | 场景配置文件，OrderEntry.xml、SalesHistory.xml 等 |
| workdir/ | 压测过程中的临时文件、日志、结果输出目录 |
| samples/ | 示例脚本和辅助配置，初学者值得仔细看 |
| docs/ | 官方文档，包含参数说明和 FAQ |
bin 目录下需要重点记住三个脚本：
swingbench：图形界面启动器，适合交互式操作和参数调优。charbench：命令行模式负载生成器，无头环境下最常用，可以独立于 GUI 运行。minibench：嵌入式运行引擎，主要面向通过 Java 代码调用压测的场景，做自动化框架合适。
实际压测时，我在服务器上几乎只用 charbench，因为它不依赖图形环境，方便通过 SSH 远端执行，也方便写进 shell 脚本做循环压测。
3. 第一个压测场景：OrderEntry 从 GUI 到命令行
3.1 GUI 启动与连接配置
把 JDK 确认好后，进入解压目录执行：
cd /opt/swingbench/bin ./swingbench如果机器没有图形环境，这一步会报 DISPLAY 相关错误，别慌，这是正常的，后面直接跳去用 charbench。有图形环境的机器上会弹出 SwingBench 主界面，左侧是“配置连接”面板，右侧是场景选择、参数配置和结果图表区。
首次使用建议先点开 Configuration 填好连接信息：主机名或 IP、端口（默认 1521）、服务名。不少新手在这里填 SID，结果连接失败，记住 19c 里绝大多数场景应该填服务名，比如 Oracle 19c 的 PDB 默认服务名通常是pdb1这种样式，连接时用jdbc:oracle:thin:@//host:1521/pdb1的格式才能正确命中 PDB。
连接测试通过后，从左侧场景下拉框选择 OrderEntry，就能进入压测参数界面。
3.2 关键参数释义：用户数、迭代次数、Think Time 和权重
OrderEntry 场景参数不少，但核心就几个，理解透了基本就掌握了大半：
| 参数 | 作用 | 我的建议 |
|---|---|---|
| 用户数 | 并发连接数，决定负载强度 | 不要一开始就上 200，先用 50 摸底 |
| 迭代次数 | 每个虚拟用户执行的事务次数 | 0 表示无限循环，压测时长由时长参数控制 |
| Think Time | 模拟真实用户思考/操作间隔（毫秒） | 常用 3000ms 左右，太短会产生过载假象 |
| 权重（Weight） | 各事务类型占比 | 默认值即可，不要随意改动 |
| 统计间隔 | 结果聚合的粒度 | 建议 10s，便于观察曲线变化 |
| 连接超时 | 数据库连接建立的超时时间 | 默认通常够用，网络差时适当调大 |
其中最容易影响压测结果的就是 Think Time。把它设成 0 意味着所有虚拟用户拼了命地发请求，压出来的是极限吞吐；真实业务系统里用户不可能没有停顿，所以做容量评估时我一般会设到 2000-3000ms，这样出的结果更贴近生产实际。
OrderEntry 默认场景自带的是一个大约 10GB 左右的数据量，如果你只是想在几台小机器上做个快速验证，可以先用 SwingBench 的配置生成器生成一个较小规模的数据集，比如 100 个仓库（Warehouse），大概 1GB 出头，先跑通流程再放大。
3.3 命令行无头压测：一键跑完一轮
到了服务器上，图形界面往往用不了，这时候用 charbench 做无头压测才是正路。一个最基础的用法是：
./charbench -c ../config/OrderEntry.xml \ -u 50 \ -i 1000 \ -t 300 \ -o ./results/oe_50users \ -uc 0参数含义：-c指定场景配置文件，-u指定并发用户数，-i每个用户的事务迭代次数，-t压测持续时间（秒），-o结果文件前缀，-uc是我自己常用的一个组合参数，含义是“unlimited connection”，即允许连接数不被 JVM 默认值限制。跑完后按 Enter 键会退出，但结果已经写入了 CSV 文件。
实际在自动化脚本里，我常常用 nohup 挂在后台执行，并把输出重定向到日志文件，这样的好处是压测过程不会被 SSH 断开影响，第二天早上直接看报告。
4. 把压测跑起来之后：结果读法与监控配合
4.1 看懂输出指标：TPS、响应时间和最大事务延迟
SwingBench 的结果面板每一行都是一次统计快照，最核心的指标是 TPS（每秒事务数）和平均响应时间，这两项直接反映数据库的处理能力。除了平均值，还要关注“最大事务延迟”，这个指标很敏感，一旦数据库出现排队或锁等待，它往往会突然飙升到几十秒。
举个例子，我做过一轮 128 用户压测，TPS 曲线从 4000 一路涨到 4600，看着挺好的，但最大事务延迟在某个时间点突然跳到 30 秒。单独看平均响应时间根本没有异常，只有拆开看明细才定位到是审计表空间满了导致小部分事务被阻塞。
所以读结果时先看整体趋势，再逐个指标排查：如果 TPS 平稳上升后维持水平，说明系统还有余量；如果 TPS 掉头向下，往往是某个资源被打满。此时需要结合数据库监控来确认瓶颈在哪。
4.2 与数据库监控结合：AWR、OS 指标缺一不可
SwingBench 是客户端视角，它看不到数据库内部到底发生了什么。所以压测的同时，手头要有数据库侧和操作系统侧的监控数据。我在跑压测时会同时盯着三块：
- 操作系统层：
top看 CPU 负载、iostat看磁盘 IO、free看内存。如果用户数提升但 TPS 不涨，先看 CPU 是不是已经 100% 了。 - 数据库层：Oracle 的 AWR 报告里重点看 Top 5 Timed Events，如果是
db file sequential read居前，多半是 IO 瓶颈；如果是library cache lock之类，可能是 SQL 解析和并发冲突。 - 连接层：压测端到数据库端口的连接数也要留意，TCP 连接建立速率过高时会出现 TIME_WAIT 堆积，表现为连接失败率上升。
把这三层数据按时间对齐，就很容易看出负载压在哪一层。有一个经验：TPS 不再上升、CPU 也没有打满、IO 也不繁忙，但响应时间在增加，这时八成是数据库内部有锁等待或并发串行化的问题。
4.3 压测数据保存与多次对比
2.6.1 可以把结果输出到 CSV、JSON 或者数据库表里。CSV 是最常用的，因为我可以用 Python 或 Excel 快速处理，把多轮压测数据画在一起对比。多次压测对比时，注意保持参数一致：同样的用户数、同样的 Think Time、同样的场景配置，否则对比出来的差异没有意义。
在自动化脚本里，我会让每轮压测输出带时间戳的文件名，比如oe_128user_20250120.csv，这样后续整理历史数据时一目了然。
5. 常见问题与避坑记录
5.1 解压阶段：目标 zip 损坏、目录不干净
先解决最让人头疼的下载包问题。网上有相当多求助帖，比如“导入资源包失败 caused by: invalid zip archive: could not find eocd”，这类错误几乎都是因为下载过程中文件被截断，或者用了某些不稳定的下载工具导致 ZIP 尾部数据损坏，EOCD（End of Central Directory）记录丢失，解压工具就找不到文件表的结束位置。
解决办法分两步：
# 1. 先校验 unzip -t swingbench2.6.1124.zip # 2. 确认损坏后，用 curl 重新下载并开启断点续传 curl -L -C - -o swingbench2.6.1124.zip https://xxxx这里我强烈建议用curl或wget -c而不是浏览器默认下载器，前者即使中途断了也能续传，后者在弱网环境下很容易下载出不完整的包。如果源码包是从 SourceForge 下载的，优先选择就近的镜像地址。
解压目录也要留心，路径中不要包含中文、空格和特殊符号。Java 对带空格的路径处理偶尔会出诡异问题，我曾经把工具放在 Windows 的C:\Program Files下，结果脚本启动时报找不到类，换到D:\tools\swingbench就好了。这不是 SwingBench 的 bug，而是很多 Java 命令行工具在引号处理上的通病。
5.2 连接阶段：驱动缺失、账号权限、PDB 服务名
最常遇到的运行时报错是驱动找不到，提示java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver。原因是 SwingBench 默认 lib 目录里不带 Oracle JDBC 驱动包，需要从 Oracle 官方下载ojdbc11.jar（对应 JDK 11+）放到 lib 目录下。注意 2.6.1 和ojdbc8.jar、ojdbc11.jar的兼容性有讲究，JDK 17 环境下我用ojdbc11.jar实测稳定，JDK 11 环境下两者都行。
连接数据库遇到ORA-01017: invalid username/password时，先检查账号，再检查服务名。前面提到过，19c 多租户模式下很可能需要连接 PDB 而不是 CDB。CDB 的根容器通常没有业务数据，压测时如果连接 SID 为ORCL这类 CDB 服务名，会发现找不到业务表，或者权限不足。
另外提醒一下：SwingBench 的场景文件在创建表之前需要账号有建表权限，很多小号为了安全限制得很严，压测前先手动跑一下场景里的建表脚本，或者直接授权 DBA 角色，能省下不少排查时间。
5.3 运行阶段：内存不足、连接风暴和 GUI 起不来
运行中如果出现OutOfMemoryError: Java heap space，可以调整 SwingBench 启动脚本里的 JVM 参数，默认堆内存可能只有 256MB，高并发场景下明显不够。我的习惯是改成JAVA_OPTS="-Xms512m -Xmx2048m"。
用户数不是越大越好。我见过有人直接把用户数拉到 1000，结果压测机自己先撑不住，大量 TIME_WAIT 连接占满端口，数据库侧还没打满，压测端先崩了。合理做法是分批加用户：50 用户跑一轮看曲线，100 用户再跑一轮，逐步往上加，直到 TPS 不再增长，那个点就是系统的性能天花板。
至于 GUI 起不来的问题，在 Linux 服务器上没有 DISPLAY 是正常现象，建议直接习惯用 charbench。如果你想在自己电脑上跑 GUI 又怕影响办公网络，可以先用本机的数据库虚拟机试，或者干脆把所有压测委托到一台专门的压力机上跑命令行。
5.4 常见错误速查表
| 错误现象 | 可能原因 | 处理办法 |
|---|---|---|
| invalid zip archive: could not find eocd | 下载不完整 | 用 unzip -t 校验，curl 断点续传重下 |
| ClassNotFoundException: OracleDriver | 缺少 JDBC 驱动 | 下载 ojdbc11.jar 放入 lib 目录 |
| ORA-01017 | 账号密码错误 | 检查账号和服务名，PDB 环境填 PDB 服务名 |
| Listener refused the connection | 网络不通或监听器未起 | telnet 测试 1521 端口，检查监听状态 |
| OutOfMemoryError | JVM 堆内存不足 | 调大启动脚本 JAVA_OPTS |
| 无法打开 GUI | 没有图形环境 | 改用 charbench 无头模式 |
6. 一套可复制的压测流程参考
最后给一个可以直接抄作业的标准化流程，我在 CentOS 7.6 + Oracle 19c 的环境里跑过很多次，改动很少就能适配其他场景。
首先确认四件事：目标数据库能连通、拥有 DBA 权限的压测账号存在、JDK 11+ 已安装、swingbench2.6.1124.zip 已解压且校验完整。然后按下面步骤走：
- 把
ojdbc11.jar复制到 SwingBench 的 lib 目录。 - 用
charbench生成指定规模的数据集：
./charbench -c ../config/OrderEntry.xml -cf ../config/Oracle19c.xml -s -n 100这里的-cf是指定数据库配置文件的路径，-s是执行 schema 构建，-n 100代表创建 100 个仓库（约为 1GB 数据量）。初次跑通可以用这个规模，正式评估再放大到 500 或 1000 仓库。
- 数据灌好后，跑一轮 50 用户 5 分钟的快速验证，确认场景没问题：
./charbench -c ../config/OrderEntry.xml -u 50 -t 300 -o ./results/oe_50u_json.log- 依次增加用户数到 100、150、200，每轮完成后记录 TPS 和响应时间，保存 CSV 结果。
- 压测结束后，同时生成数据库侧的 AWR 报告，和 SwingBench 结果按时间段对齐分析。
这个流程跑完后，你会得到一张“并发用户数 vs TPS”的曲线，这条曲线就是这套环境当前能力的最直观表达，后续无论是做 SQL 优化还是硬件扩容，都可以用它做前后对比。
我个人的经验是，在大多数业务场景下，50 到 100 个并发用户足够暴露大部分性能问题，200 个以上往往连测试机自己的连接管理都吃力了。真正要关注的不是“能跑到多少并发”，而是“系统在什么压力下开始劣化”，以及“劣化时瓶颈在哪”。SwingBench 的价值不是帮你把数据库打到崩溃，而是给你一把能量化的尺子，让你知道边界在哪里。
如果后续想做得更深入，可以研究一下 SwingBench 的结果导出到 JSON 后配合 Prometheus 和 Grafana 做大屏监控，或者把多轮压测结果做成自动回归脚本。这些方向都是在现有工具链上叠加，并不需要替换压测引擎本身。
本文还有配套的精品资源，点击获取
