Oracle性能优化实战：基准测试全流程解析与AWR瓶颈定位

Oracle性能优化基准测试AWR报告

于 2026-10-02 09:08:09 修改

·本内容遵循CC 4.0 BY-SA版权协议

做Oracle性能优化这些年，我最大的体会是：优化之前不先做基准测试，后面的一切工作都像是在黑屋子里找开关。你可能觉得这句话太绝对，但翻翻那些翻车的案例，十有八九都是改了个参数、优化了几句SQL，上线后数据库反而变慢了——不是这些改动不对，而是你没有数据能证明它们是对的，也没有稳定的基线做对比。所谓的基准测试，就是在系统跑真实或模拟业务之前，先把性能底数摸清楚，给后续每一个优化动作建立一把可量化的尺子。

以Oracle数据库为例，基准测试这件事，涉及的远不止“跑个压测脚本”那么简单。从测试建模、环境准备、工具选型，到结果解读、瓶颈定位，再到优化前后对比，本身就是一套完整的性能工程方法。这篇内容我会结合一个实际的OLTP压测案例，把Oracle性能优化里基准测试的全流程拆开讲清楚，包括每一步为什么这么做、实际跑的时候会遇到哪些坑，以及拿到AWR报告之后到底该怎么看。适合刚接触Oracle性能调优的开发、DBA，也包括那些手上有Oracle环境但一直只停留在“能跑就行”阶段的运维同学。

1. 基准测试在Oracle性能优化中的定位

1.1 性能优化的第一步不是调参，而是建立基线

很多人做Oracle性能优化，上来就想改SGA、调PGA、开并行，这些动作本身没有错，但问题在于：你凭什么判断当前系统是慢的？慢在哪里？改完参数之后是变好了还是变差了？如果没有一个量化的基线，这些问题统统回答不了。

基准测试解决的就是这个“凭什么”的问题。它的核心逻辑是：在受控的条件下，用确定的负载模型去压测数据库，得到一组性能指标（TPS、响应时间、等待事件、资源消耗等），这组指标就是基线。之后每次优化，都在同样条件下重跑一遍，用数据判断优化的真实效果。这也是行业里常说的“先测量，再优化，后验证”，顺序乱了，优化就成了碰运气。

举个例子，我之前处理过一个订单系统的性能问题。业务方反馈高峰期页面打开很慢，开发同学怀疑是数据库慢查询，连续加了好几个索引，结果不仅没变快，部分写入操作反而出现锁等待。后来我们做了两件事：第一，用真实业务日志构造了一个订单查询与更新的混合负载，在测试环境跑了一遍基准；第二，查看AWR报告发现主要等待事件根本不是全表扫描，而是redo log切换频繁导致的log file sync。方向错了，加再多索引也没用。这就是基准测试的价值——让性能优化从“我以为”变成“数据显示”。

1.2 基准测试的分类：微观基准与宏观基准

在讲具体操作之前，有必要先把基准测试的分类说清楚。按测试目标和粒度，Oracle性能优化里的基准测试大致分两类。

一类是微观基准，针对单一数据库组件或某类操作的测试。比如测试一条SQL在索引扫描和全表扫描下的性能差异、测试某存储设备的随机读IOPS、测试日志写入的吞吐量等。这类测试的特点是范围小、控制变量容易、结果直接服务于某个具体判断。

另一类是宏观基准，模拟接近真实业务的混合负载，综合评估数据库整体的处理能力。典型的如TPC-C模型（模拟订单录入、支付、查询等OLTP混合事务）、TPC-H模型（模拟复杂分析查询），以及围绕这些模型衍生出的SwingBench、HammerDB等工具。这类测试更接近生产实际情况，常用于容量规划、架构选型和优化前后的整体效果对比。

微观和宏观不是二选一的关系。我的习惯是：在优化某个具体问题时先做微观基准佐证判断，在验证整体效果时做宏观基准看全貌。两者配合，既能定位问题，又能评估优化的全局影响。

1.3 测试方法论：单一变量原则与可重复性

基准测试听起来简单，真正执行起来容易犯两个错：一是同时改了多个变量，出了问题不知道是谁引起的；二是测试环境跟生产环境差异太大，得出的结论没有参考价值。

所以，方法论上一定要守住两条底线。

第一条是单一变量原则。每次只改一个参数或一个SQL，改完重新跑一遍相同的测试，对比指标。很多新手DBA容易忽略这一点，一次优化提了好几个方案，全都实施上去，然后发现性能提升了，却说不清楚到底是哪个改动起的作用。这对后续的长期维护非常不利——你不知道哪个参数是真正有效的，也就不知道将来该如何取舍。

