Linux 上 Oracle 数据库性能测试实操指南
一 测试流程与准备
- 明确目标与范围：定义要验证的吞吐（TPS/TPM）、响应时间（P95/P99）、并发用户数、稳定性时长及可接受的SLA。
- 业务建模与用例设计：梳理核心业务路径，抽取关键 SQL与事务比例，形成可回放的脚本与数据集。
- 环境与数据：准备接近生产的测试库（结构一致、索引/统计信息一致），数据量与分布要能代表生产。
- 工具选型：数据库侧建议用Swingbench、HammerDB、sysbench、Oracle RAT（SQL Performance Analyzer/SPA）；系统侧用top/vmstat/iostat/sar/nmon；监控平台可用OEM、Zabbix、Prometheus+oracle_exporter、oratop。
- 基线采集：在“空负载/基准配置”下采集OS 与数据库基线指标，作为后续对比依据。
- 团队与计划：明确DBA/开发/性能工程师职责，制定场景矩阵（并发梯度、读写比例、数据规模）与风险预案。
二 测试工具与场景选择
| 工具 |
适用场景 |
关键要点 |
| Swingbench |
OLTP 与 TPC-C 近似评估，支持 RAC |
通过 oewizard 导入数据；GUI 控制 Users/Think Time/Transaction 权重；结果常见为 TPM/TPS 与响应时间曲线 |
| HammerDB |
通用 TPC-C/TPC-H 基准，跨平台 |
易于脚本化，结果用于容量评估与对比 |
| sysbench |
轻量 OLTP 与系统基线，支持 Oracle（需编译启用 Oracle 驱动） |
使用 prepare/run/cleanup 生命周期；可调节 threads/time/rate 等参数 |
| Oracle RAT（SPA） |
变更前后 SQL 性能回归 验证 |
捕获生产 SQL、在测试库回放并对比执行计划与性能差异 |
| OEM |
全栈监控与诊断 |
观察 AWR/ASH/Top SQL/等待事件，联动性能分析 |
| oratop |
实时会话与等待事件 |
命令行快速定位 高负载 SQL/阻塞会话 |
| nmon/vmstat/iostat/sar |
OS 资源瓶颈定位 |
关注 CPU 利用率、I/O 等待、内存与换页、上下文切换 等 |
三 执行步骤与关键命令示例
- 步骤 1 环境校验
- 核对 SGA/PGA、进程/会话数、打开游标、统计信息；确保测试库与生产统计信息一致（避免执行计划偏差）。
- 建立监控：启动 OEM/oratop，并在 OS 侧记录 nmon/vmstat/iostat/sar 日志。
- 步骤 2 数据准备
- Swingbench：运行 oewizard 生成 OE 或 TPC-C 数据，连接串形如 IP:1521:SID，选择 OCI 方式。
- 步骤 3 基线测试
- 低并发（如 10–20 Users）跑 10–15 分钟，记录 TPS/TPM、P95/P99、CPU/IO/等待事件，作为基线。
- 步骤 4 负载与峰值测试
- 设计并发梯度（如 50/100/200 Users），每档 15–30 分钟；逐步提升并观察拐点。
- 示例（Swingbench）：在 GUI 设置 Users、Min/Max Think Time、Transaction Load 权重，观察 TPS/TPM 与响应时间 曲线，避免无思考时间的“超线性”压测。
- 步骤 5 稳定性与峰值保持
- 选取目标并发，持续 2–8 小时，关注内存泄漏、会话增长、日志切换、后台进程异常。
- 步骤 6 回归与变更验证
- 使用 SPA 捕获生产 SQL，在测试库对比变更前后执行计划与性能，确认无退化。
- 命令示例
- Swingbench：使用 oewizard 导入数据；在 bin/ 目录启动 GUI，配置 Users/Think Time/权重 后运行场景。
- sysbench（Oracle）：需编译时启用 –with-oracle；典型流程：
- 准备：sysbench oltp_read_write --db-driver=oracle --oracle-db=yourdb --oracle-user=scott --oracle-password=tiger prepare
- 运行：sysbench oltp_read_write --threads=64 --time=600 --report-interval=10 run
- 清理：sysbench oltp_read_write … cleanup
- OS 监控：
- vmstat 1 60（观察 r/b/si/so/bi/bo 与 us/sy/id/wa）
- iostat -x 1 60（关注 await、r_await、w_await、svctm、util）
- sar -u -r -b -d 1 60（CPU/内存/块设备/IO 历史）
- nmon -f -s 10 -c 360（生成 .nmon 报告用于分析）
四 结果分析与瓶颈定位
- 吞吐与响应：对比不同并发下的 TPS/TPM 与 P95/P99，识别吞吐拐点与响应时间陡升点。
- CPU：若 us 高且 r（运行队列）大，说明计算密集或并发过度；若 sy 高，常见于系统调用/上下文切换频繁。
- 内存与换页：持续 si/so > 0 提示物理内存不足或缓存命中差，需核查工作集与内存配置。
- I/O：iostat 中 await 高且 util≈100% 指示存储瓶颈；结合 sar -d 查看设备繁忙度。
- 数据库等待：通过 OEM/ASH/AWR 聚焦 Top SQL 与等待事件（如 db file sequential/scattered read、log file sync、enq: TX 等），判断I/O、锁、日志等瓶颈类型。
- 结论闭环：将问题归因到SQL/索引/统计/参数/存储/网络等层面，调整并复测验证。
五 常见注意事项与最佳实践
- 数据规模与分布要贴近生产，统计信息需及时收集；避免在“空统计/错误统计”下做结论。
- 并发设计遵循“逐步加压”原则，控制 think time 与事务权重，避免非真实场景的失真高吞吐。
- 每个场景固定随机种子/数据快照，保证结果可复现；每次变更仅保留单一变量。
- 监控要贯穿全程：OS 与数据库同时采集，便于因果关联；测试结束保留AWR/ASH、nmon、日志。
- 变更评估优先用 SPA/RAT 做回归验证，在投产前拦截SQL 性能退化。
- 报告要素：标注工具版本、场景与参数、数据量、监控图表、瓶颈定位与优化建议，便于评审与复盘。
