★ FEATURED ARTICLE 简介SwingBench 2.6 是一款易于上手的 Oracle 数据库负载生成工具自带多种基准测试与向导适合 DBA、性能测试工程师和架构师用于压测数据库特性如分区、压缩或评估新硬件性能。本次分享的 swingbench2.6.1124.zip 为完整发行包共 325 个文件主要包含 129 个 SQL 脚本、78 个 Java 类文件、35 个 TXT 说明、28 个 XML 配置、15 个 JAR 运行库及 14 个 BAT 启动脚本压缩包整体 27.92MB。新版本已全面支持 Java 8带来 JSON 基准、TPC-DS 类基准、声明式自定义基准、SQL 查询编辑器与全新图表渲染引擎并支持远程连接 Oracle Cloud同时提供 SBUtil 工具用于校验/缩放基准、results2pdf 工具将结果转 PDF。资源内附各基准向导与批量启动脚本如订单、销售历史、JSON、TPC-DS 等场景均通过对应 BAT 一键唤起解压即可快速生成测试负载并观察统计结果其中 SQL 脚本与 XML 配置可按需调整测试模型。已有 1260 人学习下载适合希望系统掌握 Oracle 负载模拟、基准方法论及硬件/特性评估流程的中高级数据库从业者。1. Oracle 压测前的最后一个 zip 包swingbench2.6.1124.zip 到底解决什么问题做 Oracle 数据库性能评估的人手边几乎都会留一个 swingbench2.6.1124.zip。它不是一个普通压缩包而是一整套 Oracle 负载注入工具的免安装发行版——解压即用专门用来在数据库上模拟真实业务事务把并发上来之后才会暴露的 SQL 性能问题提前暴露出来。常见做法是先用它跑一轮负载再配合 AWR 报告确认瓶颈而不是上了生产才被慢查询打个措手不及。这个 zip 包适合三类人需要验证数据库配置变更的 DBA、要估算数据库容量和并发上限的运维工程师、以及写 SQL 但不确定它在高并发下会不会翻车的后端开发。它能解决的问题很直接在安全的环境里用可控的并发、可控的负载强度把数据库从空闲状态压到接近真实业务再观察吞吐和响应时间怎么变化。2. 解开 swingbench2.6.1124.zip 之后先把环境对齐再做压测2.1 解压目录与核心文件别急着双击拿到 zip 包后我一般先解压到固定目录避免路径里带空格和中文后续所有脚本拼接 JDBC 连接串时少踩很多坑unzip swingbench2.6.1124.zip -d /opt/swingbench ls -la /opt/swingbench解压后你会看到 bin存放启动脚本、lib存放 SwingBench 自身 jar 和 JDBC 驱动、workdir日志与结果文件、configs压测场景的 XML 配置以及 sql部分场景的建表脚本。先说逻辑bin 里的启动脚本负责把 lib 下的 jar 装配成 classpath所以驱动需要放在 lib 目录而不是随便丢在某个自定义目录configs 下的 XML 决定用什么负载模型改参数前先复制一份再改保留最原始的默认配置作对照。新手最容易犯的错是直接双击 swingbench.bat 或 start.sh环境对不上就在这一步闪退。2.2 JDK 版本先对齐这是 zip 版第一个玄学SwingBench 是 Java 应用zip 包里不带运行环境机器上必须先有 JDK。按我踩过的通用经验这类老牌压测工具对 JDK 版本很敏感JDK 1.8 或 11 是最稳的组合直接装个很新的 JDK 17 以上启动时报 UnsupportedClassVersionError 的概率很高。启动前先确认java -version cat /opt/swingbench/bin/swingbench.sh | grep JAVA_HOME逻辑说明第一个命令看你默认的 java 版本第二个命令看启动脚本是否读取了 JAVA_HOME 环境变量。如果系统里装了多个 JDK建议在运行压测的终端里显式 export JAVA_HOME 指向 JDK 11例如export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64再启动。参数就一个JAVA_HOME 指对目录PATH 里能找到同版本的 java。省略这一步后面所有报错都会很像是“程序坏了”实际是它没找到合适的解析器。2.3 驱动选型oltp、oltp2、charbench 分别模拟什么负载很多人一上来就选最热闹的 oltp 场景但我的经验是先看目标。SwingBench 的核心是 driver负载模型不是简单的压力生成器它通过真实 SQL 和存储过程在目标库上制造事务。常见配置里这些 driver 的差异大致如下配置名模拟的业务特征适合验证的目标oltp高频小事务、短查询、快速提交日常在线交易系统关注 TPS 和 commit 开销oltp2混合读写、含报表型查询偏分析但仍有事务压力的系统charbench字符型数据操作、大字段读写排查字段长度或字符集相关的性能问题选型理由如果你的业务是典型的订单交易、短连接频繁提交用 oltp 最贴近如果压测目的是验证数据仓库或者大查询并发oltp2 更合适。charbench 只在遇到字符集相关的异常才值得单独跑。别把 oltp 压测结果直接用来估算数仓场景负载模型不同结果没有可比性。2.4 连接参数配好 JDBC 连接串TNS 反而可以绕过zip 版默认不带你生产环境的 tnsnames.ora所以我建议直接用 thin 风格直连少一层解析排障也更直观。以最小参数集为例# 在 /opt/swingbench/bin 下执行验证驱动能连上库 ./minibench -u soe -p soe -db jdbc:oracle:thin:127.0.0.1:1521/ORCL -v逻辑说明-u和-p是数据库用户名和密码-db是 JDBC 连接串后面是地址、端口和服务名-v打开详细日志。第一次跑不要加任何并发参数只验证连通性。如果这一步报错后面 UI 点得再漂亮也没意义。参数说明里有三个值得注意的连接串里的服务名必须是小写或与库里 s 保持一致端口不能写错密码里带特殊字符时整个-db参数建议用双引号包起来。想走 TNS 也行在环境变量里设 TNS_ADMIN 指向 tnsnames.ora 所在目录但那样出错时排查链路更长我一般只在复现生产连接方式时才这么干。3. 从 Minibench 到 SwingBench UI跑通一次可复现的负载测试3.1 Minibench 最小验证先证明驱动能连库正式压测前我习惯先用 Minibench 做一次最小验证它可以不带图形界面跑一个配置项快速确认连接串、用户名密码、driver 选择是否全部正确/opt/swingbench/bin/minibench -u soe -p soe \ -db jdbc:oracle:thin:127.0.0.1:1521/ORCL \ -config oltp.xml \ -v逻辑说明-config指定使用哪个负载模型配置SwingBench 会根据这个 XML 决定事务组成-v会把每一步执行的 SQL 和事务结果打到控制台。第一次跑如果出现ORA-01017说明用户名密码不对如果是IO Error说明监听或服务名有问题如果出现 SQL 执行错误通常是目标 schema 没有建好数据表。这一步是给后续 UI 压测铺底别跳。3.2 准备数据表没有 SOE 数据压测一开始就会失败Minibench 能连库不代表能压测目标 schema 里必须先有 SwingBench 需要的业务表和数据。最常见的是 SOE订单入口模式它模拟订单、商品、库存等一整套电商表结构。数据准备一般通过 SwingBench UI 的 Tools 菜单里提供的数据生成功能完成也可以让 DBA 按你熟悉的场景手动建等价表。我的习惯是先估算数据量S 规模几十分钟能完成L 或 XL 规模可能要跑几个小时先在测试库里验证好再投到更大的环境。数据没准备好时压测日志里会频繁出现ORA-00942: table or view does not exist这不是工具坏了而是 schema 缺失。我见过真有同事把这种报错当成 SwingBench 的 Bug查了半天才意识到测试库从没生成过数据。准备完成后用一条简单查询确认表里有数据SELECT COUNT(*) FROM soe.orders;这条语句不参与压测只用来确认数据层面没问题。统计结果如果为 0先回去跑数据生成别浪费时间启动压测。3.3 SwingBench UI 里的三个参数并发用户、think time、load level图形界面打开后核心配置集中在连接信息和负载参数两块。连接信息沿用 Minibench 验证过的连接串和账号负载参数里必须先弄明白三个名词参数常见默认值作用Number of Users10同时模拟的业务连接数直接影响并发度Think Time0 秒每个事务之间的用户思考间隙模拟真实操作停顿Load Level100控制事务发起密度的放大系数调整顺序是有讲究的先固定并发用户数再调整 Think Time 让事务速率贴近真实业务最后用 Load Level 微调。很多人一上来就把并发数拉到几百Think Time 设为 0结果是数据库瞬间被打满你根本分不清瓶颈是 SQL 本身还是连接数爆炸。我一般先设 20 个用户跑 5 分钟观察 TPS 曲线确认稳定后再逐步加并发。3.4 启动压测与监控日志在 workdir 里别盯着图表发呆点击 Start 之后SwingBench UI 会实时画出事务完成数和响应时间曲线但我的建议是别只顾看图表真正要盯的是 workdir 目录下不断增长的日志文件。图表只是趋势参考日志里的异常堆栈和报错细节才是排查依据。压测结束后停止按钮只是结束模拟连接池释放需要一点时间这时去数据库侧查一下是不是还有残留 session。监控阶段我通常开两个终端一个看 SwingBench 日志输出另一个连数据库查当前活跃会话SELECT status, COUNT(*) FROM v$session GROUP BY status;这能帮你确认压测进程是否真的把负载打到了数据库上而不是卡在客户端等待。如果活跃会话数始终上不去问题多半出在连接池配置或 JDBC 连接串上先回去查配置。4. 避坑SwingBench 2.6 常见问题排查6 个踩坑记录4.1 启动脚本一闪而过日志提示 UnsupportedClassVersionError现象双击swingbench.sh后终端秒退捕获日志发现java.lang.UnsupportedClassVersionError。原因当前默认的 JDK 版本太新SwingBench 2.6 的 class 文件无法在新版本 JVM 上解析。这属于最典型的版本不对齐问题。解决显式指定 JAVA_HOME 指向 JDK 1.8 或 11并在当前终端重新source环境变量后再启动。别改系统默认 JDK只改压测终端的环境变量即可这样不影响其他服务。4.2 能找到主界面但一点 Start 就报找不到 JDBC 驱动现象UI 能正常打开输入连接信息后点 Start报ClassNotFoundException: oracle.jdbc.driver.OracleDriver。原因lib 目录下缺少对应数据库版本的 JDBC 驱动或驱动版本与数据库版本不匹配。zip 包自带的驱动只覆盖特定版本范围如果你连的是新版数据库原驱动可能不兼容。解决从数据库安装目录中拷贝对应版本的 ojdbc 驱动 jar 到 SwingBench 的 lib 目录替换掉原文件再重启 SwingBench。替换前把原 jar 改名备份这个习惯能省去后悔药。4.3 本地没装 Oracle 客户端怎么连都报 listener 错误现象连接串是jdbc:oracle:thin:127.0.0.1:1521/ORCL但报IO Error: The Network Adapter could not establish the connection。原因不一定是网络问题最常见的是服务名 ORCL 在目标实例上不存在或者端口配错。zip 版不依赖本地安装 Oracle 客户端所以问题基本在连接串本身。解决先用tnsping或对方 DBA 确认正确的服务名再改连接串里的服务名。另外检查端口许多测试库不是默认的 1521。4.4 压测跑了五分钟TPS 曲线一路下滑最后归零现象刚开始 TPS 正常几分钟后逐步下降最终 UI 无响应日志里出现大量ORA-01000: maximum open cursors exceeded。原因SwingBench 的事务里循环执行 SQL每个循环都打开游标而数据库的 open_cursors 参数限制了单 session 可打开的游标数。并发上去之后这个限制被触发。解决这不是 SwingBench 的配置问题是数据库参数限制。在压测库上临时调大 open_cursors压测结束后还原。注意如果调整后 TPS 依旧下滑那就不是参数问题而是 SQL 本身有问题需要回头查执行计划。4.5 并发用户加到 100TPS 不升反降数据库 CPU 也上不去现象把 Number of Users 从 50 提到 100TPS 反而从 300 掉到 200CPU 使用率也没有明显升高。这是让很多人困惑的“玄学”时刻。原因压测机的资源成为瓶颈或者连接数超过了数据库连接池的合理范围线程切换开销盖过了并发收益。另外Think Time 设为 0 会让所有用户拼命争抢资源导致锁等待放大。解决先把 Think Time 恢复到 1 到 3 秒的区间再逐步加用户同时看一下压测机本身的 CPU 和内存SwingBench 是 Java 进程压测机如果只有两核跑 100 用户时它自己先卡死了。4.6 UI 图表区域空白中文显示成乱码现象压测数据正常增长但图表区域一片空白或右侧统计文字全是乱码。这属于“能跑但不好看”的问题不影响测试结果但影响现场演示。原因Java 图形界面在缺少中文字体或 charset 设置不一致时会出现字体渲染异常。SwingBench 的 UI 层依赖系统字体库。解决在启动脚本里加上-Dfile.encodingUTF-8确保系统安装了基础中文字体。如果图表一直空白尝试换成 JDK 11 自带图形库的版本多数情况能解决。5. 压测结果怎么读看这三个数少走半年弯路压测跑完数据是一堆曲线和日志真正值得看的其实是三个数TPS 峰值、平均响应时间、Top 等待事件。TPS 峰值决定了数据库当前的业务吞吐上限。压测时 TPS 会先上升到达一个平台期后不再随并发增加而升高这个平台期就是上限。在平台期之前数据库属于资源充足状态过了平台期还在加并发响应时间会开始直线上升这是典型的过载信号。平均响应时间要分事务类型看。SwingBench 的配置里不同事务会有各自的响应时间统计不要只看总平均值。OLTP 场景下单次事务平均响应时间超过 100 毫秒就需要回头审视 SQL 本身了如果只是个别大查询超过这个值属于正常范围。Top 等待事件要和 AWR 报告对应着看。我的习惯是压测前收集一次 AWR 快照压测结束后再收集一次用差值定位数据库内部到底在等什么。常见等待事件如 enq: TX - row lock contention 说明锁竞争严重db file sequential read 则提示 IO 层可能是瓶颈。这背后是一个反复验证的习惯压测不是“跑完看个胜负”而是先建立基线再修改配置再压测最后对比三组数据。我第一次做完整压测时直接盯着 TPS 涨了就以为数据库没问题结果等消耗完所有连接之后连带其他业务一起卡住那种血泪教训到现在都记得。后来我每次都先跑一轮不变化的基线确认数据稳定再动手。希望这个习惯也能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