第二条是可重复性。同一个测试要能够稳定复现，至少跑两到三遍，取中间值或稳定值作为基线。数据库本身有缓存、有Checkpoint、有各种后台进程，第一次跑和第二十次跑的结果一定不一样。常见的做法是先做预热（比如跑几分钟丢弃结果），让buffer cache达到稳态，然后进入正式测试阶段，多次采样取平均值。只有结果可重复，你才能放心地拿它作为后续优化的对照物。

2. 测试设计与环境准备

2.1 数据库版本与基础参数选择

基准测试之前，先把环境梳理好。Oracle版本不同，参数默认值差异很大，优化手段也不同。比如11.2.0.4是一个很成熟的版本，很多企业到现在还在用，但它的很多默认参数在现在的硬件条件下偏保守；而19c（实际是12.2.0.3基础上的长期支持版本）引入了不少自适应特性。我自己做基准测试，一般会先在目标版本上确认几个关键参数。

memory_target / sga_target / pga_aggregate_target：内存分配策略，测试前就要定好，避免测试过程中发生自动内存调整干扰结果。
db_block_size：默认8K，除非有特殊原因，一般不用改。
db_files / open_cursors / processes / sessions：连接数相关参数，在压测前必须确认足够大，否则并发一上来直接报错，测试直接失败。
log_buffer、redo log大小与组数：OLTP写入密集型负载很依赖redo，redo太小会导致频繁切换。
statistics_level：建议设置为TYPICAL或ALL，否则AWR报告无法生成。

这里插一句关于补丁的。做基准测试前，确认数据库补丁版本是个容易被忽略但很重要的事。之前遇到过一台11.2.0.4的库，压测时出现异常高的latch竞争，排查了很久，最后发现是缺了一个已知bug的补丁。补丁版本不一致，性能表现差异能到10%以上，这在基准对比时是致命的干扰因素。所以测试前把OPatch版本、补丁情况都记录下来，作为测试元数据的一部分，这不是可选项，是必选项。

2.2 测试前环境检查清单：监听、归档、统计信息

在正式压测之前，有一堆环境准备工作要做。我把它们整理成了一个检查清单，每次做基准测试前逐项过一遍，能省掉很多测试中途翻车的时间。

第一个是监听服务。很多人压测刚开始就报连接失败，不是数据库有问题，而是监听服务没起来或者配置有误。Oracle监听起不来，最常见的原因有这么几个：hostname解析失败、端口被占用、listener.ora文件配置错误。排查的时候先用lsnrctl status看状态，再用tnsping测试连接。这里有个经验，如果tnsping能通但应用连不上，大概率是防火墙或者sqlnet.ora里的访问控制配置问题。

第二个是归档模式。生产环境通常开启了归档日志（ARCHIVELOG），测试环境如果也开了，压测会产生大量归档日志，磁盘满了整个数据库都会挂掉。要么在测试前确认归档目录有足够空间，要么干脆把测试库设为NOARCHIVELOG模式。不过要注意，如果你做的测试本身就包含主备切换或DG相关场景，那归档模式是必须保持开启的，不能为了压测方便而牺牲场景的真实性。

第三个是统计信息。优化器和统计信息的关系，相当于导航和地图的关系。统计信息不准确，优化器选出来的执行计划就可能离谱。压测前要对相关表收集一次统计信息，用DBMS_STATS.GATHER_TABLE_STATS或者GATHER_SCHEMA_STATS都行。做基准测试的场景里，还有一个常见隐患：某些表数据量很大，统计信息收集时间很长，有人为了省时间就跳过或抽样，结果压测跑出来的执行计划和生产不一致，整个测试白做。

第四个是表空间和数据文件。确认表空间有足够剩余空间，数据文件是自动扩展（AUTOEXTEND ON）还是手工管理，建议压测前把数据文件大小预留好，避免压测过程中频繁触发文件扩展，增加额外I/O。

2.3 业务模型抽象：从真实负载到测试脚本

基准测试的脚本不是随便写几条SQL就行，它必须能代表你真实的业务负载。这就涉及业务建模的环节——把生产环境的流量特征抽象成一组可量化的操作模型。

