企业官网建设流程全解析

简介：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 eocd

EOCD 是 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.zip

Windows 右键解压即可，注意解压路径不要带中文和空格，否则个别依赖脚本解析路径容易绕弯路。解压完成后会看到一个类似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.xml

configs/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-01950：no 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、驱动、数据库连接全部正常再放上测试机。这样做看起来多花了几分钟，但能在真正压测的时候省下大量排查时间。工具本身是免安装的，但环境准备这个环节，永远不值得省。

本文还有配套的精品资源，点击获取