怎么做？第一步是从AWR报告或v$sqlarea里抓取生产环境top SQL，统计这些SQL的执行频率、平均执行时间、涉及的表和索引。第二步是分析业务构成比例，比如订单系统里，查询订单大概占60%，创建订单占20%，更新订单状态占15%，对账统计类占5%。第三步是把这些比例映射到测试脚本里，让压测工具按比例并发执行这些操作。

这个过程如果做得粗糙，基准测试的结果就会失真。比如你把所有负载都设计成主键查询，测出来IO很低、响应很快，但实际上生产环境里有很多like模糊查询、分页查询、多表join，这些才是性能瓶颈所在。我在实际项目中会用生产环境的Top SQL作为脚本素材，再按业务比例加权，这样测试出来的结果才真正有参考意义。另外，Oracle分页是个常见坑，12c之前用rownum嵌套子查询，12c之后可以用FETCH FIRST，不同写法对不同数据分布的执行计划影响很大，建模的时候一定要把这类代表性SQL放进去。

2.4 工具选型：SwingBench、SLOB、HammerDB怎么选

Oracle基准测试工具不少，我实测下来，最常用的三个是SwingBench、SLOB和HammerDB。下面这个表格是我的使用感受，供大家对比参考。

工具	主要用途	优点	缺点	适合场景
SwingBench	OLTP混合负载压测，内置TPC-C/TPC-H模型	官方支持，生成的负载模型成熟，支持集群压测，指标丰富	配置复杂，上手需要一点时间	模拟订单类OLTP业务，优化前后效果对比
SLOB	I/O子系统专项压测	轻量级，能精确模拟Oracle的物理I/O特征	只测I/O，不覆盖SQL层	存储选型、RAID策略评估、热盘分析
HammerDB	跨数据库TPC-C/TPC-H压测	免费开源，跨平台，自带图形界面	对Oracle特性的模拟不如SwingBench精细	多数据库对比、快速压测验证

我的建议是：日常做Oracle OLTP基准测试，优先选SwingBench；要专项评估存储性能，用SLOB更直接；如果你需要在Oracle、MySQL、SQL Server之间做横向对比，HammerDB更方便。

SwingBench的架构里，有一个叫beans的核心概念，它把一次数据库操作封装成一个Java Bean，通过配置不同的bean组合来模拟不同的业务模型。它还有一个Driver的概念，Driver负责把生成的SQL发给数据库，相当于压测引擎。你可以在图形界面（SwingBench UI）里配置，也可以用命令行方式跑，后者更适合做自动化压测脚本。

3. 核心实操：OLTP基准测试全过程

3.1 测试场景构建与数据初始化

理论部分说完了，下面进入正题，我用一个模拟电商订单系统的案例，完整走一遍基准测试的流程。

先设定业务背景：假设有一张订单主表T_ORDER，一张订单明细表T_ORDER_ITEM，主表大约有500万行数据，每天新增5万行左右。业务负载特征是：订单查询（按订单号、按用户、按时间段分页查询）、订单创建（插入主表和明细表）、订单状态更新。这里对T_ORDER做了分区，按创建时间做范围分区，每个月一个分区。

数据初始化阶段，我直接用PL/SQL循环造数，用DBMS_RANDOM生成随机数据。注意造数不能太随便，数据分布要尽量贴近真实。比如订单号要有规律但不完全连续，用户ID要有热点用户（某些用户下单特别频繁），金额字段要符合偏态分布而不是均匀分布。因为优化器对数据分布的判断会直接影响执行计划，如果测试数据是均匀分布的，很多实际生产中因为数据倾斜导致的问题在测试环境就复现不出来。

造数脚本里有一个细节，给T_ORDER表建索引的时候，日期字段的索引粒度很重要。这跟Oracle分区裁剪有关——如果分页查询的条件是“某个用户最近一个月的订单”，那优化器需要决定是走分区裁剪加索引扫描，还是全分区扫描。这两种路线的性能差异在一个千万级表上可以是几十倍的差距。

3.2 压测脚本与并发模型设计

数据准备好之后，设计压测脚本。这里用SwingBench自带的Order Entry模型来模拟订单业务，它的核心操作包括：

新订单创建（NEW ORDER）：同时往主表和明细表插入数据，模拟用户下单
订单支付（PAYMENT）：更新订单状态字段，模拟支付回调
订单查询（ORDER STATUS）：按订单号查询订单及明细
库存检查（STOCK LEVEL）：关联查询商品库存，模拟订单审核

这个模型跟我们的订单系统负载是匹配的，直接拿来用。如果是更个性化的业务模型，SwingBench也支持自定义脚本，你可以把自己抓取的SQL填进去，配置好执行频率就行。

并发模型方面，压测不是并发数越大越好。我先把并发从5个线程开始，观察数据库的响应时间和资源使用率，逐步增加到10、20、50个线程，找到系统的拐点。这个拐点通常出现在CPU使用率接近80%或等待事件明显升高的位置。在拐点附近，系统的吞吐量增长趋缓甚至下降，而响应时间开始快速上升，这个区域就是我们需要重点分析的性能边界。

压测时长也有讲究，不是跑个30秒就结束。数据库有缓存预热、有检查点、有后台作业调度，短时间压测很难看到真实水平。我的建议是至少跑15到30分钟，前5分钟作为预热阶段（数据丢弃不计入结果），后面的数据才作为有效采样。这样buffer cache达到稳态之后，测出来的指标才是可重复的。

3.3 执行压测：SwingBench命令行模式实操

这里我以命令行的方式跑一次SwingBench压测，因为在生产环境或者测试服务器上，图形界面并不是随时可用的。

BASH

# 第一步：创建测试schema

sqlplus / as sysdba

SQL> create user benchmark identified by benchmark default tablespace users temporary tablespace temp;

SQL> grant connect, resource, dba to benchmark;

然后切换到SwingBench的bin目录，执行swingbench.bat（Windows）或swingbench.sh（Linux）启动图形界面，在界面上配置连接信息（主机名、端口、SID/Service Name、用户名密码）。

连接测试通过后，选择Order Entry模型，并配置以下参数：

并发用户数：先设置10个
运行时间：30分钟
预热时间：5分钟
日志目录：指定一个独立目录，用来保存测试日志

点击运行，SwingBench会实时显示TPS（每秒事务数）和响应时间曲线。这里有两个细节值得注意。第一，压测期间一定要在另一个会话里持续采集数据库性能数据（AWR快照、OSWatcher、v$sysstat），否则压测完发现有问题，数据却没有留存，复盘无从谈起。第二，SwingBench界面显示的响应时间是客户端视角的，包含网络传输损耗，而数据库内部的等待分析和执行时间要以AWR和v$session里的数据为准，两边的数值如果有较大偏差，说明网络或客户端处理可能是瓶颈。

3.4 指标采集：AWR、ASH与OSWatcher配合

压测不是跑完就算了，关键在采集数据。我最常用的三个工具是AWR、ASH和OSWatcher。

AWR（Automatic Workload Repository）是Oracle自带的性能仓库，它会定期（默认每小时）生成数据库运行状态的快照，并基于快照生成性能报告。压测期间，你可以在开始和结束时各创建一次快照，然后生成这段时间的AWR报告，用于分析各类统计信息和等待事件。生成方式：

SQL

-- 创建快照

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- 等待压测结束

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- 生成AWR报告

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

ASH（Active Session History）更细粒度，它每秒采样一次活动会话，能看到某一时刻具体哪些会话在干什么、等待什么。当AWR告诉你某个等待事件很突出时，ASH帮你定位到具体是哪个SQL、哪个会话引起的。如果说AWR是全国人口普查，ASH就是重点区域的实时监控探头。

OSWatcher是Oracle提供的一个操作系统层监控工具，采集CPU、内存、磁盘、网络指标。很多时候数据库层面看起来正常，但操作系统已经是I/O饱和了，这时候没有OSWatcher数据会非常被动。压测机上跑着oswatcher，测试结束后用oswbb工具生成图表，和AWR报告配合起来，问题的画面就完整了。

4. 测试结果解析与瓶颈定位

4.1 先看整体趋势，再看细节指标

压测结束，数据到手，怎么分析？

我的习惯是分三步。第一步看整体趋势曲线（TPS和响应时间随并发数的变化），先判断系统有没有明显的拐点，以及这个拐点出现在什么位置。如果TPS在并发数翻倍之后几乎不涨，而响应时间翻了两倍，说明系统已经到达处理能力的上限，再堆并发只会让性能更差。第二步看AWR报告里的Top 10等待事件，快速锁定瓶颈类型。第三步回到ASH和具体SQL层面，定位到具体语句和对象。

关于等待事件，有几个常见的需要特别留意。db file sequential read表示大量单块读，通常和索引扫描相关，如果这个等待突出，可能是索引选择不好或者访问路径有问题。db file scattered read表示大量多块读，通常对应全表扫描或索引快速全扫描，如果这个突出，就要检查SQL是不是缺少合适的索引，或者优化器误判了数据量。log file sync表示会话在等redo日志写入完成，这个跟提交频率、redo log大小和磁盘I/O能力都相关，很多OLTP系统压测时会卡在这里。还有一个容易被忽略的是enq: TX - row lock contention，要看具体的阻塞模式，可能是应用层的事务设计问题，也可能是唯一索引冲突。

4.2 案例分析：一次“加索引反而变慢”的基准测试复盘

下面用一个我实际遇到的案例来演示结果分析方法。

某订单查询功能，测试环境压测时发现T_ORDER表上的一个查询SQL响应时间达到800ms，而业务要求是300ms以内。开发同学加了索引后，响应时间降到200ms，看起来问题解决了。但整体压测时，系统TPS反而从之前的1200降到了900，而且出现了大量enq: TX - row lock contention等待。

第一次看到这个结果，大家都很困惑——单条SQL是变快了，为什么整体性能反而下降？后来查了AWR和ASH，发现原因有两层。

第一层，新加的索引建在了ORDER_STATUS字段上，而这个字段只有4个不同值（待支付、已支付、已发货、已完成），选择性极差。优化器反而选择了这个低选择性的索引做索引范围扫描，产生了大量单块读，比原来的全表扫描还要慢。第二层，更隐蔽的问题是，这个表本身业务写入频繁，每次插入、更新都要同步维护新增的索引，索引维护的开销直接拖慢了写入类事务，造成了行锁等待。

这个案例的教训是：基准测试里的优化验证，不能只看单条SQL的响应时间，要看整体TPS和写入链路。优化手段对系统的影响是全局的，一条SQL变快了，可能给其他SQL带来了额外负担。这也是为什么优化前后一定要各自跑一遍完整的基准测试做对比。

4.3 执行计划变化与统计信息陷阱

在基准测试的重复执行过程中，还有一个常见问题：同一个SQL，第一次跑和第二次跑的执行计划完全不一样。这不一定是bug，很可能是统计信息或者绑定变量窥探（bind peeking）在起作用。

Oracle优化器在做执行计划选择时，依赖表和索引的统计信息来估算基数。如果你在压测前收集过一次统计信息，然后在压测过程中又进行了大量DML操作，表的统计信息就过期了，优化器后续可能选择完全不同的执行路径。这在长时间压测中尤其明显。

解决方式有几种：一是压测前收集统计信息，并在压测过程中关闭自动统计信息收集任务，保证统计信息的一致性；二是对于关键SQL，使用SQL Plan Management（SPM）来固定执行计划；三是理解你的测试模型，如果它是偏OLTP的短事务，频繁的统计信息变化本身就是一种干扰因素，要在测试方法论里排除掉。

4.4 优化后再测：闭环验证的关键

前面的分析定位了问题，开发同学做了优化（调整索引、改SQL写法、修改参数等），这时候必须做一件事：在完全相同的压测条件下，重新跑一遍基准测试。这就是性能优化的闭环验证。

闭环验证有几个注意点。首先，测试条件和上次保持一致，包括并发数、测试时长、数据量、脚本版本。其次，测试环境尽量避免其他干扰性操作，比如不要在压测过程中跑全量备份。最后，对比指标要全面，除了TPS和响应时间，还要看等待事件是否发生变化、资源消耗（CPU、I/O）是否转移。

我在多次项目里验证过的做法是：把每次测试的配置、参数、脚本版本、数据库版本、补丁信息、结果指标都记录在一张表里，形成一份“测试运行记录”。这看起来有点繁琐，但当你需要回溯某次优化为什么有效、某次压测数据为什么和上次不一致时，这份记录能帮你省下大量排查时间。

5. 常见问题与排查技巧实录

5.1 压测常见问题速查表

实际操作中，基准测试本身就会遇到各种问题。我整理了一张速查表，基本都是这些年踩过的坑。

现象	常见原因	排查思路
压测开始时大量连接失败	监听未启动、processes/sessions参数过小	`lsnrctl status`查看监听状态，检查参数文件确认连接数上限
压测过程中磁盘空间暴涨	归档日志或redo日志增长过快	检查归档目录、redo log大小和组数，必要时开启或确认AUTOEXTEND
TPS不稳定，起伏很大	自动统计信息任务、其他后台作业干扰	压测期间禁用自动维护任务，确认无其他应用连接测试库
某些SQL执行计划飘忽不定	统计信息过期、绑定变量窥探	压测前收集统计信息，对关键SQL使用SPM固定计划
`log file sync`等待严重	redo log太小、磁盘I/O太慢、提交过于频繁	增加redo log大小和组数，评估存储IOPS能力，优化应用批量提交
AWR报告无法生成	statistics_level不是TYPICAL/ALL，或快照被清理	设置`statistics_level=TYPICAL`，确认AWR保留策略
压测结果和上次差异很大	数据库补丁变化、参数变更、数据量变化	核对测试运行记录，确认环境变量是否一致

5.2 实测中容易被忽略的4个细节

第一个细节，JDBC驱动版本。很多应用用JDBC连接Oracle，驱动版本和数据库版本不匹配时，可能出现连接异常、响应变慢。之前遇到过一个问题，应用反馈压测时SQL执行时间普遍偏长，数据库端AWR显示SQL执行很快，最后定位到是JDBC驱动版本太老，ResultSet默认的fetch size太小，网络往返次数太多导致。换上新版驱动之后，性能立刻改善。基准测试前，确认驱动版本与数据库版本兼容很关键。

第二个细节，SQL里隐藏的隐式类型转换。这是Oracle里非常经典的一个性能陷阱。比如VARCHAR2字段和NUMBER字段比较，Oracle会做隐式类型转换，导致索引失效。写压测脚本时，要检查SQL里的字段类型是否和表定义一致。我自己就用这个解释过很多“为什么我的SQL明明有索引却不走”的疑问，多数情况不是索引问题，而是隐式转换悄悄把索引废了。如果压测脚本封装得好，这类问题是可以在测试准备阶段就发现的。

第三个细节，分页查询的写法。Oracle分页有两种常见风格：一种是经典的ROWNUM嵌套子查询方式，另一种是12c开始的FETCH FIRST。两种写法在某些情况下执行计划差异极大，但这跟数据分布、排序字段选择性有关，不能在一种环境下用了就断言另一种一定差。基准测试里，如果你要模拟分页场景，要把两种写法都覆盖，测试结果才全面。

第四个细节，游戏性能优化领域的“IO延迟”思路在Oracle里同样适用。也许你看过游戏引擎的性能优化文章，核心思路是把耗时的操作分摊到多帧，避免单帧卡顿，这在数据库领域对应的是“把大的事务拆小、把集中提交分散到整个时间轴”。基准测试中如果发现log file sync特别高，可以尝试把压测脚本里的事务提交方式改成批量提交或适当降低提交频率，观察等待事件的变化，这种方式往往比盲目调整redo log更有效。

5.3 关于后续扩展：基准测试不止于性能优化

基准测试的价值不局限于性能优化。我自己在实际工作中还经常用基准测试做另外几件事。

第一，容量规划。业务增长到一定阶段，需要评估数据库什么时候需要扩容、需要升级到什么配置。有了基准测试的数据，可以比较科学地推算当前配置的性能上限，为容量规划提供依据。

第二，架构方案选型。比如在采购新硬件、评估存储方案（SSD还是HDD？RAID几？）、规划主备切换方案时，基准测试可以提供一个基础判断：哪种方案在关键负载下的性能表现更好、性价比更高。之前在比较两套存储方案时，就是用SLOB做I/O压测，数据出来之后决策立刻清晰了。

第三，环境迁移验证。从11g升级到19c，从物理机迁移到云虚拟机，这些环境变更对性能影响有多大？跑一遍基准测试，前后对比，风险就清楚了。我自己在项目里做过一次从传统X86服务器迁移到ARM架构云主机的方案评估，就是靠基准测试的数据说服了团队提前发现了不少架构兼容性问题。

如果你准备在团队里推广基准测试，我的建议是从小处着手。先选一个你有把握的环境，跑通一次完整的压测流程，输出一份标准的性能报告模板。然后逐步覆盖关键业务场景，建立属于你们团队的基线数据资产。这个过程很值得投入，有了基线数据，后续所有的性能问题讨论都可以从“我感觉”变成“数据显示”，这种转变的价值，做运维和性能优化的人应该都懂。

最后再分享一个小技巧。每次做完基准测试，除了保存AWR和压测日志，记得把数据库的初始化参数文件（spfile）、关键SQL脚本、执行计划、工具配置都归档保存。几个月后当你需要复盘某次优化的来龙去脉时，这套完整档案的价值会远超你的预期。基准测试做得好不好，很多时候取决于你前期准备得细不细，而不是工具用得有多炫。把每一步做扎实，性能优化的地基自然就稳了。